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

[James]

Interfaces are exactly the right OO approach as only interfaces will
allow you to
change the entire implementation of a class without impacting the rest
of the code.

Effective Java - Joshua Block - has an item that specifically deals
with this if you
need a Java specific reason.

Essentially is good OO practice.

See another implementation here: www.jamesladdcode.com/moat

Rgs, James.

 

[Andrew McDonagh]

Responding to Lahman...

Responding to McDonagh...



You are introducing subclassing and polymorphic dispatch that was not in
the OP's example.

I'm merely talking about a better approach to the naming convention,
than sticking an 'i' in front of the interface.

That said, the op is using Java, where everything is a polymorphic
dispatch unless explicitly declared otherwise.

My first point was simply that the interface should
be virtual, as yours seems to be here.

Agreed...and in Java you have no choice about this. Interfaces are virtual.

My secondary point is that the
class spawning the objects should be named for the problem space
entities being abstracted and that the interface name should be the
derivative _when there is no polymorphic dispatch_. Again, that is what
you are doing here, albeit with subclassing.

I wasn't showing/using subclassing. Interface implementing yes,
subclassing no. These are different things.

If there is subclassing
and polymorphic dispatch, then one should name the superclass interface
in a reasonable fashion, as you have done here, rather than as a
derivative.

Agreed.

 

[Andrew McDonagh]

Still, "(nearly) all classes should be package-private" is a fine
rule-of-thumb.

If I'm developing a library that others will use then using this
approach does have some benefits.

That said, I'd be very careful to introduce it as it can create more
headaches that its actually worth.

Going for convention over configuration is a much simpler solution. We
usually just have a package which contains interfaces for the public
facing API. All code behind them are in other packages...but they are
still public classes/interfaces.

Much like sun with its .sun.* packages ;-)

 

[John C. Bollinger]

Andrew McDonagh wrote:

