CSC/ECE 517 Fall 2012/ch2a 2w16 dp
Adapter Design Pattern
In computer programming, the adapter pattern (often referred to as the wrapper pattern or simply a wrapper) is a design pattern that translates one interface for a class into a compatible interface.
Introduction
An adapter allows classes to work together that normally could not because of incompatible interfaces.It “wraps” its own interface around the interface of a pre-existing class. It may also translate data formats from the caller to a form needed by the callee.
Adapter pattern is also used to translate calls made by a user to any wrapped interface. e.g. for efficiency, a data structure may be used to store multiple values in it. but it becomes difficult for the user to understand them and edit them, so the adapter class may simplify the call to the wrapped class, and provide users with only the variables/methods that he might be interested in. Another scenario where adapter patterns may be used is that in a system, different users may be given different access level depending of their classification, so instead of changing the whole design, a number of adapter classes will do the work, instead of modifying the whole design.
This added layer given between two interfaces decreases cohesion among modules. if there are lots of interfaces interacting with an interface(one to many), adding an adapter class in between is advisable, as change in the base class will not introduce change in all caller classes, but only in adapter class.
The main use of this pattern is when a class that you need to use doesn't meet the requirements of an interface. Adapters are common across Eclipse plug-ins. For a particular object to contribute to the Properties view, adapters are used display the objects data. The view itself doesn't need to know anything about the object the it is displaying properties for.
Adapter pattern is also very useful during development phase of any software. since the high level modules need not know the details of the low level modules, after a common interface for the adapter class is decided, work on the low level and the high level modules can be started in parallel.
Properties of adapter pattern
Delegation: Delegation is basically delegating a task to another part of program. Adapter pattern uses this property as described in the above example,, wrapper class may perform some operations on the values returned by wrapped class before forwarding it to the caller method. The advantage of this is that the view has no idea about how the model/controller is working. If we have to make changes to any of the business logic, we need not change the view. we only need to make appropriate changes to the wrapper class.
Dependency Inversion Principle This is another principle that adapter pattern uses. It refers to a specific form of decoupling relationship dependency from high-level modules to low level modules are inverted so that high level modules are independent of the implementation of low level modules. There are two important ideas this principle is based on: A) High level modules should not depend on low level modules, and vice versa. Both of these should depend on the abstraction.
This means that there should be middle layer in between that acts a common interface between the two levels of modules. this provides a very good way of decoupling them and thus changes in any level need not lead to changes at the other level. This will also lead to re-use principle as low-level as well as high level modules can be made generic and not application specific.
Patterns similar to Adapter design
Facade Design Pattern
The name of the pattern itself provides a hint of as to what it might be referring to. Facade means the face of the building. The people walking past the road can only see this glass face of the building. They are completely unaware of the wiring, the pipes and other complexities. The face hides all the complexities of the building and displays a friendly face. More technically, it hides the complexity of the system from the client and allows the client to interact with it via an interface. JDBC can be said to be an example of facade pattern in Java.A user or programmer is like a client who simply uses the “java.sql.Connection” interface to create a connection without bothering about its implementation. The implementation is left to the vendor of the driver. Some common situations in which the facade pattern can be used: A system has several identifiable subsystems and:
The abstractions and implementations of a subsystem are tightly coupled. The system evolves and gets more complex, but early adopters might want to retain their simple views. You want to provide alternative novice, intermediate, and "power user" interfaces. There is a need for an entry point to each level of layered software.
Decorator Design Patterns
The decorator pattern is a pattern that allows additional behavior to be added to existing object dynamically. The important point here is that this new feature can only be added dynamically at runtime, and not at compile time. Another important point to notice here is that the extended feature can be added to a particular object, i.e. we can use this pattern to extend features of a single instance of an object and not all the instances. We can also stack multiple decorators on top of one another, therefore overriding methods.
Decorator functionality can be obtained by following these simple steps:
Subclass the original "Decorator" class into a "Component" class (see UML diagram); In the Decorator class, add a Component pointer as a field; Pass a Component to the Decorator constructor to initialize the Component pointer; In the Decorator class, redirect all "Component" methods to the "Component" pointer; and In the ConcreteDecorator class, override any Component method(s) whose behavior needs to be modified
Comparisons
Adapter and Facade
To many people, these two patterns appear to be similar.
- They both act as wrappers of a preexisting class
- They both take an interface that we don’t need and convert it to an interface that we can use
But there are some subtle differences: An adapter solves the issue of incompatible interfaces while Facade defines a higher-level interface that makes the subsystem easier to use.Facade defines a new interface, whereas Adapter uses an old one. Adapter makes two existing interfaces work together as opposed to defining an entirely new one. Adapter and Facade are both wrappers; but of different kinds. The intent of Facade is to produce a simpler interface, while the intent of Adapter is to add design to an existing interface. While Facade routinely wraps multiple objects and Adapter wraps a single object; Facade could front-end a single complex object and Adapter could wrap several legacy objects.
To summarise we can say that an adapter “converts” while a facade “simplifies”.
Adapter and Decorator
Adapter Pattern provides a different interface to the object it adpats , whereas decorator changes the objects’s responsibilities or simply provides an enhanced interface to the subject.
In comparison to the Adpater pattern the Decorator pattern is more transparent to the client.
Another difference between Adpater and Decorator is that Decorator supports recursive composition, which is not possible with pure Adapter
Implementation of Adapter pattern
When implementing the adapter pattern, for clarity use the class name Template:Java, for example Template:Java. It should have a constructor method with adaptee class variable as parameter. This parameter will be passed to the instance member of [AdapteeClassName]To[Interface]Adapter.
Class SampleAdapter implements ClientClass
{
private AdapteeClass mInstance;
public SampleAdapter(final AdapteeClass INSTANCE)
{
mInstance = INSTANCE;
}
@Override
public void ClientClassMethod()
{
// call AdapteeClass's method to implement ClientClassMethod
}
}