Interface vs. abstract class in UML and in Java; role of TO, VO

[Thomas Taeger]

PS: I replaced the former wrong wording "DTO" by "TO" now for better reading. Further discussion might not be affected. Thomas

Hello all,

I tend to be a purist in using interfaces ("the glue of OO") instead of abstract classes in Java and for instance in UML diagrams.

Whatever is generic I show it as an interface in my UML diagrams.
I also let an interface call others - that fortunately is correct in UML [2.0] (though impossible in Java).

Now the UML tool Together Solo let me come up against the fact that especially for a Transfer Object (TO) there might be a logical, non-technical reason for being an abstract class and not an interface. The occurence was:
- as long as an interface has neighther getters nor setters, it is shown in the ball notation
- as soon an interface has at least one getter and or setter (called Properties in Together), it is shown in the classifier notation.

First I felt about fighting against the tool, configure it ..., but in meantime I think the tool is right, at least for TOs (question follows below).


Thesis I:
- TO should carry values only (old term was "value object"!, "VO")
- TO should not have any business logic
- (only minimal technical conversion methods, maybe)
- TO needs not and should not provide any interface(!)
- Therefore Together is right to force me to decide if I want to have
- - a TO (values with getters/setters)
- - or an interface (business behaviour).


Thesis II:
- Exactly this strict functional separation is the only logical reason for giving TO an own design pattern.
Regarding this the old term VO was even better than TO (though TO is more handy, easier to understand).


Or do you know any other objects in UML needing abstract classes instead of interfaces for logical reasons?
I would be glad to read your answers ...

Thomas

[ May 10, 2006: Message edited by: Thomas Taeger ]
[ June 08, 2006: Message edited by: Thomas Taeger ]

[don brown (aka brownie brownie)]

firstly, VO and DTO are not the same. DTO is mutable since it can be sent from the middle tier down to the client - changed - and then sent back to the middle tier. It has a get/set interface. A Value Object is immutable and as such doesn't need an interface...just make the variables public. This will be passed between tiers and used for rendering mainly.

secondly, don't use interfaces unless you have several possible implementations to generalise from. shock!! think of JMS. did they generalise from one M.O.M. ? they couldn't have. This is the misuse of interfaces that most people carry out. don't generalise too early. stick with concrete classes until you can properly generalise. then you will gain substitutability without having to bend implementations to fit an interface they don't really support semantically.

[Thomas Taeger]

Hello Don,

Originally posted by don brown (aka brownie brownie):
secondly, don't use interfaces unless you have several possible implementations to generalise from. shock!!

Why shock? I am shocked of all the programmers coding classes by copy&paste instead of generalizing common behaviour - to an abstract class in Java. And in UML you not even need to or should think in abstract classes but can and should think in UML interfaces.

Originally posted by don brown (aka brownie brownie):
This is the misuse of interfaces that most people carry out.

I have seen generations of developers coding without or with only few interfaces, but I have never seen a "misuse of interfaces that most people carry out".

Originally posted by don brown (aka brownie brownie):
don't generalise too early. stick with concrete classes until you can properly generalise. then you will gain substitutability without having to bend implementations to fit an interface they don't really support semantically.

1. Then normally it is late. Rare developers will touch their code anymore.
2. If I know from the usecases that two realizations (say for customers and for agents) have to do the same business, are to have the same behaviour (regardless of their boundaries, UI, HTML, ...) then I am intelligent enough to design this common behaviour in common sequence diagrams using common UML interfaces, necessarily being UML interfaces and not concrete classes (nor abstract classes in UML).

At all: Please note that this is
- my oppinion
- not said by any book
- not forbidden by any book
- strictly used in the good projects I have been working on
- neglected in the bad projects I have been working on

(DTO vs. TO vs. VO I will give a secons answer)

Thomas

[Peer Reynders]

Anything driven to the extreme � even a best practice � becomes an anti-pattern.

However the rule is that interfaces are underutilized rather than over-utilized. Object-Oriented Design usually attempts to exploit polymorphism through application of the Liskov Substitution Principle.
Abstract classes have limited utility in Java because of the limitation to single inheritance so most of the polymorphic action happens with interfaces. For maximum flexibility you'll often end up with two artifacts:

The interface. (Classes doing their own thing only implement this)

An implementing abstract or concrete convenience class that contains any default method implementations. If the class is concrete, most classes can simply implement the interface themselves and delegate to the convenience class when they don't have anything better to do, while other classes that aren't already tied to another base class can directly extend the convenience class (however see Why extends is evil). An abstract convenience class is less useful as classes already tied to another base class can't use it.

