Using interfaces "everywhere" due to (EMF) modelling framework

[ozgwei]

Responding to Peter, the OP.

interface Country {...}
class CountryImpl implements Country {...}

I think Country is better implemented as an enum class, or inheriting
org.apache.commons.lang.enums.Enum for JDK 1.4 or prior.

If defined as an Interface, how can you prevent multiple
implementations of this interface and still evaluate
InternetDomainCountryImplementation.getCountry("uk").equals(ConventionalCountryImplementation.getCountry("The
United Kingdom") to true?

I know it's still possible but that will take a lot of effort and
achieve little.

Generally speaking, value classes, especially those that depends little
on other non-immutable classes should be defined as classes. Country is
a good candidate. If the instances can be enumerated, you should define
it as an enum class.

 

[Stefan Ram]

starting with the Class, then extracting the interface.

I would prefer an approach in the opposite direction:

I do not start with the class, but with the algorithms
to be used on objects, to construct interfaces.

For example, I want to write an algorithm to swap to
storage entities (preliminary draft in pseudo Java):

void swap( s, t ){ b = s.read(); s.write( t.read() ); t.write( b ); }

This indicates that the storage entities need to have
the following interface

interface Readable<T>{ T read(); }
interface Writeable<T>{ void write( T ); }
interface ReadableAndWriteable extends Readable<T>, Writeable<T> {}

So the algorithm becomes:

<T> void swap
( ReadableAndWriteable<T> s, ReadableAndWriteable<T> t )
{ T b = s.read(); s.write( t.read() ); t.write( b ); }

Any additional operation in that interface beyond »read«
and »write« would be interfering because it would restrict
possible argument objects too much without need by
requiring an operation which is not really needed by
the algorithm.

This way, helpful interfaces are detected.

Then every class with appropriate read and write
operations would be tagged as implementing this interface
and thus might become an argument to all such algorithms
needing such an interface.

This way algorithms are decoupled from their arguments
to the maximum extend possible as long as static type
checking via interfaces is wanted: They require just the
smallest possible interface that they need to operate on.

 

[Herbie Jurvanen]

Yes, with Eclipse.
After highlighting an Interface/Class, select 'Navigate->Open' or
right-click and select 'Open Declaration' or press F3 will bring you to
the defnition of the Interface (if it is one). If you select
'Navigate->Open Type Hierarchy' or right-click and select 'Open Type
Hierarchy' or press F4 will display the Inheritance of the interface
(its superinterface and subinterfaces) as well as all implementations.

Thanks for mentioning that, but I should have mentioned that I'm already
aware of Eclipse's code browsing features. What I want is a browser where
the intermediate step of opening the interface could (according to user
preference) be skipped if it wasn't strictly necessary. As it stands, I
still have to do two operations in Eclipse (open interface, open
implementation) for one task (open the only impl for an interface that has
only one impl), and it's annoying.

 

[Andrew McDonagh]

Responding to Herbie...



Yes, with Eclipse.
After highlighting an Interface/Class, select 'Navigate->Open' or
right-click and select 'Open Declaration' or press F3 will bring you to
the defnition of the Interface (if it is one). If you select
'Navigate->Open Type Hierarchy' or right-click and select 'Open Type
Hierarchy' or press F4 will display the Inheritance of the interface
(its superinterface and subinterfaces) as well as all implementations.

thansk saved me having to reply - its been a long time since we've had
to worry about 'I can't see what implements me interface'....

(ignoring one point of OO - that we should really care who implements
it, only that they do)

 

[Timo Stamm]

Is it? hadn't noticed...but then there's always one eh...

Make it two. Wicket (wicket.sourceforge.net) uses IInterface all over. I
bet there are a lot of other projects that follow this "pattern".


Timo

 

[Daniel Dyer]

Make it two. Wicket (wicket.sourceforge.net) uses IInterface all over. I
bet there are a lot of other projects that follow this "pattern".

TestNG also.

Dan.

 

[Timo Stamm]

I too agree about the IXxxx interface name thing -- in fact I included an
explicit prohibition in a Java coding standard I once wrote.

XxxxxImpl is a bit different.

This seems to be the same problem people have been discussing for ages:
hungarian notation. Only difference being that it is about class names
instead of variable names.

So far I have seen:

XxxxxImpl
XxxxxSupport // See J2EE tag libraries
IInterface
AbstractXxxxx
XxxxPatternname // Patternname being the name of a software pattern
// like Observer, Facade, etc.


The hungarian notation was invented by Charles Simonyi (being Microsofts
Chief Architect, then). An article by him about this naming convention
can be found here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp

There is also a very good article by Joel Spolsky:
http://www.joelonsoftware.com/articles/Wrong.html


In my experience, there are situations where hungarian notation for
class names really helps keeping the track of complex class
relationships. But I don't like these situations.


Timo

 

[Timo Stamm]

I'd hate it very much if a project had a thousand classes all called
"ConcreteFoo"

One of the benefits of a strongly-typed language is that you don't need
to rely on naming conventions to tell you about types! I get sick of
the redundant naming prefixes that some people use.

It might make sense to put *semantic* information in the class name. But
I agree that using type names is useless, and maybe even counter-productive.


Timo

 

[Andrew McDonagh]

This seems to be the same problem people have been discussing for ages:
hungarian notation. Only difference being that it is about class names
instead of variable names.

So far I have seen:

XxxxxImpl
XxxxxSupport // See J2EE tag libraries
IInterface
AbstractXxxxx
XxxxPatternname // Patternname being the name of a software pattern
// like Observer, Facade, etc.


The hungarian notation was invented by Charles Simonyi (being Microsofts
Chief Architect, then). An article by him about this naming convention
can be found here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp


There is also a very good article by Joel Spolsky:
http://www.joelonsoftware.com/articles/Wrong.html


In my experience, there are situations where hungarian notation for
class names really helps keeping the track of complex class
relationships. But I don't like these situations.


Timo

Weirdly, I don't really have any problem with the AbstractXXXxxx or
XXxxPatternname pre/suffixes as these help reinforce some intent behind
the class.

Coming from a C++ background... we always prefix classes with 'C', so I
can see why the 'I' for interfaces happened in that language...

Yet even then, I hated the 'C' prefix, never mind the 'I'

At the moment I working with a lot of Delphi... its the same there,
only this time classes are prefixed with 'T' for Type or 'I' for
interfaces....

(runs away screaming.....)

 

[Roedy Green]

It might make sense to put *semantic* information in the class name. But
I agree that using type names is useless, and maybe even counter-productive.

I think the general principle is don't embed obvious information. It
just dilutes the true information.

If you have tools to find you interfaces or classes and if they look
different e.g. italics for Interfaces, then it is just gilding the
lily to embed the word Iterface or something like it.

It is bit like going nuts with a label maker and labeling your toaster
as TOASTER.

 

[Patrick May]

Coming from a C++ background... we always prefix classes with 'C',
so I can see why the 'I' for interfaces happened in that language...

No, "we" don't. That ugly little wart is a Microsoftism that
must die.

Yet even then, I hated the 'C' prefix, never mind the 'I'

Ah, a man with taste.

Regards,

Patrick

 

[Timo Stamm]

It might make sense to put *semantic* information in the class name. But
I agree that using type names is useless, and maybe even counter-productive.

[...]

It is bit like going nuts with a label maker and labeling your toaster
as TOASTER.

I wouldn't call a "TOASTER" label semantic information

 

[James McGill]

I wouldn't call a "TOASTER" label semantic information

If a cafe uses one toaster only for Bagels, and one only for Sliced
Bread, it would accomplish nothing to label either of them "TOASTER".

 

[Andrew McDonagh]

No, "we" don't. That ugly little wart is a Microsoftism that
must die.

Oh god, crap , yes...forgot it was a MS shop....

Ah, a man with taste.

'Suits you sir'

 

[Bart Wakker]

Like all things, this depends.

For simple straight forward POJOs that are used like most POJOs, you
are spot on. E.g. String, Integer, MySimpleClass, etc...

However, (you knew there was one)...

There are times when even these singular POJOs benefit from
separation of interface from implementation - Dependency inversion,
coupling avoidance (as in when using Frameworks), Substitutability
for Testing (as in Fakes or Mocks for TDD) even though there is only
one concrete production class, etc...

We are using only POJO's, since our entities are mapped to persistence
(database) using an object relational mapper (hibernate) that requires
no modification of classes, i.e. works with POJO's.

So there is only 1 possible and thinkable implementation.

Should one not make the distinction between public and published
API's, that is as long as it is public but internal to the project, it
makes little sense to separate the Interface from the implementation?
As long as your API gets published, then you should not provide
implementations and extract the minimum needed interface?

 

[Bart Wakker]

I think Country is better implemented as an enum class, or inheriting
org.apache.commons.lang.enums.Enum for JDK 1.4 or prior.

We do have enums, but Country is mapped from a database table so the
table contains the enumeration, we cannot use an enum in this case.

Also it just serves to make an example.

Generally speaking, value classes, especially those that depends
little on other non-immutable classes should be defined as
classes. Country is a good candidate. If the instances can be
enumerated, you should define it as an enum class.

That is an interesting statement. Even though Country cannot be
implemented as an enum, similar classes just contain values so at
least in this case it makes no sense to separate Interface from
implementation (not even for a published API).

 

[Bart Wakker]

There is a plugin to do that:
http://eclipse-tools.sourceforge.net/implementors/

bind it to some key (e.g. to replace f3) and instead of jumping to the
method on the interface it jumps to the implementor. If there is more
than 1, it presents a list of implementors and you have to select one.

 

[Ed Kirwan]

We are using only POJO's, since our entities are mapped to persistence
(database) using an object relational mapper (hibernate) that requires
no modification of classes, i.e. works with POJO's.

So there is only 1 possible and thinkable implementation.

I'm curious, my good mister Wakker, about your use of the word,
"Entities," in the above. Perhaps you could elaborate?

A naive interpretation of the above suggests that you have no interfaces
anywhere because all your classes are mapped to a database. I suspect
that this interpretation is wrong.

So, a second attempt: a small number of your classes are, "Entities,"
and, among these classes, there is no need for separating interfaces
from the concrete classes themselves. And this is fair enough: but the
question is: how many of your classes are these, "Entity," classes? I
would guess less than 10%

And this leaves 90% of your system. I would have thought that, among
this 90% of your system, even if they are all unpublished, there is
plenty of scope for separating interface from implementation.

In other words, just because your classes are internal to your system,
this is no reason to dismiss interface/implementation separation. I'm
not saying that all internal classes should be separated from
interfaces; just enough to secure the encapsulation of those internal
concepts that you expect to vary, and whose variance you wish to hide
from the rest of your internal system.

Would you agree?

--

..ed

www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html

 

[Herbie Jurvanen]

There is a plugin to do that:
http://eclipse-tools.sourceforge.net/implementors/

Wow, thanks for that! (And thanks for understanding my point, which several
others seemed to miss-- I was wondering if I hadn't been clear enough)