commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerome lacoste <>
Subject Re: [exec] vision for the library
Date Tue, 24 Jan 2006 13:14:59 GMT
On 1/24/06, Brett Porter <> wrote:
> jerome lacoste wrote:
> I'm big on interfaces for defining and maintaining a simple public
> contract of the API,

They help to some extent, but if you are going to use interface just
to define your public contract, I think it might be an overuse.

An 'implicit' interface is sometimes enough.


> However, this situation would have to be worked around by adding to the
> factory instead of replacing.

Factories have their use, e.g. when you want to keep control on the
returned objects, when you can do smart stuff inside the factory to
return the more appropriate object and make the client life simpler,

I think that today, full fledged dependency injection fits better than
this 'old school' IoC pattern. In particular a factory added without
real good reasons could limit the client dependening on possibilities.

I've seen people go from one class to one class + its interface + one
factory [+ the factory interface + ...]. I did that mistake before,
and I found out it didn't bring me that much benefits. I am trying to
avoid it now.

WRT intefaces, I am OK to use one, if it is minimal and has a good use
case. In fact if there's no need to have an interface right now, it
can always be added afterwards. Same for the factory.

In our case, an interface should be minimal. As you said in another
post getters and setters sshould not be part of the interface.

Basically, we only need something like:

Process start() [throws ExecuteException];

But we can add that later on, if needed. So let's design the thing as
simple as possible and to grow from there. WDYT?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message