Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Java Design Patterns: Proven Solutions to Common Problems : Page 2

Design patterns not only provide proven solutions to common development issues, they also make communication between developers and designers more efficient.


advertisement

The Structure of Java Design Patterns

Design patterns vary in their level of abstraction. There are many design patterns, so it helps to organize them. The sections to follow classify design patterns so that developers can refer to the appropriate patterns. Through this classification, it's easy to identify as well as incorporate new patterns.

In 1995, software professionals Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides (also known as the Gang of Four or simply GoF) published a book titled Design Patterns. This book is considered the bible or "Gita" of design patterns to the software community at large and it has been very influential in the evolution of design patterns.



Design Patterns described 23 patterns based on the experience of the authors at that time. Today, some 250 or more design patterns are used in the object-oriented world. To organize them, the GoF established three design pattern categories:

  • Creational patterns
  • Structural patterns
  • Behavioral patterns

A creational pattern prescribes the way that objects are created. These patterns are used when a decision must be made at the time a class is instantiated. Typically, the details of the classes that are instantiated -- what exactly they are, how and when they are created, and so on -- are encapsulated by an abstract superclass and hidden from the client class, which knows only about the abstract class or the interface it implements. The specific type of the concrete class is typically unknown to the client class.

Structural patterns prescribe the organization of classes and objects. These patterns are concerned with how classes inherit from each other or how they are composed from other classes. Common structure patterns include adaptor, proxy and decorator patterns. These patterns are similar in that they introduce a level of indirection between a client class and the class it wants to use. Their intents are different, however.

The adaptor patterns uses indirection to modify the interface of a class to make it easier for a client class to use. The decorator pattern uses indirection to add behavior to a class, without unduly affecting the client class. The proxy pattern uses indirection to transparently provide a stand-in for another class.

Behavioral patterns prescribe the way objects interact with each other. They help make complex behavior manageable by specifying the responsibilities of objects and the ways they communicate with each other.

I further categorize design patterns using two criteria: Scope and Purpose. Scope specifies whether a pattern applies primarily to a class or its objects. Class patterns deal with the relationship between classes and their subclasses. Relationships are initiated through inheritance, so they are fixed at compile time. Objects deal with object relationships, which can change at run time. Almost all patterns use inheritance, so those patterns focus on pure class patterns -- patterns I labeled under class.

Purpose explains what a pattern does. Creational patterns concern the process of object creation. Structural patterns deal with the composition of classes or objects. Behavioral patterns characterize the way in which a class or object interacts and is distributed. See Figure 1 for a table of design pattern structures.



Click here for larger image

Figure 1. Design Pattern Structures

Source: Design Patterns: Elements of Reusable Object-Oriented Software

There are other ways to organize patterns. Some patterns result in similar designs even though they have different intents. You can also pass reference to other patterns to meet your requirements. Figure 2 shows design patterns' relationship with each other.



Click here for larger image

Figure 2. Design Pattern Relationship

Source: Design Patterns: Elements of Reusable Object-Oriented Software



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap