Design - inheritance vs interface

E

Edward A Thompson

I have been reading on Java design practice, especially the arguments
for using interfaces rather than inheritance (composition vs
extension). I understand the reasons one would want to use an
interface rather than inherit form a parent class, but I have concerns
-

Since an interface does not have code, if multiple classes need to
implement the same interface, doesn't that mean I will be writing the
same methods for each, methods which might be identical?

Doesn't this encourage the bad practice of cut and paste coding and
the implied maintenance nightmare?

Interested in your thoughts
 
O

online.no

well, you can create an abstract base class....

e.g.

interface A

class abstract A1 implements A

interface B extends A

class abstract B1 extends A implements B
......

etc...

-Jon
 
M

Michael Borgwardt

Edward said:
Since an interface does not have code, if multiple classes need to
implement the same interface, doesn't that mean I will be writing the
same methods for each, methods which might be identical?

Doesn't this encourage the bad practice of cut and paste coding and
the implied maintenance nightmare?

If the code is indeed identical or can be made so, and the classes do not
have a "is-a" relationship (i.e. inheritance would be bad), then how
about composition? Implement the method in one class, keep instances
of that class in the others and have the interface methods just forward
the calls. It makes for some verbosity, but at least avoids copy-paste
of the actual implementing code.

The need shouldn't arise too often, otherwise I'd suspect some
underlying design problems.
 
A

Anton Spaans

Edward A Thompson said:
I have been reading on Java design practice, especially the arguments
for using interfaces rather than inheritance (composition vs
extension). I understand the reasons one would want to use an
interface rather than inherit form a parent class, but I have concerns
-

Since an interface does not have code, if multiple classes need to
implement the same interface, doesn't that mean I will be writing the
same methods for each, methods which might be identical?

Doesn't this encourage the bad practice of cut and paste coding and
the implied maintenance nightmare?

Interested in your thoughts

If you're mainly worried about code re-use, use inheritance more. If you
know that a multiple of classes implementing interface IFoo actually
implement the methods the same way, make a (abstract) base class AFoo that
implements IFoo:
public abstract class AFoo implements IFoo
{
.... now implement the bodies of the methods of IFoo that are the same for
all (or most) possible subclasses of AFoo....
public int method1OfIFoo(int pParam)
{
...
}
}

And use inheritance to do code re-use:

public class Klass1 extends AFoo
{
....
}

public class Klass2 extends AFoo
{
....
}


Or use a delegate:

public class Klass1 implements IFoo
{
private final IFoo mDelegate = new IFooDelegateVersion1();

public int method1OfIFoo(int pParam)
{
return mDelegate.method1OfIFoo(pParam);
}
... etc...
}

public class Klass2 implements IFoo
{
private final IFoo mDelegate = new IFooDelegateVersion1();

public int method1OfIFoo(int pParam)
{
return mDelegate.method1OfIFoo(pParam);
}
... etc...
}

If you're not worried about code-use, you can just use interfaces. It's all
upto your needs for your design.
-- Anton Spaans.
 
T

Tim

online.no said:
well, you can create an abstract base class....

e.g.

interface A

class abstract A1 implements A

interface B extends A

class abstract B1 extends A implements B
.....
Is that correct or should B1 extend A1?
 
B

BarryNL

Edward said:
I have been reading on Java design practice, especially the arguments
for using interfaces rather than inheritance (composition vs
extension). I understand the reasons one would want to use an
interface rather than inherit form a parent class, but I have concerns
-

Since an interface does not have code, if multiple classes need to
implement the same interface, doesn't that mean I will be writing the
same methods for each, methods which might be identical?

Doesn't this encourage the bad practice of cut and paste coding and
the implied maintenance nightmare?

If that was the situation, you'd probably code an abstract class to the
interface and extend that for the implementations with a lot of shared
functionality. Either that or encapsulate the common functionality in a
helper class.
 
B

BarryNL

