Design Patterns : Bridge

Bridge decouples the abstraction from implementation so that the two can vary independently.

Client which uses the classes inheriting the abstraction need not know about the service implementations.Bridge pattern abstracts the implementations’ interface from the application.
An example ? Consider database drivers. Removing the dependency from database vendors from the systems provides more flexibility.

Inheritance is a common way to specify different implementations of an abstraction. However, the implementations are then bound tightly to the abstraction,and it is difficult to modify them independently. The Bridge pattern provides an alternative to inheritance when there is more than one version of an abstraction.The Bridge Pattern is classified as a structural design pattern.This pattern helps to hide the implementation details giving more encapsulation.As the interface implementations and abstractions are decoupled , they can have hierarchies.Changing an implementation needn't require any compilation of abstractions or its clients.This provides a better layering structure than having the traditional abstract implementation of parent interfaces.

Sample Code:
http://bytescrolls-samples.googlecode.com/files/bridge-design.zip

More:
http://en.wikipedia.org/wiki/Bridge_pattern

A note on anemic antipattern

In the object oriented principles POJOs or java objects represent data.Some people do write business logic along with the data objects.The objects do represent the real world object as it is named according to business nouns.The anemic anti-pattern describe the use of a domain model where the business logic is implemented outside the domain objects. The antipatterns help us to understand what are bad practices.These pitfalls are to be avoided.There is a fundamental mismatch with the OOP concepts explained by Martin Fowler in his article . With this pattern, logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts.It decouples the binding using a separate business layer to contain the logic.When we use hibernate-like persistance layer, most of the objects are basically attribute beans.The businesss logic will reside in a layer in which the process is spread between these objects.A service layer on top of domain layer or models is used when domain model impelementing multiple interfaces for data storage and logic.The service layer is not supposed to serve as a business logic provider/container, but rather as an access / synchronization layer, to allow for radically different interfaces access to your domain model.Ideally, the domain object would contain behavior to handle its own persistence. If domain objects offered such behavior, then the service object could deal directly with the domain object in a very object-oriented way. Instead of telling a DAO to persist a customer, the service would tell the customer to persist itself. There will still be a DAO, but the domain object will do its own dealing with the DAO, unbeknownst to the service object. In effect, the domain object and the DAO swap positions with relation to the service object.The attributes are provided by POJOs and the behaviours are provided by service layer. These forms the basis of domain driven design.I believe that in Anemic Domain Model the behavior is implemented in separate classes increasing the lines-of-code in the application layer and it also makes the application code less maintainable since the use of domain objects is no more logical.But the loosely coupled nature could provide more benefits of relationsgips,encapsulation,simplicity,readable,more functional support and so on.These are mere analysis in my perspective, hope I could add much more knowledge about this in future.