Design patterns are the well-known solution to recurring problems, and the software development community has widely accepted them. Now the question comes, why do we follow design patterns rather than designing our solutions.
Introduction
We know that software development started a long time back. Gradually, development processes have been improved to cater to various difficulties different engineers face on the projects in different environments and use-cases. These difficulties are modification in the existing code base, an extension of existing code to incorporate new requirements, scalability issues in the developed solution, integration of different tasks, modules, subprojects, etc.
Moreover, there is no point in reinventing the wheel when already well-experienced people have learned and evolved the designing processes.
It is a mandatory requirement for an expert software engineer to know the basics of design patterns. It is like a vocabulary through which communication can be established at a module-level task level, subproject level, etc.
Well-experienced people are there in the industry. They improved and enhanced their knowledge from past experiences. Design patterns provide well-proven structures for systematic reuse of best design ideas rather than thinking and designing our approach for every problem. Consequently, it significantly lowers the cost of design and development and produces a refined product.
There are many reference books that we can follow to understand the design patterns. A few of them are listed below:
- Design patterns: Elements of Reusable Object-Oriented Software
Design Patterns – Characteristics
- Design patterns are often language-neutral and mostly applicable for object-oriented programming languages.
- Design patterns are dynamic as these patterns are often enhanced based on the need.
- Design patterns are incomplete by design to promote customization.
Design Patterns – Types
Design patterns are broadly classified into three types, and these are as follows: Creational, Structural, and Behavioral.
- Creational Patterns: It is used to create objects systematically to attain flexibility. Creational patterns exploit polymorphism.
- Structural Patterns: It is used to establish relationships between software components to accomplish functional and non-functional requirements. The main difference between functional and non-functional requirements is that the functional requirements map to what software does, and non-functional requirements measure how well it completes the job. The main focus here is to map different goals with different structures. Moreover, structural patterns exploit inheritance.
- Behavioral Patterns: It is used to make the objects interact. It accomplishes both functional and non-functional requirements. The primary focus is to design the protocols between objects trying to work together to achieve a common goal. Moreover, behavioral patterns exploit methods and their signatures.
The common OOPs concept is Interfaces used across all the design pattern types such as creational, structural, and behavioral patterns.
Design Patterns – Context
The design patterns context plays a vital role in selecting a particular pattern. To use design patterns effectively, we must know the context in which design patterns work best. The pattern context consists of the following:
- Participants: Participants refer to the classes involved to form a design pattern. They play a different role in accomplishing the goals of the design pattern.
- Quality attributes: It refers to non-functional requirements such as usability, modifiability, reliability, performance, and so on. The quality attributes have an impact on the entire software. Architectural solutions address them.
- Forces: The various factors or trade-offs to consider when adopting a particular design pattern. Quality attributes manifest forces, and if we don’t reason about these forces very well, we would be likely to face some unintended consequences.
- Consequences: These consequences could be worse performance when we try to use one of the design patterns. So knowing when to use and when not to use is crucial, specifically as they can cause more problems than solving them when they are misused. After thoroughly considering its consequences, the ultimate responsibility falls on the decision-makers who are expected to choose a design pattern.
Design Patterns – Language
- Mastering the terms used to describe design patterns is like learning a new language. Therefore, we can safely say that these terms constitute a pattern language. A pattern language consists as follows:
- Name The name of a pattern capture the gist of each pattern. These names will be an essential vocabulary during the design process. Therefore, the pattern name should be meaningful and memorable.
- Context: The context provides a scenario in which we may use these patterns. It also offers more insights on when and where to use the pattern.
- Problem: It describes a design challenge a pattern is addressing.
- Solution: It specifies a pattern in terms of structure and behavior. The structure specifies the relationship among the elements used in the pattern. At the same time, behavior determines the interactions among the pattern elements.
- Related patterns: These list other patterns and use the pattern described or similar patterns together. In these related patterns, the section of the pattern language is crucial to precisely describe the subtle differences between the patterns.
References
- Design Patterns in Python by Dmitri Nesteruk
- Python Design Patterns by Jungwoo Ryoo
CITE THIS AS:
“Python Design Patterns – Introduction” From NotePub.io – Publish & Share Note! https://notepub.io/notes/software-engineering/python-design-patterns/introduction-dp/
12,138 total views, 1 views today