Michael said:
If the code is indeed identical or can be made so, and the classes do not
have a "is-a" relationship (i.e. inheritance would be bad), then how
about composition? Implement the method in one class, keep instances
of that class in the others and have the interface methods just forward
the calls. It makes for some verbosity, but at least avoids copy-paste
of the actual implementing code.

The need shouldn't arise too often, otherwise I'd suspect some
underlying design problems.

This sort of thing is fairly common with MVC design. Consider
javax.swing.ListModel, javax.swing.table.TableModel and their
abstract/default implementations, for example.
 
S

Silvio Bierman

Michael Borgwardt said:
If the code is indeed identical or can be made so, and the classes do not
have a "is-a" relationship (i.e. inheritance would be bad), then how
about composition? Implement the method in one class, keep instances
of that class in the others and have the interface methods just forward
the calls. It makes for some verbosity, but at least avoids copy-paste
of the actual implementing code.

The need shouldn't arise too often, otherwise I'd suspect some
underlying design problems.

I would disagree with the last sentence. Even in Swing several XXXListener
interfaces are matched with an XXXAdapter class to derive from since
implementing the interface is to tedious. Not that I am saying Swing has no
design problems...

The point is that Java gives us a very flexible interface facility which I
strongly prefer over inheritance which I avoid in most cases, but Java fails
to provide a simple forwarding facility. See the next example:

public interface I
{
public void f1();
public void f2(int x,int y);
public String getF3();
}

public class IAdapter
{
public void f1() { /***/ }
public void f2(int x,int y) { /***/ }
public String getF3() { /***/ }
}

public class DerivedI extends IAdapter
{
public String getF3() { return "DerivedI"; }
}

This is currently the only practical way of reusing IAdapter. Containing an
IAdapter and forwarding all identical implementations is to tedious and
extensions of interface I will break the class, even if the mathcing
IAdapter is extended. So inheritance is the only practical way.

Why not have something like

public class ImplementingI implements I
{
private I forwarder = new IAdapter();

public I() { return forwarder; } //provide a forward function for implicit
forwarding non-overruled methods from I

public String getF3() { return "ImplementingI"; } //overrule when needed
}

That would be a usefull extension that makes aggregation of adapter classes
much more practical and helps avoiding extending base classes.

Silvio Bierman
 
D

Dimitri Maziuk

Edward A Thompson sez:
I have been reading on Java design practice, especially the arguments
for using interfaces rather than inheritance (composition vs
extension). I understand the reasons one would want to use an
interface rather than inherit form a parent class, but I have concerns
-

Since an interface does not have code, if multiple classes need to
implement the same interface, doesn't that mean I will be writing the
same methods for each, methods which might be identical?
Yes.

Doesn't this encourage the bad practice of cut and paste coding and
the implied maintenance nightmare?

Yes.

Java interfaces have little to do with composition; they are
behaviour specifications.

For example, you have two packages that store data structure
as in-memory tree and in a relational database. Implementations
are quite different so there's no point in reusing the code via
inheritance. That's when you'd use an interface: make both
implement the same interface so they can be used interchangeably
by client code.

Composition, OTOH, is when you put an object inside a wrapper
class. You get to reuse the code, as with inheritance, plus
you can hide object's public methods, fake overriding on
return value, and do other tricks you can't do with inheritance.

Dima
 
P

Pat Ryan

Silvio Bierman said:
Why not have something like

public class ImplementingI implements I
{
private I forwarder = new IAdapter();

public I() { return forwarder; } //provide a forward function for implicit
forwarding non-overruled methods from I

public String getF3() { return "ImplementingI"; } //overrule when needed
}

That would be a usefull extension that makes aggregation of adapter classes
much more practical and helps avoiding extending base classes.

Silvio Bierman
Delphi has a feature like this - it allows you to implement an interface by
delegating to a member objetc without explicitly writing the delegation
code - there is simply a keyword ("implements") which declares that the
member object implements the interface on behalf of the owner see
http://weblogs.asp.net/fmarguerie/archive/2003/04/07/4983.aspx for a code
example
 
S

Silvio Bierman

