On 1/24/06, Brett Porter <[EMAIL PROTECTED]> 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. > > WDYT? 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, etc. 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? Jerome --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