The Open-Closed Principle relies on the abstraction of the interface. If you are implementing against a concrete type/class then you cannot "sneak" in a new class that wraps and augments the pre-existing class (now sometimes this is done in combination with "final" for security reasons but that is another discussion) � they may be a variety of reasons why you may not want to or cannot modify the pre-existing class (see refactoring: Introduce Local Extension).
The Dependency Inversion Principle also relies on interfaces � most callbacks are based on this principle.
The Interface Segregation Principle simply suggests that you keep your interfaces lean to limit the client's dependence to the methods that are actually used � so you tend to end up with a larger number of interfaces but each of them should only require a few methods.
You can find a discussion of these topics here.

SRP: The Single Responsibility Principle

OCP: The Open-Closed Principle

LSP: The Liskov Substitution Principle

DIP: The Dependency Inversion Principle

ISP: The Interface Segregation Principle

You can find most of these topics updated to Java in Robert C. Martin's (Uncle Bob) Agile Software Development: Principles, Patterns, and Practices

Certain refactorings may introduce polymorphism (i.e. interfaces), sometimes in surprising (i.e. unexpected) places:

Replace Conditional with Polymorphism

Replace Type Code with Class

Replace Type Code with State/Strategy

Replace Type Code with Subclasses

Tease Apart Inheritance

Introduce Null Object

Introduce Local Extension

Form Template Method

Extract Superclass

Extract Subclass

Extract Interface

I can certainly understand interface-fatigue after you've been exposed to EJB. For every little thing you have to worry about the:

Bean Class

Component Interface

Home Interface

Remote vs. Local

Dealing with EJBContext (or sub-interfaces) to "talk" to the container

Reacting to the container through the EntityBean, SessionBean, SessionSynchronization, MessageDrivenBean, MessageListener callback methods

But this is simply the result of the choices that were made when the container architecture was designed. It doesn't imply that interfaces are overkill. To avoid this complexity and dependency on the container, current lightweight containers utilize Dependency Injection(Inversion of Control (IoC)).

I already mentioned "Why extends is evil" - might as well throw this one in: Why getter and setter methods are evil.

[Thomas Taeger]

Hello Peer,

Originally posted by Peer Reynders:
Anything driven to the extreme � even a best practice � becomes an anti-pattern.

A commonplace (bathos, bromide, platitude, truism?) without reasoning easily gets a "Moralin-effect".

Thank you for the other 99% of your answer! I will study it carefully. This will take some time.
Till then,
Thomas

[don brown (aka brownie brownie)]

>I have seen generations of developers coding without or with only few >interfaces, but I have never seen a "misuse of interfaces that most >people carry out".


Interface based programming is obviously a good idea but my point is that often, people try and extract an interface from a class and code to that when they shouldn't. The reason they shouldn't is because they have generalised from a sample of 1, which is ridiculous. In order to plug in a different implementation you'll have to bend your impl's to fit your interface. You have to consider the semantics of an interface when you implement it, not just type safety.

[Peer Reynders]

Originally posted by don brown (aka brownie brownie):
In order to plug in a different implementation you'll have to bend your impl's to fit your interface. You have to consider the semantics of an interface when you implement it, not just type safety.

