Design Patterns Overview

Design Patterns

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Uses of Design Patterns

  • Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
  • Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
  • In addition, patterns allow developers to communicate using well-known, well-understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

Object-oriented design principles

Before reading design patterns, I suggest to read some useful oops design principles:
  • Encapsulate what varies.
  • Code to an interface rather than to an implementation
  • Delegation principle
  • The open closed principle (OCP)
  • DRY- Don't Repeat Yourself 
  • Single Responsibility Principle (SRP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Injection or Inversion principle
Read more detail about object-oriented design principles in my post.

How to Use a Design Pattern

Let's discuss a step-by-step approach to applying a design pattern effectively:

1. Read the pattern once through for an overview. Pay particular attention to the Applicability and Consequences sections to ensure the pattern is right for your problem.

2. Go back and study the Structure, Participants, and Collaborations sections. Make sure you understand the classes and objects in the pattern and how they relate to one another.

3. Look at the Source Code section to see a concrete example of the pattern code. Studying the code helps you learn how to implement the pattern.

4. Choose names for pattern participants that are meaningful in the application context. The names for participants in design patterns are usually too abstract to appear directly in an application. Nevertheless, it's useful to incorporate the participant name into the name that appears in the application. That helps make the pattern more explicit in the implementation.
For example, if you use the Strategy pattern for a text compositing algorithm, then you might have classes SimpleLayoutStrategy or TeXLayoutStrategy.

5. Define the classes. Declare their interfaces, establish their inheritance relationships, and define the instance variables that represent data and object references. Identify existing classes in your application that the pattern will affect, and modify them accordingly.

6. Define application-specific names for operations in the pattern. Here again, the names generally depend on the application. Use the responsibilities and collaborations associated with each operation as a guide. Also, be consistent in your naming conventions. For example, you might use the"Create-" prefix consistently to denote a factory method.
7. Implement the operations to carry out the responsibilities and collaborations in the pattern. The source code section offers hints to guide you in the implementation. 

Organizing the Catalog

Design patterns are organized into Creational, Structural, or Behavioral purpose.
  • Creational patterns concern the process of object creation. 
  • Structural patterns deal with the composition of classes or objects. 
  • Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility. 

Creational design patterns

  • Creational patterns involve object instantiation and all provide a way to decouple a client from the objects it needs to instantiate.
  • This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.
      Click to read creational design patterns.

Structural design patterns

  • Structural pattern let's compose classes and objects into larger structures.
     Click to read structural design patterns.

Behavioral design patterns

  • Behavioral pattern is concerned with how classes and objects interact and distribute responsibility.
  • These design patterns are all about Class's objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.
      Click to read behavioral design patterns.

    References

      Comments

      Post a Comment

      Popular posts from this blog

      Design Patterns used in Hibernate Framework

      Image
      In this post, let's discuss a different kind of design patterns which are widely used in the Hibernate Framework. Design Patterns denote the best computer programming practices in the object-oriented software development. Hibernate framework has been built by using the following design pattern or standard practices. I list few known design patterns used in Hibernate Framework. Please mention in a comment, if you know any other design patterns used in Hibernate Framework. You can also read my post of  Design Patterns used in Spring Framework Domain Model Pattern The domain model is treated as POJO in Hibernate. The domain model is an object model of the domain that incorporates both behavior and data. Read more about Domain Model Pattern here https://stackoverflow.com/questions/41335249/domain-model-pattern-example Proxy Design Pattern Proxy Pattern for lazy loading - https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html Proxy Pattern provides a surrogate or pl
      Read more

      Data Mapper Pattern

      Image
      This pattern belongs to  Data Source Architectural Patterns  Catalog and this Catalog belongs to  Patterns of Enterprise Application Architecture . Intent A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself. Mapper means an object that sets up a communication between two independent objects. Applicability Use the Data Mapper in any of the following situations when you want to decouple data objects from DB access layer when you want to write multiple data retrieval/persistence implementations Explanation The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other.  With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema.  How It Works The separation betwee
      Read more

      Information Expert GRASP Pattern

      Image
      Information Expert is the  GRAS Patterns (General Responsibility Assignment Software Pattern) Read about GRASP Patterns:  GRASP Patterns Overview Problem What is a general principle of assigning responsibilities to objects? A Design Model may define hundreds or thousands of software classes, and an application may require hundreds or thousands of responsibilities to be fulfilled. During object design, when the interactions between objects are defined, we make choices about the assignment of responsibilities to software classes. Done well, systems tend to be easier to understand, maintain, and extend, and there is more opportunity to reuse components in future applications. Solution Assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility. Example   Let's consider Point of Sale (POS) application: a Brief overview of POS application. Application for a shop, restaurant, etc. that registers sales. Each sale is of one
      Read more