Adapter Pattern

In this week’s lecture we covered the Adapter Pattern. In this blog I give an overview of the Adapter Pattern and my opinion about it.

An Adapter Pattern is one of the structural patterns by GOF. Its used in situation where you have one class that you wish to reuse, but the application interface does not match the class interface.[1] The Adapter is therefore used to convert the application interface to the existing class interface. Put simply, the Adapter maps the interface of one class to that of another.

I especially like the example of an electric socket that was used in class to explain the adapter pattern.

How the Adapter pattern works

A Client wants to invoke the method request() in the Target interface. Since the Adaptee class has no request() method, it is the job of Adapter to convert the request to an available matching method. Here the Adapter converts the method request() call into the Adaptee method specificRequest() call. The Adapter does this conversion for each method that needs adapting.

The two types of Adapter Patterns are:

1. Object Adapter Pattern(contains an instance of the class it wraps)
2. Class Adapter Pattern (using multiple inheritance)

From the class discussion, I think this is one of the most important patterns in software development.

With the Adapter Pattern, one does not have to change local objects, the adapter takes care of the job.

Beside, the adapter pattern reduces the creation of excessively heavy and low performance remote objects. Therefore lighter programmes can be developed.

Since adapter separated responsibilities along class lines, one produces a design that is easy to debug and code the in easier to read.

Like other patterns, once created, adapters can be used over and over again saving both effort and time.


Though adapter pattern provides the benefits highlighted above, I have noted a few issues with them.

I think one must be carefully when using the Adapter pattern. When the design of the Adapter is poor, even if the applications/interfaces that the adapter intends to adapt are good, the design of the adapter may negatively affect the overall performance of the classes involved.

The scope of adapting that an adapter does also needs to be considered. Rather than improving performance between the adapted class the adapter may compromise functionality of one of the classes hence affecting performance of both classes whenever they interface.


References

[1]
Dan Becker,
Design Networked Applications in RMI Using the Adapter Pattern,
A guide to correctly adapting local Java objects for the web
(5/01/99)
http://www.javaworld.com/javaworld/jw-05-1999/jw 05networked.html?page=1
Accessed: 16th March 2007

[2]
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Design Patterns,
Elements of Reusable Object-Oriented Software,
(1995)
Addison-Wesley
Page 139 – 150

[3]

James W Copper,
Java Design Patterns,
(2000)
Addison Wesley
Page 71 - 79

The Abstract Factory

Task 1 – Abstract Factory

In this lecture we looked at the Abstract Factory design pattern. In this blog I discuss my understanding of the Abstract Factory

Definition 1

Abstract Factory is a set of related abstract classes, the Abstract Factory pattern provides a way to create instance of those abstract class from a matched set of concrete subclasses. This pattern is useful for allowing a program to work with a variety of complex external entities such as different windowing systems with similar functionality.[1]

Definition 2

Abstract Factory pattern can also be defined as a design pattern that provide an interface for creating families of related or dependent objects without specifying their concrete classes.[2]

The link to reference [2] provides a good structure of the Abstract Factory together with the code.

In Abstract Factory, the client does not know (or care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage.

A good example of when the Abstract Factory should be used is when a system needs to support multiple look-and-feel for the user interface for example Windows 9x, Motif, and Macintosh. The same application will have different look and feel under different platforms without the need to change the core of the application.

A non software illustration of Abstract Factory design pattern

In the sheet metal stamping equipment used in the manufacture automobiles, the stamping equipment is an Abstract Factory. It creates auto body parts. The same machinery is used to stamp right hand doors, left hand doors, right front fenders, left front fenders, hoods, etc. for different models of cars. Through the use of rollers to change the stamping dies, the concrete classes produced by the machinery can be changed within three minutes. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54]

Advantages of using Abstract Factory

• The Abstract Factory isolates the concrete classes from the abstract classes that generated them. Because of the isolation of classes, you can change or interchange
  The product class families freely.

• Further, since one generates only one kind of concrete class, this system avoids from inadvertently using classes from different families of products.
  
  
  Disadvantages of using Abstract Factory
  
• There is nothing to prevent some derived classes from having
  additional methods that differ from the methods of other classes.
  
  
  Related Patterns
  
  1. Factory Method
  2. Singleton: Concrete Factory classes are usually implemented as Singleton classes
  
  Task 2
  
  Examining the Coursework and critiquing it.
  
  The lecturer asked us to examine the Coursework and critique it.
  
  The coursework has something for every one, both programmers and non-programmers. Task 1 can easily be handled by both programmers and non-programmer. Programmers may not have problems with Task 2 especially if Task 1 was well handled.
  
  However, in case Task 1 is not efficiently do, results in Task 2 may be badly affected. To attempt Task 2 would require one to have do Task 1 pretty well. It would also be difficult to do Task 2 without doing Task 1.
  
  It also put to use the skills previously learned for example the use of UML. One can therefore apply skills previously learned.
  
  The blog is quite an interesting one. From the blogs I have done so far and from commenting on other people’s blogs, I have learnt a lot about Design Patterns. It also makes the subject interesting. The blog is funny!!
  
  To understand patterns even better, the course work requires/covers anti-patterns. Being a subject about Patterns I had not expected to find Anti-patterns being mentioned at all. However studying patterns and anti-patterns gives an appreciation of the two concepts. One can there for better understand them.
  
  Task 3 further cements the understanding of Design Pattern by allowing students form complete patterns from a list of incomplete ones. This gives a practical dimensional to the subject which would have rather been too theoretical.
  
  However the word limit on the essay seems to be tight, given the kind of discussion this will be.

References:

[1] Mindspring.com
Overview of Patterns
(2007)
http://www.mindspring.com/~mgrand/pattern_synopses.htm#Abstract%20Factory
Accessed 2nd March 2007

[2] Data and Object Factory
Abstract Factory
http://www.dofactory.com/Patterns/PatternAbstract.aspx
(2007)
Accessed 2nd March 2007