CSC/ECE 517 Fall 2012/ch2a 2w16 dp: Difference between revisions
No edit summary |
|||
Line 68: | Line 68: | ||
<source lang="Java"> | <source lang="Java"> | ||
Class SampleAdapter implements ClientClass | Class SampleAdapter implements ClientClass | ||
{ | { | ||
private AdapteeClass mInstance; | private AdapteeClass mInstance; | ||
public SampleAdapter(final AdapteeClass INSTANCE) | public SampleAdapter(final AdapteeClass INSTANCE) | ||
Line 81: | Line 81: | ||
} | } | ||
} | } | ||
</source> | </source> |
Revision as of 21:16, 26 October 2012
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
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
}
}