A very appropriate example from JDK itself is the JDBC. JDBC is an abstraction over database-access mechanisms. While a developer is not at all exposed to the nitty-gritties of as to how the databse specific driver classes internally connect to and read data from the database.

All well defined objects are facades in a sense. They encapsulate their data and and the actual implementation from the callers and provide services as an abstraction. For example, a Stack object lets the caller push and pop objects without worrying about how it is implemented internally.

The Facade pattern extends the same concept to a higher level. Here, the entire complex inner-workings of a subsystem are encapsulated and a simple abstraction is presented to the outer world as the facade.

The whole JDBC mechanism in Java can be considered a facade. The caller will do something as simple as

PreparedStatement.executeUpdate()

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.

For example when the client wants to ship a order in a order management system. Ordering involves calls to multiple classes. This calls can be encapsulated in a facade. The client can then invoke the facade method so that the overall complexity in getting the job done will be reduced. All the complicated logic will reside in the facade. Any future changes in the logic entils to change only in the facade and not in the client.