Pat Ryan said:
Delphi has a feature like this - it allows you to implement an interface by
delegating to a member objetc without explicitly writing the delegation
code - there is simply a keyword ("implements") which declares that the
member object implements the interface on behalf of the owner see
http://weblogs.asp.net/fmarguerie/archive/2003/04/07/4983.aspx for a code
example

Thanks for the reply Pat,

I heard of this but have never used this particular feature of Delphi. In
fact, it has been a few years since I used Delphi at all. I am in the
business of writing enterprise applications that are accessed through
browsers and run on various server platforms. Therefore Java is the most
natural platform for me and I have come to really appreciate the strong
sides of the language these past years. That is why I am disappointed that
even Java 1.5 does not offer such a feature.

Regards,

Silvio Bierman
 
E

Ed Thompson

This is actually what I did -

public interface A {}

public abstract class A1 implements A
{
public void process()
{
lots of shared processing...
doSomething();
lots of shared processing...
}
abstract void doSomething() {};
}

public class A1A extends A1 {
public void soSomething() { do something A1Aish };
}

public class A1B extends A1 {
public void soSomething() { do something A1Bish };
}




what makes me uncomfortable is that I have a
method in A1 (the abstract class) that needs to behave
slightly differently in A1A abd A1B - not enough to merit
overridding in A1A and A1B.

So I defined an abstract method in A1 that is called by A1.
These methods are implemendt in A1A and A1B, which menas I have
a base class referencing a method in a derived class. Is this bad?

I guess this is what I am looking for design feedback on...
 
A

Adam

what makes me uncomfortable is that I have a
method in A1 (the abstract class) that needs to behave
slightly differently in A1A abd A1B - not enough to merit
overridding in A1A and A1B.

So I defined an abstract method in A1 that is called by A1.
These methods are implemendt in A1A and A1B, which menas I have
a base class referencing a method in a derived class. Is this bad?

I guess this is what I am looking for design feedback on...

Perfectly resonable for me - isn't that what polymorphism
was invented for?
There may be some dangers about that though.
For example if doSomething operates on some instance
data fields in derived classes it would be a horror
to call it from constructor of base class,
because it would be called before constructor
of derived class is finished, so probably before
the data fields are constructed.

Adam
 
M

Michael Borgwardt

Ed Thompson said:
So I defined an abstract method in A1 that is called by A1.
These methods are implemendt in A1A and A1B, which menas I have
a base class referencing a method in a derived class. Is this bad?

I'm not sure whether it's considered "bad", but it's a quite common practice
when using abstract base classes. However, one would normally declare
such method as protected, not public, and there should be very thorough
documentation describing how it should be implemented. For widely-circulated
code, the method and its contract cannot be changed afterwards since there
might be subclasses that depend on it.
 
M

Michael N. Christoff

Ed Thompson said:
This is actually what I did -

public interface A {}

public abstract class A1 implements A
{
public void process()
{
lots of shared processing...
doSomething();
lots of shared processing...
}
abstract void doSomething() {};
}

public class A1A extends A1 {
public void soSomething() { do something A1Aish };
}

public class A1B extends A1 {
public void soSomething() { do something A1Bish };
}




what makes me uncomfortable is that I have a
method in A1 (the abstract class) that needs to behave
slightly differently in A1A abd A1B - not enough to merit
overridding in A1A and A1B.

So I defined an abstract method in A1 that is called by A1.
These methods are implemendt in A1A and A1B, which menas I have
a base class referencing a method in a derived class. Is this bad?

I guess this is what I am looking for design feedback on...

Why do you need the A interface? Why don't you just use A1 as your common
type?



l8r, Mike N. Christoff
 
P

P.Hill

Adam said:
Perfectly resonable for me - isn't that what polymorphism
was invented for?

Isn't that what the beginning textbooks suggest when the
have examples of Bear extending FourLeggedAnimal extending Animal

and all animals have a walk() method

but FourLeggedAnimals have incomplete implementations of the whole
process so have various abstract methods
bendFrontKnee()
bendBackKnee()

More specifically such things are what abstract base classes
are for.

-Paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top