Introduction to design patterns PART 1

Overview

This is the first post from a series in which I will dive into the topics of design patterns. My purpose is to clarify what are design patterns and how to use them. The following topics will be covered:

1. Design pattern introduction
   
   • What is a design pattern?
   • When to use a design pattern.
   • Finding a pattern.
   • How to use a pattern.
   • How to read and understand a class diagram.
   • Example – applying design patterns.
2. Creational patterns – Abstract Factory.
3. Creational patterns – Builder.
4. Creational patterns – Abstract Factory vs Builder.
5. Structural patterns – Adapter.
6. Structural patterns – Facade.
7. Behavioral patterns – Observer.
8. Behavioral patterns – Template Method.

What is a design pattern?

Christoper Alexander says:

Each pattern describes a problem which occurs over and over again in our environment and the describes the core solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice

In more simpler words a pattern is a general solution to a common occurring problem.

According to the “Gang of four” the following parts describe a pattern:

1. The pattern name – a handle to describe the problem.
2. The problem – describes when to apply the pattern and its context.
3. The solution – describes the elements that make up the design and the relationships between them.
4. The consequences –  describe the result and trade off of applying the patterns.

In programming a design pattern shows how classes and objects interact to solve a common design problem.

Design patterns can be grouped in 3 categories based on there purpose:

• Creational – deal with object creation.
• Structural – deal with composition of classes and objects.
• Behavioral – characterize the way in which objects and classes interact.

When to use a design pattern

My advice before selecting a design pattern would be to think if you really need to use a design pattern. Patterns are powerful tool for developers but as we know “With Great Power Comes Great Responsibility” (Voltaire or Uncle Ben I am not sure ho said it first).

When I develop I start with respecting the Clean Coding principles (for more information i recommend Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martin) then I want to respect the SOLID principles(here is the link from Wikipidea). If I have problems and cannot respect SOLID principles or other design problems I think how can I refactor the code: extract class, remove middle man etc(more information you can find on SourceMaking). If I still have problems like: dependencies on hardware or software platform, dependence on specific operations etc,only after this I search to see if I can apply a pattern.

!!!!!Attention: Always think before applying any of the steps mentioned before. When you apply a clean coding rule/ SOLID principle/etc think about why you apply it and what are the pros and cons of that rule/principle etc. Do not apply them blindly.

Finding a pattern steps

1. Identify the problem you want to solve (more information in Design Patterns: Elements of Reusable Object-Oriented Software Chapter 1 Designing for change).
2. Identify the family of patterns that help solve this problem(creational, structural or behavioral).
3. Scan the intent section of each pattern and find the pattern that helps remove the cause of redesign.
4. Study the pattern description.
5. Examine the reason of redesign (what problem does the pattern solve).
6. Consider what should be variable in your design( the components that you can change often without to redesign).

Applying a design pattern

1. Get on overview of the pattern.
2. Understand the structure of the pattern (UML diagram of the pattern).
3. Search for examples(before/after etc)
4. Choose names for pattern participants:
   • Determine which classes of your code will be affected by the pattern.
   • Find suggestive names for the classes.
5. Define the interfaces and classes.
6. Define application names for method and members for the method participants.
7. Implement the methods that carryout the responsibility in the pattern.

Understanding UML class diagrams

I will present a simplified overview of the class diagrams in order to help the future understanding of the presented design patterns (so please UML evangelist don’t get mad).

According to Visual Paradigm a class diagram is a:

Type of static structure diagram that describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects.

So a UML class diagram consist of:

• A set of classes interfaces, abstract classes etc.
• The relations between them.

Classes in UML consist of:

• Name
• Attributes : data members
• Operations: methods.

The classes have the following format:

For this series we will discuss the following relationships :

• Generalization/Specialization
• Realization
• Association, Aggregation, Composition
• Dependency.

Generalization/Specialization

Generalization – extract shared characteristic of two or more classes.

Specialization – create a new subclass from an existing class (the reverse process of generalization).

In the diagram above:

• Priest and Fighter are specializations of Character (create sub classes from Character super class that implement specific operations and attributes)
• Character is a generalization of Priest and Fighter (create Character class that contains the shared attributes and operations from Priest and Fighter)

In the case of OOP languages generalization is done through inheritance. In the case above Priest and Fighter inherit from Character.

Note:For more information on this topic please read this post.

Realization

Is a relationship between two elements: the specification and the implementation.

A simple and common example is when you implement an interface. (the interface represents the specification).

In the above class diagram The Command interface specifies the contract that has to be implemented by each class that derives from it. OpenFile and SaveFile will represent actual implementations of the Command interface.

Note: detailed information can be found here.

Association, Aggregation, Composition

Association

According to Visual Paradigm

If two classes in a model need to communicate with each other, there must be link between them, and that can be represented by an association (connector).

So basically an association represents a relationship between two objects.

In the first diagram a doctor can consult one or multiple patients.

In the second diagram a patient can go to one or multiple doctors.

Note: Aggregation and Composition are subsets of Association.

Composition

An object(parent) manages the lifetime of another(child). The child cannot exist without the parent.

The stamp lifetime is determined by the doctors lifetime.

Aggregation

The child can exists independently of the parent. If you delete the parent the child can still exists.

The Hospital employs the doctor but the doctor’s lifetime is not managed by the hospital.

Dependency

Changes in a model element trigger changes in another model element. In our case changes in one class trigger changes in another class. This a more general relationship and it includes all of the above.

Next Post

In the next post we will try to refactor an existing code and see what problem cause us to find a design pattern. You can find the post here.

Thank you for reading. If you liked this post please share it. Also if you have any observations please specify them in the comment sections.