Design question on Interfaces

[mike]

Does anyone have an example of a standard implementation of interfaces
in a system. Let's say I am developing a standard eCommerce
application. I want to have a light, portable set of classes that can
be used for my current client, but it should be flexible enough to
support other clients as well.

To me it makes sense to write my classes which interface with the
database and a few utilities, UI related classes, etc. Beyond that,
it seems to me that I should use interfaces and then write
implementations for each client. That would give me a few classes and
a bunch of interfaces, for which I would have to complete
implementations for each client. It should give me the ability to
write my base set of classes and not have to touch them again(except
for bugs of course).

It seems like a solid design to me, but I don't have much experience
in that area. I'm sure there will be no shortage of people who have
an opinion on this, so please, if you're just going to tell me how
stupid I am for even thinking this way, don't bother posting. I would
just like to know some pitfalls I may run into with this sort of
design.

 

[xarax]

Does anyone have an example of a standard implementation of interfaces
in a system. Let's say I am developing a standard eCommerce
application. I want to have a light, portable set of classes that can
be used for my current client, but it should be flexible enough to
support other clients as well.

To me it makes sense to write my classes which interface with the
database and a few utilities, UI related classes, etc. Beyond that,
it seems to me that I should use interfaces and then write
implementations for each client. That would give me a few classes and
a bunch of interfaces, for which I would have to complete
implementations for each client. It should give me the ability to
write my base set of classes and not have to touch them again(except
for bugs of course).

It seems like a solid design to me, but I don't have much experience
in that area. I'm sure there will be no shortage of people who have
an opinion on this, so please, if you're just going to tell me how
stupid I am for even thinking this way, don't bother posting. I would
just like to know some pitfalls I may run into with this sort of
design.

For each "interface", I write 4 java files:

1. The interface declaration, say MyFubar.

2. The abstract class definition, say MyFubarAbstract,
which implements MyFubar. In this abstract class, I
write all of the common supportive methods that I anticipate
all concrete subclasses will need.

3. The default concrete class definition, say MyFubarDefault,
which extends MyFubarAbstract. This concrete subclass lives
in a package that is separate from the package that owns the
interface and abstract class.

4. The factory class that instantiates an object of
type MyFubar. Sometimes I will use a factory object instead
of a factory class, depending on other criteria.

Now then, I use a repository class or object that has
getter and setter methods for each interface type. When
my application initializes, the main() method will instantiate
the appropriate interfaces (or factory objects) and stuff them
into the repository. All other components of the application
use the repository to get instances of the interfaces that
they need.

I mostly use "command" and "event" interfaces. The "command"
interface is the API for initiating an action or an event.
The "event" interface receives the notification of completion
of a command. The "event" interface is actually a set of
interfaces that declare the event (MyFubarEvent), the listener
(MyFubarListener), and the source of the event (MyFubarSource).

An event client will register its listener, MyFubarListener,
with the event source, MyFubarSource, by calling the
addMyFubarListener(MyFubarListener) method on the MyFubarSource
instance that the client retrieved from the repository.

A command client can choose one of two forms of the command
interface:

1. A "broadcast" form which returns a "reference ID number".
When the command completes, an event is fired to all registered
listeners. The event message includes the reference ID number
so that multiple listeners can filter for their own events.

2. A "direct" form which the client directly specifies the
listener instance that will be called when the command
completes. This is a direct form of "call-back" and is
generally more efficient than the broadcast form.

In summary, the command interface initiates an action
that will complete sometime in the future. The event
interface listens for event completion. Each interface
are coupled with an abstract class that defines the
common supportive methods that all concrete subclasses
will want to use. Default concrete classes are defined
in separate packages, along with factory classes (or
factory instances) that instantiate the default concrete
class and return a reference to the interface type. A
repository class (or instance) holds references to the
command, event, and factory instances that all components
need. The repository reference is passed to all components
during their initialization calls. The repository is
initialized by main() when the application starts.

 

[Roedy Green]

Does anyone have an example of a standard implementation of interfaces
in a system.

I can't make sense of your question. If you have an interface, you
have no choice but to implement it to the interface spec. There is
nothing special to see.

See http://mindprod.com/jgloss/interface.html