Design patterns represent best practices and are generally adopted by experienced object-oriented software developers. Design pattern is a solution to the common problems faced by software developers during software development.
A design pattern is a set of repeated, well-known, catalogued code design lessons. Design patterns are used to reuse code, make it easier for others to understand, and ensure code reliability.
The importance of design patterns in project development has been self-evident, let’s go into the theme of design patterns
First, take a look at UML modeling, which provides the foundation for a better understanding of design patterns
Class diagrams in UML and relationships between class diagrams
Unified Modeling Language (UML) is a visual Modeling Language used to design software blueprints. In 1997, IT was adopted by OMG as an international standard for object-oriented Modeling languages. Its characteristics are simple, unified, graphical, can express the dynamic and static information in software design.
UML defines nine diagrams including use case diagram, class diagram, object diagram, state diagram, activity diagram, sequence diagram, collaboration diagram, component diagram and deployment diagram from different points of view of target system.
Classes, interfaces, and class diagrams
class
A Class is an abstraction of objects with the same attributes, methods and relations. It encapsulates data and behaviors. It is the basis of OOP and has three characteristics, namely encapsulation, inheritance and polymorphism.
Classes have class names, attributes, and methods. Here is an example representing a class diagram
No, name, school, age, and sex represent attributes, while display() represents methods.
interface
An Interface is a special class that has the structure of a class but cannot be instantiated. It can only be implemented by subclasses. Interfaces are commonly used to design relationships between classes
The phone interface above has two methods, either call() or receive().
The class diagram
A ClassDiagram is a static model that shows the classes, interfaces, collaborations in a system, and the static structures and relationships between them.
Relationships between classes
In a software system, classes do not exist in isolation, and there are various relationships between classes. Class diagrams in UML have the following relationships according to the coupling degree between classes from weak to strong: dependency, association, aggregation, composition, generalization, and implementation. Where the coupling degree of generalization and implementation is equal, they are the strongest.
- dependencies
Dependency relationship is a kind of usage relationship, which is the weakest way of coupling between objects, and is a temporary association. In code, a method of one class does something by accessing some method in another (dependent class) through local variables, method arguments, or calls to static methods.
In UML class diagrams, dependencies are represented by dotted lines with arrows that point from the using class to the dependent class, as in the following example
Modern people rely on mobile phones for communication and communication. In UML class diagrams, dependencies are represented by dotted lines with arrows that point from the using class to the dependent class
- correlation
Association is a reference relationship between objects, used to represent the relationship between one type of objects and another type of objects, such as teachers and students, teachers and apprentices, husbands and wives, etc. Association relation is the most commonly used relation between classes, which can be divided into general association relation, aggregate relation and combinatorial relation.
The association can be bidirectional or unidirectional. In UML class diagrams, bidirectional associations can be represented as solid lines with two arrows or no arrows, and one-way associations are represented as solid lines with an arrow pointing from the using class to the associated class. You can also annotate role names at both ends of the association line to represent two different roles.
For example, if the relationship between a teacher and students is many-to-many, a teacher can teach multiple students and a student has multiple teachers, a student can choose multiple courses at the same time, and the relationship between students and courses is many-to-many.
- The aggregation relationship
Aggregation is a kind of association relation. It is a strong association relation. It is the relation between whole and part, and it is the relation of HAS-A.
Aggregation relationships are also implemented through member objects, which are part of the overall object, but can exist independently of the overall object. For example, the relationship between the school and the teacher, the school includes the teacher, but if the school closes, the teacher still exists.
In UML class diagrams, aggregation relationships can be represented by solid lines with hollow diamonds that point to the whole
There will be more than one teacher in a school, but teachers will still exist without the school.
- Combination relationship
Composition relation is also a kind of association relation, which also represents the whole and part relation between classes, but it is a stronger aggregation relation, which is contains- A relation.
In combinatorial relation, the whole object can control the life cycle of some objects. Once the whole object does not exist, some objects will not exist, and some objects cannot exist without the whole object.
In UML class diagrams, composition relationships are represented by solid lines with solid diamonds that point to the whole
Wallet and money are a combination of the relationship, the wallet is the pocket of money, wallet lost money, so it is a combination of the relationship.
- Generalization relationship
Generalization relationship is the relationship with the maximum coupling degree between objects, and represents the general and special relationship, the relationship between the parent class and the subclass, and the Generalization relationship, which is the RELATIONSHIP of IS-A.
In UML class diagrams, generalization relationships are represented by solid lines with hollow triangular arrows that point from subclasses to parent classes. When the code is implemented, the object-oriented inheritance mechanism is used to realize the generalization relationship. For example, the Student and Teacher classes are subclasses of Person,
- Realize the relationship between
A Realization relationship is the relationship between an interface and an implementation class. In this relationship, the class implements the interface, and the operations in the class implement all the abstract operations declared in the interface.
In UML class diagrams, implementation relationships are represented by dashed lines with hollow triangular arrows that point from the implementation class to the interface.
For example, represents a Vehicle interface, which has a move method, there are two classes of Bike and Car respectively implemented Vehicle, then also implemented move() method
Principles of design patterns
After a brief UML modeling session, let’s talk about design principles. There are six design principles in design patterns
The Open Closed Principle
The core idea is open to extension, closed to modification. That is, changes to already used classes are made by adding code, rather than modifying existing code, to achieve a hot-plug effect.
For example, if you have a desktop theme on your phone, you can’t change an existing desktop theme. You can only download a new desktop theme from the Internet
Single Responsiblity Principle
The core of the single responsibility principle is to control the granularity of classes, decouple objects, and improve their cohesion. In what developers often call “high cohesion, low coupling”, each class should have only one responsibility, only one external function, and only one cause of class change.
For example, a class will have many class representatives, such as Chinese class representatives, math class representatives, English class representatives, etc., so the class representatives should only be responsible for the work of the class specific subjects, and the Chinese class representatives should not interfere in the work of math class representatives and English class representatives.
Liskov Substitution Principle
The principle of Li substitution holds that a subclass can extend the functions of the parent class, but cannot change the original functions of the parent class. That is to say, when a subclass inherits from the parent class, it should not rewrite the methods of the parent class except adding new methods to complete the new functions.
For example, birds have a fly() method, swallows are a bird, swallows inherit from birds and rewrite the fly() method, penguins are a bird, penguins inherit from birds but penguins can’t fly, which is equivalent to changing the function of birds, penguins can’t fly, so birds can’t fly
Dependency Inversion Principle
The core idea of the dependency inversion principle is to rely on abstractions and interfaces, not concrete implementations.
In essence, all classes in an application that use or depend on other classes should rely on their abstract classes or interfaces, not directly on their concrete classes. To implement this principle, we are required to program for abstract classes or interfaces rather than concrete implementations.
For example, when a woman goes to the mall, she may buy many things, not just one bag. She may also buy shoes, cosmetics and so on. So we can model goods
Interface Segregation Principle
It requires programmers to try to break up bloated interfaces into smaller, more specific interfaces that contain only methods of interest to customers.
The interface isolation principle and the single responsibility principle, both intended to improve the cohesion of classes and reduce coupling between them, embody the idea of encapsulation, but they are different:
- The single responsibility principle focuses on responsibility, while the interface isolation principle focuses on isolation of interface dependencies.
- The single responsibility principle is mainly a constraint class, which is targeted at the implementation and details in the program; The interface isolation principle mainly constrains interfaces and is aimed at abstraction and the construction of the overall framework of the program.
Principle of Least Knowledge
Demeter’s law is also known as the least cognitive principle. Its core idea is that one object should know as little as possible about other objects
In essence: reduce the coupling between objects, improve the maintainability of the system. Between modules, interface programming should only be used, ignoring the internal working principle of modules, which can minimize the coupling degree of each module and promote the reuse of software.
Take the circle of friends around us as an example. To determine the circle of friends, if two people have a common friend, their “likes” and “comments” in the circle of friends will be visible; if there are no common friends, they will not be visible to each other.
Twenty-three design patterns
Overview of Design patterns
- Design patterns represent best practices and are generally adopted by experienced object-oriented software developers.
- Design pattern is a solution to the common problems faced by software developers during software development. These solutions have been developed by numerous software developers over a long period of trial and error.
- A design pattern is a set of commonly used, well-known, catalogued code design experiences. ** Design patterns are used to make code reusable, easier to understand, and reliable.
- Design pattern is not a method and technology, but an idea.
- Design pattern is independent of specific language, learning design pattern is to establish object-oriented thinking, interface oriented programming as far as possible, low coupling, high cohesion, so that the design of the program can be reused.
- Learning design patterns promotes an understanding of object-oriented thinking and vice versa. They complement each other.
Types of design patterns
Generally speaking, there are 23 types of design patterns:
- Creation (5 types) : Factory pattern, Abstract factory pattern, singleton pattern, prototype pattern, Builder pattern
- Structural (7 kinds) : adapter mode, decorative mode, agent mode, appearance mode, bridge mode, combination mode, share mode
- Behavior mode (11) : template method mode, policy mode, observer mode, mediator mode, state mode, responsibility chain mode, command mode, iterator mode, visitor mode, interpreter mode, memo mode
Article Reference:
C.biancheng.net/view/1319.h…