Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26494 > unrolled thread

java inheritance

Back to article view | Back to comp.lang.java.programmer

Contents

  java inheritance asdf9797 <paul.caffrey@gmail.com> - 2013-11-11 05:30 -0800
    Re: java inheritance Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-11-11 09:12 -0500
    Re: java inheritance Arne Vajhøj <arne@vajhoej.dk> - 2013-11-11 09:40 -0500
    Re: java inheritance markspace <markspace@nospam.nospam> - 2013-11-11 09:45 -0800
      Re: java inheritance Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-11-18 09:24 -0400
    Re: java inheritance Robert Klemme <shortcutter@googlemail.com> - 2013-11-11 19:19 +0100

#26494 — java inheritance

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,

[toc] | [next] | [standalone]

#26495

On 11/11/2013 8:30 AM, asdf9797 wrote:
> 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.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#26496

On 11/11/2013 8:30 AM, asdf9797 wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#26497

On 11/11/2013 5:30 AM, asdf9797 wrote:
>
> 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.

[toc] | [prev] | [next] | [standalone]

#26533

On 11/11/2013 01:45 PM, markspace wrote:
> On 11/11/2013 5:30 AM, asdf9797 wrote:
>>
>> 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.
>
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

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26498

On 11.11.2013 14:30, asdf9797 wrote:
> 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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web