This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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.
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.