Design Patterns - Types and suggested Precepts

What are Design Patterns?

Design Patterns are basically a catalog of common interactions between objects. These interactions have been found, tested/tried, and optimized by skilled programmers to help others in solving some of their very common programming problems in an efficient way. Design Patterns simply illustrate how objects can communicate with each other without being much concerned about their individual data models and methods. This clear separation helps building robust and scalable design solutions to various programming problems. If you've already made this separation in your code (which is highly possible in Object Oriented Dev) then you're already using some of the widely used Design Patterns.

There are various formal definitions of Design Patterns and almost all of them convey the same message. Find below one such popular definition given by Gamma, et al., 1993.

“Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.”

What are Communication Patterns?

Design Patterns do discuss design of objects as well, but what makes them even more important is that they describe an elegant and efficient methods of communication between the involved objects and this is the reason why Design Patterns are also referred to as Communication Patterns.

How many Design Patterns are currently available?

There is no fixed answer to this question. The original Design Patterns book included 23 design patterns and these are the most widely used patterns having several known applications using them. But, we currently have hundreds of Design Patterns documented/presented in some form or the other and many of them have already gained a good popularity. There are few which are suitable only for some very specific problems and hence not so popular. These Design Patterns are applicable at many levels ranging from very low level specific problems to general system-wide problems. Understanding of these Design Patterns may become extremely beneficial in designing solutions as they have been found/tested/tried by experts and it's highly unlikely that most of us will come up with a better design on the fly.

Types of Design Patterns

The authors of the original Design Pattern book deivided the 23 patterns into three categories based on what actually the patterns do in a design solution. These categories are:-

• Creational - the design patterns belonging to these category are used for creating objects. Using such a design pattern provides more flexibility where we require a control over the creation of objects. One very common use case is the usage of a creational design pattern to restrict the total number of instances of a class. Example: The Singleton Pattern, The Abstract Factory Method Pattern, etc. Read more - Creational Design Patterns & their Examples >>
• Structural - as the name suggests this category groups all those design patterns which help the user to group objects into larger structures to meet the complex requirements in a structured way. A common use case is to use such a design pattern for designing a complex user interface. Example: The Adapter Pattern, The Proxy Pattern, etc. Read more - Structural Design Patterns & their Examples >>
  
• Behavioral - the patterns belonging to this category are used to define communication between objects of a proposed solution. In other words such design patterns helps defining the flow of a complex system. Example: The Chain of Responsibility Pattern, The Strategy Pattern, The Iterator Pattern, etc.

What do Design Patterns suggest for Object Oriented programming?

The goal of Design Patterns (as discussed in the first section of the article) is to maintain a clear separation between classes so that they need to know (and hence depend) very little on each other. Object Oriented Programming has two popular mechanisms of enforcing separation which are: Inheritance and Encapsulation. Based on these two separation mechanisms Design Patterns suggest two important precepts which are:-

Programs should be based on Interface and NOT on implementation - If you're using inheritance then you may have unnecessary access to other methods/members of the base class and you may keep carrying all that extra load throughout the inheritance chain and this may subsequently cause many undesirable issues especially when the inheritance chain the underlying system becomes large and complex. You can avoid such a potential issue by having an abstract class at the top of the hierarchy and having the specific implementation in the corresponding sub classes only.

Composition should be preferred over Inheritance - does it seem contrary to the customs of Object Oriented Programming Methodology? Well... it isn't actually. Interitance may cause some undesirable side-effects in certain cases whereas Composition is usually (or probably always) pretty safe to use without worrying about any possible side-effects even when the classes evolve to newer versions which may not be the same in case of Inheritance.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.