A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
It's often useful to configure an object by telling it what its parts are. Say CommHandler is an interface, and you configure MessageHandler like this:
messageHandler.setCommHandler(someCommHandler)
Now messageHandler could be talking to any of a variety of CommHandlers, maybe one that does sockets, another that does SOAP and another that is a mock handler just for unit testing. Actually that last case may be enough reason to do it. Are you familiar with mock objects? If not, start a new thread. They are cool.
This is probably the opposite of reality, but say messageHandler is very stable and will never change, while CommHandler must frequently adapt to new networks, protocols, addresses, etc. You want the less stable package to have compile time dependencies to the more stable package. MessageHandler's package could define the CommHandler interface so that any unstable packages that implement CommHandler will depend on the stable MessageHandler package. MessageHandler will never know the actual classes that implement CommHandler, so it would have a hard time creating a CommHandler in its constructor.
Any of that help? Hope it wasn't too far off the deep end. OO Theory is great fun!
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
Design is always compromise. Are you designing for comm to be reusable in other systems, maybe marketed as a binary-only jar? Then it needs to own its interface. Or are you designing for the stable part of your system to survive changes in the less stable parts? Then it needs to satisfy MsgHandler's requirements.
For more fun, think about how JDBC plays two roles. It must be reused by many applications. It must be stable over many drivers. Dependencies flow IN to JDBC from both directions. Writing an application you use one set of interfaces. Writing a driver you use another set of interfaces. But in both cases, JDBC owns the interface and does not depend on the app or the driver.
Any of that help?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi