Function calls...

[Andrew McDonagh]

Ok, there seems to have been a mis-communication between us on this...

I remain unconvinced. Interfaces and abstract classes are two different
animals intended for two different purposes.

I completely agree with you that Interfaces & Abstract classes are
different and are used for different purposes.

Maybe in your work, interfaces
predominant, but should java.lang.Number be an interface? What about
java.util.AbstractCollection, java.iutputStream, or java.text.DateFormat?
If your answer is yes, you are at the least promoting heavy-duty code
duplication.

No you are completely right, it would be absurd at best.

So we agree.

Whilst a think Tony's stance is somewhat 'unique', I was trying to
highlight the benefits of using Interfaces are the reference type rather
than concrete or abstract classes, as this allows for a more flexible
(i.e. loosely coupled) design.

Weirdly enough, in my work Interfaces only come into existence when I
have a need to reference more than one version of the original concrete
type. Until then, I simply use the single concrete class types as the
reference.

As soon as I have a need for another version of the same type, then
first I'll 'extract interface', and then create the second concrete
class. If the two concrete classes have duplicate code, then I will of
course create an intermediate abstract class.

A very simple example....

Person ---uses--> Car

What about when they also need to drive a truck?

The code would be

Person ---uses --> vehicle

^
----------------
|
Car truck

then i remove the duplication..


Person ---uses --> vehicle

^
|
AbstractVehicle
^
|
----------------
|
Car truck


But what about when the person uses a boat, would be 'weird' for boat to
derive from AbstractVehicle as it doesn't have wheels. So by passing
refs around via the interface we over come any problems when we need to
change.

Ok...maybe that was too simplistic, but you get the idea...

We agree...

 

[Andrew McDonagh]

Sudsy was responding to Tony Morris, who said:

"It is arguable that abstract classes should be used at all
(inheritance from anything but an interface is pure evil, but
that's another story for another camp fire)."

That cause Ryan Stewart to ask why, and hence this subthread. Your
position obviously isn't as extreme as Tony's, so Sudsy's response
doesn't apply to you.

oh yes, I see that now. Yes I agree Tony's view is a little 'extreme',
and in fact I agree with Ryan, but just used different words that did
not convey my meaning very well.

 

[Andrew McDonagh]

I think it's deeper than that. In fact, I don't think that a "real
world" example along the lines you're suggesting exists.

Ok, lets forget trying to come up with a 'real world' example, as most
peoples domain knowledge would produce an example which would probably
only be confusing for others who haven't worked in that domain.

Almost by
definition, it would introduce improper dependencies between modules.

I completely agree...

However, it was just simply an example of JTables usage of the
TableModel interface.


snipped rest

 

[Ryan Stewart]

Ok, there seems to have been a mis-communication between us on this... [...]
I completely agree with you that Interfaces & Abstract classes are
different and are used for different purposes.

Okay, I thought you were agreeing that abstract classes should never be
used. That appears to be Tony's perspective.

[...]

A very simple example....

Person ---uses--> Car

What about when they also need to drive a truck?

The code would be

Person ---uses --> vehicle

^
----------------
|
Car truck

then i remove the duplication..


Person ---uses --> vehicle

^
|
AbstractVehicle
^
|
----------------
|
Car truck


But what about when the person uses a boat, would be 'weird' for boat to
derive from AbstractVehicle as it doesn't have wheels. So by passing refs
around via the interface we over come any problems when we need to change.

Ok...maybe that was too simplistic, but you get the idea...

We agree...

Absolutely. And the "Person uses Vehicle" example is a perfect example of an
interface. That's the whole point of interfaces: to provide an interface for
interaction. To take it to a higher level of complexity, you might note
first that not all vehicles have wheels (like your boat), so you might have
an abstract Vehicle with an abstract Automobile subclass with concrete
subclasses Car and Truck (or even more specialized as the need arises). Then
Boat could be a concrete subclass of Vehicle:
^
|
Vehicle
^
|
-----------------
| |
Automobile Boat
^
|
---------------
| |
Car Truck
(View fixed width for proper perspective.)

Or Boat might be abstract, and you might have subclasses Sailboat, Yacht,
OilTanker...

Finally, note that an interface doesn't need to define an entire class. When
a Person interacts with a Vehicle, what do they need to do with it? Let's
narrow it down a bit. Suppose Person is an abstract class, and you have
concrete classes Driver and Mechanic extending it. What do they do with a
Vehicle? A driver drives and a mechanic services. Therefore, you might
create interfaces Driveable and Serviceable which define methods drive and
service (in a simple world), respectively. Then a Driver can drive
*anything* that is Driveable, and a Mechanic can service *anything* that is
Serviceable. You aren't tied to a Vehicle, Automobile, Car, or any other
class.

(I'm not assuming you don't know all this, mainly writing it for others that
may be watching.)

 

[Andrew McDonagh]

Ok, there seems to have been a mis-communication between us on this...
[...]

I completely agree with you that Interfaces & Abstract classes are
different and are used for different purposes.

Okay, I thought you were agreeing that abstract classes should never be
used. That appears to be Tony's perspective.

Nare, that would be daft! Just talking about the references that are
passed around, with the (my personal) norm of by sole class type or
interface, very rarely by abstract class type.

Absolutely. And the "Person uses Vehicle" example is a perfect example of an
interface.

Weird eh...we seem to be on the same page at last...

snipped

(I'm not assuming you don't know all this, mainly writing it for others that
may be watching.)

Thanks for clarifying.

 

[Tony Morris]

I'll bite. Why never use abstract classes?

I have two articles pending for IBM DeveloperWorks early next year.
Once they are published, I will make efforts to offer a full explanation by
way of another article.

 

[Andrew McDonagh]

snipped


I have two articles pending for IBM DeveloperWorks early next year.
Once they are published, I will make efforts to offer a full explanation by
way of another article.

I take it you favour delegation over inheritance?

I certainly do, as I've seen code with large inheritance trees and its
next to 'useless' and beside its good old friend 'fragile'.

 

[Raymond Martineau]

The usual name for this is 'Command pattern', however, like Tony said,
the AbstractFunction class should always be an interface.

This was exactly what I was looking for - a standardized design pattern.
Thanks.

I was being a bit cautious - Java is ment to be programmed properly with
specific design patterns, but it's hard to know about these patterns if you
haven't been taught about them.

 

[Andrew McDonagh]

This was exactly what I was looking for - a standardized design pattern.
Thanks.

No probs, glad to help.

I was being a bit cautious - Java is ment to be programmed properly with
specific design patterns,

;-) and of course you mean all OO languages are meant to be designed
properly, using the appropriate design patterns where applicable

but it's hard to know about these patterns if you
haven't been taught about them.

True, the uni's do not always cover design patterns enough, but then
thats what books/NGs/Google are for ;-)

There's comp.software.patterns NG for general discussion of patterns.

Feel free to talk about Java implementation of those patterns here,
otherwise the OffTopic police tend to get iffy - though it doesn't
bother me at all.

Andrew