[Responding to comments about naming interfaces' implementation classes]

not in Java it isn't, adding Impl is pretty much standard.

I HATE that! I don't know where it came from or how it caught on, but I
attempt to stomp on it whenever I see it. Ineffectually, more often
than not.

And is actively discouraged elsewhere.

With good reason.

The 'xxxxImpl' tag isn't great, true, but removing it by tagging the
interface is just as bad.

Agreed about tagging the interface name. The only reason that my
opinion about that one is less strong than my opinion about 'xxxxImpl'
is that I don't see it anywhere near as often.

A better example would be

interface Client

class CharitableClient
class BillableClient
etc...

Yes, exactly.

Naming an implementation ClientImpl suggests that it is the *only*
expected implementation. If the interface is only intended to admit a
single implementation, then why does it exist at all? If it is intended
to admit multiple implementations, then well chosen names for those
implementations will describe what distinguishes them from other
implementations, what their intended role or nature is, etc..

For what it's worth, when I want to provide a bare-bones implementation
of some interface without specialization for any particular domain, I
typically use the form SimpleFoo or sometimes PlainFoo or BasicFoo.
These all express pretty well the nature of the implementation, at least
to my eyes. For what it's worth, Sun uses both of the first two in
various places, though that has little to do with my general opinion on
the matter.

 

[John C. Bollinger]

Greg R. Broderick wrote:

I see and understand your point...

However, the primary use of an interface is to separate the 'Interface'
from the implementation. This is nothing to do with there (potentially)
being multiple implementations.

Interface separation allows much more design fluidity than direct
coupling to classes. Heck, its even the principle that used in
frameworks like Spring.

I read a bit more into that the first time than you actually wrote. I
generally agree with what you did write, but lest anyone else take away
something that you did not say (and hopefully didn't mean), I'll assert
that seperating interface from implementation is best realized by
designing the interfaces first and designing *TO* the interfaces
primarily. It thoroughly misses the point to design the classes first
and then hope to gain the same benefit by writing interfaces to put in
front of them. In other words "seperat[ing] the 'Interface' from the
implementation" should not be interpreted as a programming action, but
rather as a design principle.

 

[Chris Uppal]

Agreed about tagging the interface name. The only reason that my
opinion about that one is less strong than my opinion about 'xxxxImpl'
is that I don't see it anywhere near as often.

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. I think it (the name) is adopted from the C++
worlds "pimpl" (pointer to implementation) idiom. At least, that's where I
first saw it. Using it to name a class which implements an interface is, of
course, an abomination. But I think it's a valid naming scheme when an
/object/ (as opposed to a type) is split into two[*] -- one half of which
provides the publicly accessible "face", and the other provides the actual
implementation (as in the C++ idiom). "XxxxImplementation" would, of course,
be better still; and there might be better names even than that depending on
the relationship between the two objects.

([*] When it's done for technical reasons, i.e. for reasons which have only to
do with the implementation, rather than modelling anything in any domain.)

-- chris

 

[Thomas Weidenfeller]

Andrew McDonagh wrote:

[Responding to comments about naming interfaces' implementation classes]

not in Java it isn't, adding Impl is pretty much standard.

I HATE that!

I hate it, too.

I don't know where it came from

Probably C++. At least I saw it a lot in C++ code.

or how it caught on,

Probably with the GoF book. The Bridge design pattern in that book
advocates it, although with a slight different meaning. With the Bridge
pattern one is supposed to have an high-level Abstraction (catering for
the user of e.g. some library or interface), and a low-level Implementor
(Impl), catering for the one who has to implement that library or API.
The bridge is that the Abstraction utilizes (uses-a) an instance of an
Implementor to provide its service.

The Implementor is supposed to be an abstract class, which is further
subclassed into ConcreteImplementors (ConcreteImpls), providing actual
implementations of the Implementor ...

This is all in a very special context, but even in that context the Impl
suffix doesn't make much sense.

Naming an implementation ClientImpl suggests that it is the *only*
expected implementation. If the interface is only intended to admit a
single implementation, then why does it exist at all?

This is the question I always ask the people who "in the name of good OO
design" advocate that one should always use interfaces in APIs.

/Thomas

 

[Daniel Parker]

not in Java it isn't...

Eclipse being a notable exception.

Regards,
Daniel Parker
http://servingxml.sourceforge.net/

 

[Herbie Jurvanen]

Also when class browsing, the indirection through all of these
interfaces kind of generates a fog for me that is very hard to see
through.

I'm currently working in a project where interfaces are slavishly used
"everywhere," and I hate it.

In addition to the good reasons already mentioned, the code browsing issue
is one of my serious pet peeves about this approach. I wonder if there is a
code browser intelligent enough to do the following: when asked to see the
code of a particular function, and the function is called on an interface,
first check if that interface has only one implementor. If so, then go
immediately to that one implementation. If not, then offer the list of
implementors (in addition to the interface itself) so the user can choose.

As mentioned, one shouldn't necessarily use an interface if there is only
planned to be one implementor, but that's half the value of code browsers:
understanding someone else's ill-conceived code.

 

[H. S. Lahman]

Responding to McDonagh...

I'm merely talking about a better approach to the naming convention,
than sticking an 'i' in front of the interface.

The problem is that when there is no subclassing the name of the
interface and the name of the class will be semantically the same since
they both abstract the same underlying entity. So one needs to be able
to make a distinction between them for code readability. Using an 'i'
in such cases is relatively painless when deriving one name from the
other so that one can distinguish interface and class references in the
code.

OTOH, such a convention usually isn't needed when defining pure
inherited interfaces because the superclass definition is usually
implied so one won't have superclass references in the code that need to
be distinguished. That was the case in your example where only the
subclasses had class definitions. (Obviously, if one /does/ explicitly
provide superclass class definitions, then one will need to distinguish
between references to the superclass' interface and the superclass itself.)

[Of course one could argue that one should still use a derivative name
for the superclass interface just in case someone adds an explicit
superclass definition in subsequent maintenance. But that becomes even
more of a coding practice debate, so let's not go there.]

That said, the op is using Java, where everything is a polymorphic
dispatch unless explicitly declared otherwise.

We must have very different definitions of polymorphic dispatch.

To have polymorphic dispatch it must be possible to substitute behavior
when a single interface is invoked. If an interface is provided to
access only one class' members, as all of the OP's interfaces did, then
there is no polymorphic substitution when invoking the interface because
there is a 1:1 mapping between interface and class behavior. So
polymorphic dispatch only exists when different classes implement
different specializations of behavior (i.e., the classes are sibling
subclasses). Then the common interface is the interface of their
generalized superclass.

[Actually, there are other forms of polymorphic dispatch in the OO
paradigm but they are related to different constructs, such as
overloading. The form relevant in this context (i.e., behavior
substitution at the interface level) is inclusion polymorphism, which is
only enabled by subclassing.]

Agreed...and in Java you have no choice about this. Interfaces are virtual.



I wasn't showing/using subclassing. Interface implementing yes,
subclassing no. These are different things.

But that is what you /were/ showing relative to the OP's original
problem statement. In the OP's case the interfaces were not shared by
objects from different classes.

Your implication was that CharitableClient and BillableClient both
provided unique implementations of the Client interface. (If they
don't, then I don't understand your example at all.) That makes them
sibling specialization subclasses of a superclass that provides the
<common> Client interface. While languages like Java -- that provide
pure interface inheritance -- don't require the superclass to be defined
explicitly, it is still there implicitly from an OOA/D perspective.

Note that you named your <shared> interface 'Client', which implies a
higher level of abstraction and a generalization relative to the other
class names. IOW, your interface naming convention already abstracts
inheritance from a superclass in a subclassing relationship.

Put it this way. Take away BillableClient so you only have one class to
which the Client interfaces applies, as in the OP's examples. Why
wouldn't the interface name be CharitableClient rather than Client?


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

 

[James]

What do people think of having a class that implements an interface
called prefixed
with Concrete ?

eg:

Client
ConcreteClient

It not always that clear cut to define a type of Client in the first
instance.
If the first instance is a base class then something like
AbstractClient can make
more sense.

To the user code these conventions should be irrelevant as they only
care about the
interface and should use a factory to gain the actual implementation.
ie: They will never do a "new ConcreteClient" in anycase.
This is upto the factory to do and they dont see that implemenation as
the user/caller.

Rgs, James.
http://www.jamesladdcode.com/moat

 

[Andrew McDonagh]

Eclipse being a notable exception.

Regards,
Daniel Parker
http://servingxml.sourceforge.net/

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

 

[James McGill]

What do people think of having a class that implements an interface
called prefixed
with Concrete ?

eg:

Client
ConcreteClient

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 does not solve a
problem and creates complexity where there was none.

I can determine from "Client" that it's an interface -- the langauge
keeps track of that! Likewise, ConcreteClient *knows* it's a regular
class that implements Client. Why feel compelled to repeat this
information? What problem does it solve, and does it solve one problem
by creating another?

 

[Andrew McDonagh]

@news.freedom2surf.net:




Only for Java coders who can't read, or who don't understand the meaning
and use of the access modifier keywords "public", "protected", and
"private".



Cheers
GRB

Java Interfaces have nothing to do with readability or access modifiers.
They are a type abstract mechanism - separating interface from
implementation.

Let me explain....

// Note the lack of need to specify the run() method is public....
interface Runnable {
void run();
}



class LongRunningThing implements Runnable {

public void run() {
//....go to DBMS, run Stored Proc, calculate something...etc
}

public void CanOnlyBeSeenIfRefTypeIsLongRunningThing () {
}

}


class ShortRunningThing implements Runnable {

public void run() {
System.out.println("Done!");
}

public void CanOnlyBeSeenIfRefTypeIsShortRunningThing() {
}

}



class Main {

public static void main(String[] args) {

Runnable longThing = new LongRunningThing();
Runnable shortThing = new ShortRunningThing();

new Thread(longThing).start();
new Thread(shortThing).start();
}

}


Here in the main method's usage of the two runnable implementing
classes, the Type of reference used to point to the objects, is not the
class Type, its the interface Type.

So within this scope the two objects have the same Type and therefore
public interface - Runnable.

Without direct casting to the actual Class Type, we can't call the other
public methods of the corresponding Class.

i.e.

Runnable longThing = new LongRunningThing();

// Won't compile...even though target method is public.
// longThing.CanOnlyBeSeenIfRefTypeIsLongRunningThing

// Will compile - cause of casting to Class Type
((LongRunningThing)longThing).CanOnlyBeSeenIfRefTypeIsLongRunningThing();


So you see...we aren't talking about access modifiers or readability.

 

[Andrew McDonagh]

Greg R. Broderick wrote:


I see and understand your point...

However, the primary use of an interface is to separate the
'Interface' from the implementation. This is nothing to do with there
(potentially) being multiple implementations.

Interface separation allows much more design fluidity than direct
coupling to classes. Heck, its even the principle that used in
frameworks like Spring.

I read a bit more into that the first time than you actually wrote. I
generally agree with what you did write, but lest anyone else take away
something that you did not say (and hopefully didn't mean), I'll assert
that seperating interface from implementation is best realized by
designing the interfaces first and designing *TO* the interfaces
primarily. It thoroughly misses the point to design the classes first
and then hope to gain the same benefit by writing interfaces to put in
front of them. In other words "seperat[ing] the 'Interface' from the
implementation" should not be interpreted as a programming action, but
rather as a design principle.

Absolutely agree.

The only time I've ever done it 'arse backwards', is when retrofitting
interfaces to legacy code that I'm trying to tease apart in order to
improve the design - AKA Extract Interface refactor.

http://www.refactoring.com/catalog/extractInterface.html

 

[Andrew McDonagh]

What do people think of having a class that implements an interface
called prefixed
with Concrete ?

eg:

Client
ConcreteClient

It not always that clear cut to define a type of Client in the first
instance.
If the first instance is a base class then something like
AbstractClient can make
more sense.

To the user code these conventions should be irrelevant as they only
care about the
interface and should use a factory to gain the actual implementation.
ie: They will never do a "new ConcreteClient" in anycase.
This is upto the factory to do and they dont see that implemenation as
the user/caller.

Rgs, James.
http://www.jamesladdcode.com/moat

The ConcreteXxxx prefix is certainly well known and used thanks to GoF,
personally whilst I've used it when stuck for a better name, I still
prefer to find a more natural and better fitting name, even when that
class can only be created by a factory.

However, if I'm struggling for that name and the class is very simple,
I'd usually have the factory use an anonymous class.


interface Client {
void execute();
}



class ClientFactory {

public static void createClient() {

// create and use an anonymous inner class...
return new Client() {

public void execute() {
system.out.println("executing");
}

}

}

}

 

[Andrew McDonagh]

John C. Bollinger wrote:




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

Nice one!

 

[Andrew McDonagh]

I read a bit more into that the first time than you actually wrote. I
generally agree with what you did write, but lest anyone else take
away something that you did not say (and hopefully didn't mean), I'll
assert that seperating interface from implementation is best realized
by designing the interfaces first and designing *TO* the interfaces
primarily. It thoroughly misses the point to design the classes first
and then hope to gain the same benefit by writing interfaces to put in
front of them. In other words "seperat[ing] the 'Interface' from the
implementation" should not be interpreted as a programming action, but
rather as a design principle.

Absolutely agree.

The only time I've ever done it 'arse backwards', is when retrofitting
interfaces to legacy code that I'm trying to tease apart in order to
improve the design - AKA Extract Interface refactor.

http://www.refactoring.com/catalog/extractInterface.html

Oh, better qualify that a bit more....(hoping not to start a sub-thread
on TDD virtues...)

As someone who designs using TDD, I'll always take the 'YAGNI'[1] &
'DTSTTCPW'[2] approach, which normally[*] means starting with the Class,
then extracting the interface. However, the time between these two
steps is usually very small (minutes or hours). Rarely would the design
stay using the Class only for longer than that, before becoming an
interface.

[*]By normally, I mean where the first testcase has shown that i don't
need an Interface, I need a Class. Other times, the first testcase will
show immediately the need for an Interface.

[1]http://www.google.co.uk/search?hl=en&safe=off&q=YAGNI&btnG=Search&meta=
[2]http://www.google.co.uk/search?hl=en&q=DTSTTCPW&btnG=Google+Search&meta=

 

[ozgwei]

Responding to Herbie...

In addition to the good reasons already mentioned, the code browsing issue
is one of my serious pet peeves about this approach. I wonder if there is a
code browser intelligent enough to do the following: when asked to see the
code of a particular function, and the function is called on an interface,
first check if that interface has only one implementor. If so, then go
immediately to that one implementation. If not, then offer the list of
implementors (in addition to the interface itself) so the user can choose.

As mentioned, one shouldn't necessarily use an interface if there is only
planned to be one implementor, but that's half the value of code browsers:
understanding someone else's ill-conceived code.

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.

 

[ozgwei]

Responding to James

What do people think of having a class that implements an interface
called prefixed
with Concrete ?

eg:

Client
ConcreteClient

I hate to use prefix: it renders autocompletion by IDE useless. When
you type 'Concrete', you see dozens of classes and have to pick the one
you intend to use from the list.

So is 'I' for interfaces.

'Abstract' is a bit better as there aren't many of them.

Suffix 'Impl' is better, although you would like to replace it with a
more descriptive phrase to describe the implementation method. But it
isn't always preferrable if you have to use many words...