java inheritance

[asdf9797]

Hi

I did a java test recently and one of the questions was on the subject of
inheritance/ OO design

The idea was there was a "Storable" abstract class which contained a store() method.

There was a IStorable interface

And then there was

class Book extends Storable implements IStorable {
public void save(Book) {
}

}
The question was how to improve the implementation.

What is the current thinking on extending abstract classes ?

Is that the issue?

Thanks,

 

[Eric Sosman]

Hi

I did a java test recently and one of the questions was on the subject of
inheritance/ OO design

The idea was there was a "Storable" abstract class which contained a store() method.

There was a IStorable interface

And then there was

class Book extends Storable implements IStorable {
public void save(Book) {
}

}
The question was how to improve the implementation.

Fixing the syntax error would be a good start ...

What is the current thinking on extending abstract classes ?

The current thinking is that an abstract class that's not
extended is very nearly useless. ;-)

Is that the issue?

I don't know what the test-setters were looking for. Perhaps
the Storable class already implements IStorable, so the "implements"
part in Book is redundant. Maybe they felt the abstract class didn't
add value, and hoped you would discard "extends Storable". It's
possible they wanted the save() method to take any Storable (or
maybe IStorable) instead of insisting on a Book. Possibly all they
wanted was a trivial renaming, something along the lines of

interface Storable { ... }
abstract class AbstractStorable implements Storable { ... }
class Book extends AbstractStorable { ... }

Some design schemes are fairly rigid about such things -- make
an interface with THIS kind of name, and an abstract implementing
class with THAT kind of name, and so on and so on. If the testers
were aficionados of one such scheme, perhaps they were just trying to
find out whether you, too, were familiar with it. I'd say familiarity
with a particular set of conventions is not quite the same thing as
familiarity with Java and/or with O-O design -- but maybe that's not
what they were after.

 

[Arne Vajhøj]

I did a java test recently and one of the questions was on the subject of
inheritance/ OO design

The idea was there was a "Storable" abstract class which contained a store() method.

There was a IStorable interface

And then there was

class Book extends Storable implements IStorable {
public void save(Book) {
}

}
The question was how to improve the implementation.

What is the current thinking on extending abstract classes ?

Is that the issue?

The construct of:
- an interface
- an abstract base class with common logic that that are good for most
implementations
- some concrete classes that extends the abstract base class
is widely used.

The question probably relates to something very specific in the text.

Arne

 

[markspace]

The idea was there was a "Storable" abstract class which contained a
store() method.

There was a IStorable interface

To explain Arne comment a bit, probably the actual question involved
something you didn't tell us. Besides the obvious syntactic omission
and a possible misspelling, "improve" can require quite a lot of
context, and what you've told us is basically nothing at all.

One job interview technique (not for written tests) is to ask the
candidate an open ended question, and see how he or she responds. What
sort of questions does the candidate ask, and what sort of logical paths
does he or she pursue? Maybe this was that sort of question.

 

[Robert Klemme]

Hi

I did a java test recently and one of the questions was on the subject of
inheritance/ OO design

The idea was there was a "Storable" abstract class which contained a store() method.

There was a IStorable interface

And then there was

class Book extends Storable implements IStorable {
public void save(Book) {
}

}
The question was how to improve the implementation.

Get rid of the argument of method save(). A Book has immediate access
to all its state.

If at all, you would want to pass something like a Store, a Store
interface or something which is able to store data. For that it would
have to exhibit methods for basic store operations much like DataOutput
does.

http://docs.oracle.com/javase/7/docs/api/java/io/DataOutput.html

What is the current thinking on extending abstract classes ?

Extending abstract classes is absolutely necessary.

Is that the issue?

What?

Kind regards

robert

 

[Arved Sandstrom]

To explain Arne comment a bit, probably the actual question involved
something you didn't tell us. Besides the obvious syntactic omission
and a possible misspelling, "improve" can require quite a lot of
context, and what you've told us is basically nothing at all.

One job interview technique (not for written tests) is to ask the
candidate an open ended question, and see how he or she responds. What
sort of questions does the candidate ask, and what sort of logical paths
does he or she pursue? Maybe this was that sort of question.

Good comments by all. I think this is exactly that kind of question, to
see how the candidate or certification taker responds and thinks.

One of the first things I'd question is the existence of the abstract
class. Not that we know how IStorable is defined, but intuitively I'd
want a "store" method to be in the interface, with documentation. Only
if there were substantial implementation commonality would I bother with
the abstract class.

In the real world I (we) would know what the problem actually is, not be
presented with part of a flawed solution.

AHS