Reputation: 8815
I am doing a thin wrapper over a third-party framework, i am thinking following options:
completely wrap the framework, so that the client of the wrapper will not notice the wrapped framework. if so, it means i have to wrap some classes from the framework. this way no dependency between the wrapper's client and the wrapped framework.
expose some classes from the framework to the wrapper's client, it means the client is required to reference the wrapped framework.
what's your opinion?
Upvotes: 0
Views: 314
Reputation: 13055
I'd go a step further, and write the functionality independent of the framework, and create "ideal" interfaces that you use.
Then, create a bridge between your functionality and the framework.
Wrapping someone's framework isn't necessarily a huge win if the wrapper is a one-to-one translation of the framework! You'll remove the binary dependency, but you'll still be conceptually coupled to the framework, making it harder to use your code outside of the framework.
Upvotes: 1
Reputation: 3155
You should take the purpose and the "volatility" of the framework in mind, but in general I would opt for wrapping it completely. This gives you much more flexibility and better encapsulation (think of exceptions for example)
Upvotes: 1
Reputation: 10814
I'd say that if the purpose of the wrapper is to make the client application independent of the third-party framework, then the wrapper should include all the aspects of the framework that the client application will use. That way the third-party component could be swapped out further on without affecting the client (assuming the interface of the wrapper is designed to be general enough to "fit" another third-party component).
Upvotes: 1