removing dependency on third party jar changes
1 posts in topic
Flat View  Flat View
Older Post First |   Reply to Topic
TOPIC ACTIONS:
 

Posted By:   gaurav_abbi
Posted On:   Tuesday, November 6, 2007 04:17 AM

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 i   More>>


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.

   <<Less
Report | Quote This | Send private message | Reply | Print

Re: removing dependency on third party jar changes

Posted By:   Stephen_McConnell  
Posted On:   Tuesday, November 6, 2007 11:39 AM

There is a pattern called the Delegate pattern. What you do is wrap the third party's API's in a set of your own API's that deal with the functionality you need from the third party.


That way, if the third part API's change or archetecture changes, then the only classes you change are the way your API classes call the third party API's.


This is similar to the Data Access Object in accessing a database. With the DAO, If I change the database or use EJB's or Hibernate to access the database, all I have to do is change in one place.


Good for you for looking ahead at a potential problem. I've dealt with so many Project managers that say "OH WE'LL NEVER CHANGE OUR DATABASE, or OUR USE OF THIS THIRD PARTY APPLICATION." Then, a couple of months later, they are crying because the third party app went away or the Database changed...


Hope this helps.


Stephen McConnell

Report | Quote This | Send private message | Reply | Print
About | Sitemap | Contact