to wrap or not to wrap an opensource framework?

Question

Possible Duplicate:
Should you wrap 3rd party libraries that you adopt into your project?

I am using mail.jar, an opensource api to send mails in java.

I am wondering whether I should wrap its call to my own framework like this :

DedicatedFramework.sendMail(subject, body, recipientList);

this dedicatedFramework would then make the necessary calls to mail.jar.

The idea is that if tomorrow I replace mail.jar with a new version which deprecates/changes methods, then I reduce my coupling.

On the other hand, I add boiler code just to "hide" the framework.

What do you people do regarding this ?

Of course, it could be another framework than mail : picture managing, jdbcTemplate, GoogleCollections ...

There is no "should". Abstraction is a handy tool, when you need abstraction. Totally depends. — Dave Newton, Dec 21 '11 at 15:54
Definitile, my apologies ! I read too fast the proposal of the wizard :( — charly's, Dec 21 '11 at 17:21

score 2 · Answer 1 · answered Dec 21 '11 at 16:00

No.

Do you know you'll have to use a different mail library tomorrow? Is it even likely? I doubt it. Wrappers just for the sake of "maybe one day" are the worst kind of YAGNI.

On the other hand, if your sendMail() method does something that would otherwise be repeated wherever you send a mail, then it's not a wrapper but a useful abstraction.

score 0 · Answer 2 · answered Dec 21 '11 at 15:54

Wrap it. Making a bridge between what is available and how it's going to be used is going to save you 1) a lot of boilerplate code and 2) a lot of maintaining that code when something minor changes but you have to make the change in 20 places.

It's entirely possible there is more to this question that isn't being shown. What are our memory constraints? Can we support those extra classes being loaded? We have to identify what problems we would face by doing the wrap, just like any other problem.

However, if there isn't anything that says "We can't wrap because __" then I would recommend doing it.

score 0 · Answer 3 · answered Dec 21 '11 at 15:56

0

I would wrap it. It's way easier to find and change code when it's all in one place.

answered Dec 21 '11 at 15:56

tskuzzy

35,812
14
73
140

score 0 · Answer 4 · answered Dec 21 '11 at 15:58

In general, APIs are reasonably stable and classes/methods usually don't disappear, they get deprecated. In your particular case mail.jar is very stable so I wouldn't bother wrapping it.

My advice is to not waste your time writing an API on top of an API - it will cost you more time than it saves in the long run. I've used many libraries over the last decade and the only library I've ever had trouble with was one written by an in-house team - they refactored and changed package names and method names. That broke a lot of code. I've never experienced that with open source libraries.

score 0 · Answer 5 · answered Dec 21 '11 at 16:01

Wrap

If the framework will be used generally all over your codebase
If it will be a part of project where relatively small number of developers know how to use the framework well

Don't Wrap

If it would be used at just a tiny portion of code that would be very unlikely to change
If the framework or api is realy common knowledge for developers

to wrap or not to wrap an opensource framework?

5 Answers5