File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes to remove dependency from third part jars Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "to remove dependency from third part jars" Watch "to remove dependency from third part jars" New topic

to remove dependency from third part jars

gaurav abbi
Ranch Hand

Joined: Jan 05, 2007
Posts: 108
hi all,
i'm using a third party jar to implement some of my functionality.
Now in case there is a whole architectural change in the third party jar, my project also needs to be restructured which is quite a laborious work.

what i want is a kind of design where any future changes in the third party jar(like package restructuring or API changes) i'm using will have a minimal effect on my code.
i've read some design patterns but not very sure which will be what combination be helpful.i'm thinking of providing a kind of interface where instead of directly using the third part APIs, i need to make calls through this inerface, but not very sure.
please provide your inputs on implementing this.

thanks,<br />gaurav abbi
Frank Carver

Joined: Jan 07, 1999
Posts: 6920
It looks like you might be in search of the "facade" pattern. This suggests a way of inserting an isolating layer between two areas of a system. Once you have produced your facade, you can code "your" part of the application against that facade, and call the third-party code from the facade.

If/when the third-party software changes, you can then add conversion code to your facade, and give it aspects of the "adapter" pattern.

Read about me at ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Nageswar Kakolla
Ranch Hand

Joined: Jan 16, 2006
Posts: 71
Hi there,

If you are using 3rd party jars, then you must be using some API's related to that 3rd party jar. Define You own API and within this API, invoke 3rd party API. If 3rd party API changes, All you have to do is go to your user defined API definition and update 3rd party API or for that matter use different 3rd party jar API. In this way, Your application design wont change drastically if dependent jars change. I have done similary for Logging. Instead of invoking log4j API's directly, We have defined user defined logging within which log4j API's are inoveked. By this, Later, we can replace Log4j with JDK 1.5 logging or whatever.

I am not sure this follows a pattern rather approach for Design Encapsulation.

.. Nag
I agree. Here's the link:
subject: to remove dependency from third part jars
It's not a secret anymore!