Separation of Interface/Implementation At the risk of exposing myself as a person with a small mind, I am submitting a draft visual for approval of the Separation of Implementation from Interface. Couldn't seem to work it out, without the visuals.
The problem for me is simple. Inversion of Control and Separation of Concerns really help, but my interest is in true pluggability. True pluggability falls apart like a big dog, right when the first guy that writes a component defines the interface just by being nice enough to contribute an implementation. He didn't intend to mess up the interface, but if the interface is not defined by some standard API rather than his custom implementation, no amount of good intentions makes it possible for the next guy to follow behind. So that is the problem. If the problem is simple, the solution did not seem so simple. This is because of the many to many relationship between APIs and interfaces, and the one to many relationship between an implementation and interfaces. A strictly hierarchical approach doesn't work in all cases, so I had to map it out visually to figure out if it was even possible to come up with a methodology that would work for everything. What follows is a first draft. It is intended that smarter persons than myself will find many logic errors, and I will correct the visuals accordingly. When ready, or at any time, the Avalon committers may submit at their discretion, to add to what is already written on Interface/Impl. http://couldbe.net/InterfaceImpl/ Thanks for your help in sorting this out. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