The point I was trying to make is that are many reasons to use interfaces � many more than there are to use inheritance (inheritance is quite often overused, especially by neophytes). For example, it is a powerful technique to isolate yourself from a third-party API or library (especially if you don't have access to the source code), limit your dependencies to the ones that are essential and potentially simplify the "interface" by using your own interfaces (and adaptors) so that you can replace the "risky" third-party components later. That time may never come, so there may only ever be a single implementation and type safety is not the issue.

[don brown (aka brownie brownie)]

You have just pinned down another misuse of interfaces. People often wrap an API, or hide it behind an interface, thinking that they have removed a dependency on that API.

They haven't removed a dependency on an API. They have merely replaced an explicit coupling with an implicit one - which is *worse* IMHO.

Instead of being directly tied to the API, they have a layer of indirection. However, to plug in another product they will more than likely end up rewriting all the wrapping interfaces due to premature generalisation, so what have they gained?

In reality once an API goes into a product, it rarely gets changed anyway.

[Devender Thareja]

IMHO, I kind of agree with Don's first point. If you adopt the style to extract common interface when you come accross similar implementations, your code is more foolproof and you are constantly improving your design and implementation. And with all fancy IDE available now a days, refactoring is not that difficult.
However, I donot agree with Don, on that developing an interface and adapter is useless layer in middle. Think about it, if the extrenal class is used million times and your project then the replacing risky code will require to modify all the places it was used. With this case the change limited to one class. In my opinion, this is a valid use of interface.
My 2 cents.

[Thomas Taeger]

Hello all,

I just found an interesting correction in [Austrian/German] literature:
"UML@Work" 1st Edition, 1999 (UML 1)
versus
"UML@Work" 3rd Edition, 2006 (UML 2)
concerning the definition of the term interface in UML (!, not in Java).

In 1st Ed., page 51 I read:
"Ein Interface ... kann ... allenfalls hinfuehrende unidirektionale Assoziationen aufweisen",
i.e.:
an interface can at the most have associations that
- are unidirectional and
- lead to the interface.

This [...] passus has been removed in the actual 3rd edition, page 101.

I did not check aigainst the UML 1 specification if there has been a change to UML 2. But I remember my confusion on this old wrong definition when I read it in 2003. I at that time discussed that with a friend working at the university and got the clear answer, that an UML interface (also in UML 1) may also have outgoing associations, in contrary to what was said in 1st edition and in contrary to Java interfaces.

PS: Both book editions seem to be right due to a specification change, see Peer's reply below, posted June 07, 2006 06:09 PM.

Thomas
[ June 08, 2006: Message edited by: Thomas Taeger ]

[Thomas Taeger]

Originally posted by Thomas Taeger:
... I will study it carefully. This will take some time. ...

I promised to read it carefully later, here I am:

"Why extends is evil":
great, and mostly matching the topic "interfaces ...".

[... cut on 2006-06-08 ...]

Thomas
[ June 08, 2006: Message edited by: Thomas Taeger ]

[Peer Reynders]

Originally posted by Thomas Taeger:
In 1st Ed., page 51 I read:
"Ein Interface ... kann ... allenfalls hinfuehrende unidirektionale Assoziationen aufweisen",
i.e.:
an interface can at the most have associations that
- are unidirectional and
- lead to the interface.

The Unified Modeling Language Reference Manual (December 1998) p. 311:

Interfaces do not have implementation, they lack attributes, states, and associations; they have only operations and signals received. Interfaces may have generalization relationships.

Originally posted by Thomas Taeger:
I did not check against the UML 1 specification if there has been a change to UML 2.

The Unified Modeling Language Reference Manual (2004) p. 415

An interface may have associations to other interfaces. This means that a conforming association must exist between instances of classifiers that realize the interfaces. Each interface is a provided interface of the interface.
An interface may have an association to a classifier. This means that a conforming association must exist between instances of classifiers realizing the interface and instances of the classifier. The interface is a provided interface of the classifier.

Originally posted by Thomas Taeger:
� but not the topic.

Sorry, but I don't think any of my posts were "on topic" with your original post in this thread as none of them related directly to TO's. However, Don's "don't use interfaces unless you have several possible implementations to generalize" compelled me to respond. I think is important to emphasize that the statement "inheritance is overused" doesn�t imply that "polymorphism is overused" and that interfaces are far more useful than either abstract classes or inheritance with concrete classes. All those references (the getter/setter one excluded) were merely trying to emphasize how useful (and often appropriate) interfaces really are � and how they may appear before you are even sure that there will be multiple implementations. Also to a neophyte it may not be obvious that something as simple as an "if-then-else" construct may in the future give rise to multiple class implementations/realizations to be generalized by an interface � hence the reference to "Replace Conditional with Polymorphism".

[Thomas Taeger]

Originally posted by Peer Reynders:
[...] "don't use interfaces unless you have several possible implementations to generalize" compelled me to respond. I think is important to emphasize that the statement "inheritance is overused" doesn�t imply that "polymorphism is overused" and that interfaces are far more useful than either abstract classes or inheritance with concrete classes. All those references (the getter/setter one excluded) were merely trying to emphasize how useful (and often appropriate) interfaces really are [...]

... My "not the topic" comment expressed my frustration when reading the documents linked to in your long list. I had postponed reading because I thought it would take much time that at that moment I did not have. ... I will erase my comment in place.

The Unified Modeling Language Reference Manual (December 1998) p. 311:
quote: Interfaces do not have implementation, they lack attributes, states, and associations; they have only operations and signals received. Interfaces may have generalization relationships.
[...]

The Unified Modeling Language Reference Manual (2004) p. 415
quote:
An interface may have associations to other interfaces. This means that a conforming association must exist between instances of classifiers that realize the interfaces. ...

Thank you for this clarification! So I had been misled by the tool (TogetherJ) that
a) for the exam and for being UML 1 compliant unfortunately
b) but in praxi fortunately
supports outgoing associations of interfaces as allowed in UML 2 - though it is a UML 1 tool.

That also means that both editions of the book "UML@Work" had been right. I will re-edit / PS that.

Thomas
[ June 10, 2006: Message edited by: Thomas Taeger ]