On 08/24/2016 02:08 PM, Michael Vorburger wrote: > On Wed, Aug 24, 2016 at 1:13 PM, Robert Varga <n...@hq.sk > <mailto:n...@hq.sk>> wrote: > > > On 08/24/2016 01:06 PM, Tom Pantelis wrote: > > Yes but accessing it via getSupportedExtensions isn't intuitive, hence > > the discussion. > > Well, it follows the Extensible Object pattern, which really is the only > feasible way to provide extensibility without breaking API contracts in > face of multiple competing contracts and forwarding classes... > > > Well I do think there is another way.. with Dependency Injection, you > can create additional interfaces for new API methods, and then register > a single service implementation under several Service API interfaces, to > make it easy for clients to get them inject easily instead of having to > grab one thing and in client code having to adapt them to another thing > explicitly à la getSupportedExtensions().get(...), assuming that's what > you mean with the Extensible Object pattern.
Right, which leads down to problems with decomposition and naming those new interfaces -- eventually leading to combinatorial explosion of interfaces. DI does not automatically solve the problem, because given that a particular interface can have a multitude of implementations, and an application's need to inject multiple services which are just facets of a particular implementation. To draw a very concrete example, DOMDataBroker has two aspects to it: a producer aspect (transactions, transaction chains) and a consumer aspect (DOMDataChangeListener). User of the API certainly expects that committing transactions will result in DCNs -- but that is only guaranteed as long as the two services are related -- which is not something DI will solve automatically, as the two services would be injected separately and could come from unrelated implementations. As it turned out, DOMDataChangeListener's API design is completely wrong and was replaced by DOMDataTreeChangeService. We could have retrofitted it directly into DOMDataBroker, breaking all implementations out there and having to deal with the same problem in DOMDataTreeChangeService's contract did not work out. Furthermore there is the question of providing implementation-specific interfaces to access implementation internals, which the user *can* take advantage of (but are not required for proper operation). I am not sure how DI can solve this problem without leading to explosion of interfaces (like DDSDataBroker extends DataBroker) and migration issues stemming from the complicated class hierarchy that creates. With this design pattern, you get hold of a DOMDataBroker and acquire aspects you need or can take advantage of. Bye, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
