Introduction to Design Patterns Part 1 Introduction to Design Patterns Chapter 1

There are two ways to classify design patterns, namely, according to the purpose of the pattern and according to the scope of the pattern.

1. Divide by purpose

Patterns can be divided into creation patterns, structural patterns and behavioral patterns according to what they are used to accomplish.

The creation pattern describes how objects are created. Its main feature is the separation of object creation and use. GoF provides five creation patterns: singleton, prototype, factory method, Abstract factory, and Builder.

Structural patterns: Used to describe how classes or objects are arranged into a larger structure. GoF provides seven structural patterns: proxy, adapter, bridge, decoration, facade, share, and composition.

Behavioral patterns: Describe how classes or objects work together to accomplish tasks that a single object could not accomplish alone, and how responsibilities are assigned. GoF provides 11 behavioral patterns, including template methods, policies, commands, chains of responsibility, states, observers, mediators, iterators, visitors, memos, and interpreters.

2. Divide according to scope of action

Patterns can be divided into class patterns and object patterns according to whether they are mainly used on classes or objects.

Class pattern: Used to deal with relationships between classes and subclasses, which are established by inheritance and are static and determined at compile time. Factory methods, (class) adapters, template methods, and interpreters in GoF belong to this pattern.

Object pattern: Used to deal with relationships between objects, which can be implemented through composition or aggregation, that can change at run time and be more dynamic. All but four of the above are object modes in GoF.

Table 1 describes the classification of these 23 design patterns

3. Features of GoF’s 23 design modes

The 23 categories of GoF design patterns were described earlier, and now the functionality of each pattern is described. Singleton pattern: Only one instance of a class can be generated. This class provides a global access point for external access to the instance. The extension is the finite-multiple pattern.

Prototype pattern: Use an object as a Prototype and clone it to create new instances similar to the Prototype.

Factory Method pattern: Defines an interface for creating products, and subclasses decide what products to produce.

AbstractFactory pattern: provides an interface to create a family of products, each subclass of which can produce a series of related products.

Builder pattern: Decompose a complex object into relatively simple parts, then create them separately according to different needs, and finally build the complex object.

Proxy mode: Provides a Proxy for an object to control access to that object. That is, a client indirectly accesses an object through a proxy to restrict, enhance, or modify some of its features.

Adapter pattern: Converts the interface of one class into another interface that the customer expects, making classes that would otherwise not work together due to interface incompatibility work together.

Bridge pattern: Separate the abstraction from the implementation so that they can vary independently. It is realized by using combinatorial relation instead of inheritance relation, thus reducing the coupling degree of abstraction and realization of these two variable dimensions.

Decorator pattern: Dynamically add some responsibility to an object, that is, add additional functionality.

Facade pattern: Provides a consistent interface to multiple complex subsystems, making them more accessible.

Flyweight pattern: Sharing techniques are used to efficiently support reuse of large numbers of fine-grained objects.

Composite pattern: Groups objects into a tree-like hierarchy, giving users consistent access to individual and Composite objects.

TemplateMethod pattern: define the skeleton of an algorithm in an operation and defer some steps of the algorithm to subclasses so that subclasses can redefine specific steps of the algorithm without changing the structure of the algorithm.

Strategy pattern: A series of algorithms are defined and each algorithm is encapsulated so that they are interchangeable and the change of the algorithm does not affect the customers using the algorithm.

Command pattern: Encapsulates a request as an object, separating the responsibility for making the request from the responsibility for executing the request.

Chain of Responsibility pattern: Requests are passed from one object in the Chain to the next until the request is responded to. In this way, objects are decoupled.

State mode: Allows an object to change its behavior when its internal State changes.

The Observer pattern: There is a one-to-many relationship between objects. When one object changes, the change is notified to the other objects, thereby affecting the behavior of the other objects.

Mediator mode: Define an intermediary object to simplify the interaction between the original objects, reduce the degree of coupling between the objects in the system, so that the original objects do not need to understand each other.

The Iterator pattern: Provides a way to access a series of data in an aggregate object sequentially without exposing the internal representation of the aggregate object.

Visitor pattern: Provides multiple access to each element in a collection without changing the collection elements, that is, multiple Visitor objects for each element.

Memento pattern: Retrieves and saves the internal state of an object so that it can be restored later without breaking encapsulation.

The Interpreter pattern: Provides the grammar of how to define a language and the method of interpreting language sentences, called the Interpreter.

【 Note 】 These 23 design patterns do not exist in isolation, many of them are related to each other, and multiple design patterns are often used simultaneously in large system development. Of course, we’ll also discuss another class of design patterns: the J2EE design pattern.

Table 2.

Figure 1 Relationships between design patterns

The Open Closed Principle (OCP) was developed by Bertrand Meyer, In his 1988 book Object Oriented Software Construction, he proposed: Software entities should be open for extension, but closed for modification. This is the classic definition of the open closed principle.

The open closed principle means: open for extensions, closed for modifications. When the program needs to be extended, you cannot modify the original code to achieve a hot plug effect. In short, to make the program extensible, easy to maintain and upgrade. To achieve this, we need to use interfaces and abstract classes, which will be discussed later in the concrete design.

The software entity here consists of the following parts:

The project divides the module into a program which acts according to the interface principle

The function of the open close principle

The open and close principle is the ultimate goal of object-oriented programming, which makes software entities have certain adaptability and flexibility as well as stability and continuity. Specifically, its functions are as follows:

1. Impact on software testing If the software follows the open and closed principle, only the extended code needs to be tested during software testing, because the original test code still works properly.

2. Can improve the reusability of code the smaller the granularity, the greater the likelihood of reuse; In object-oriented programming, programming according to atoms and abstractions can improve code reusability.

3. Can improve the maintainability of software to comply with the open and closed principle of software, its high stability and continuity, thus easy to expand and maintain.

The implementation method of the open and closed principle can be realized by “abstract constraints and encapsulate changes”, that is, by defining a relatively stable abstraction layer for software entities through interfaces or abstract classes, and encapsulating the same variable factors in the same concrete implementation class.

Because abstraction has good flexibility and wide adaptability, as long as abstraction is reasonable, it can basically maintain the stability of software architecture. The changeable details in software can be extended from the abstract implementation class. When the software needs to change, it only needs to derive an implementation class to extend according to the requirements.

The following uses Windows desktop themes as an example to describe how to apply the on/off rule. Windows desktop theme design. Analysis: A Windows theme is a combination of elements such as desktop background images, window colors and sounds. Users can change their own desktop theme according to their favorite, or download a new theme from the Internet. These topics have common characteristics, and you can define an Abstract Subject for them, with each Specific Subject as a subclass. The user form can select or add new themes as needed without modifying the original code, so it meets the open and closed principle, as shown in Figure 2.

Figure 2 Desktop theme class diagram for Windows

Dependence Inversion Principle (DIP) is an article by Robert c. Martin, president of Object Mentor, published in C++ Report in 1996.

The dependency inversion principle was originally defined as: a high-level module should not depend on a low-level module, but both should depend on its abstraction; Abstraction should not depend on details, Details should depend upon abstractions (High level modules shouldnot depend upon low level modules. Both should depend upon abstractions. Abstractions Should not depend upon details. Details should depend upon Abstractions). The core idea is: program to the interface, not to the implementation.

Dependency inversion principle is one of the important ways to realize the open closed principle, which reduces the coupling between the customer and the implementation module.

Because in software design, detail is variable and abstraction layers are relatively stable, an architecture based on abstraction is much more stable than one based on detail. Here, abstraction refers to an interface or abstract class, while detail refers to a concrete implementation class.

The purpose of using interfaces or abstract classes is to create specifications and contracts that do not involve any concrete operations, leaving the task of presenting the details to their implementation classes. This principle is the basis of the open closed principle, the concrete content: programming for interfaces that rely on abstraction rather than on concrete.

The function of dependence and inversion principle

The main functions of the dependency inversion principle are as follows:

The principle of dependence inversion can reduce the coupling between classes. A system can improve its stability by relying on the principle of inversion. Relying on the principle of inversion reduces the risks associated with parallel development. Relying on inversion principles boosts readability and maintainability of code.

The purpose of the dependency inversion principle is to reduce the coupling between classes by programming to the interface, so we can satisfy this rule in projects by following the following four points in real programming.

Anyway, each class tries to provide an interface, an abstract class, or both. A variable declares itself either as an interface or as an abstract class. Anyway, no class should derive from a concrete class. Anyway, use inheritance to adhere to the Richter substitution principle.

The application of dependency inversion principle is illustrated by the example of “customer shopping program”. Application of dependency inversion principle in “customer shopping program”. Analysis: This program reflects the relationship between “customer class” and “store class”. In the shop class, there is a method called sell(), which is used by the customer class to shop. The following code defines the customer class to shop in ShaoguanShop:

class Customer
{
	public void shopping(ShaoguanShop shop)
	{
		/ / shoppingSystem. The out. Println (shop. Sell ()); }}Copy the code

However, there are drawbacks to this design. If the customer wants to shop from another store (such as WuyuanShop), the customer’s code needs to be modified as follows:

class Customer
{
	public void shopping(WuyuanShop shop)
    {
		/ / shoppingSystem.out.println(shop.sell()); }}Copy the code

Customers change the code every time they change stores, which is a clear violation of the open and close principle. The reason for the above shortcomings is that the customer class is bound to the specific store class when it is designed, which violates the dependency inversion principle. The solution is to define the common interface Shop of “Wuyuan Online Shop” and “Shaoguan Online Shop”. The customer class is programmed to this interface, and the code is modified as follows:

class Customer
{
	public void shopping(Shop shop)
	{
		/ / shoppingSystem.out.println(shop.sell()); }}Copy the code

In this way, no matter what store the Customer class visits, or if a new store is added, there is no need to modify the original code, as shown in the class diagram.

Figure 5. Class diagram of customer shopping program

The program code is as follows:

package principle;
public class DIPtest
{
	public static void main(String[] args)
	{
		Customer wang=new Customer();
		System.out.println("Customers purchase the following items:"); 
		wang.shopping(new ShaoguanShop()); 
		wang.shopping(newWuyuanShop()); }}/ / store
interface Shop
{
	public String sell(a); / / sell
}
// Shaoguan online shop
class ShaoguanShop implements Shop
{
	public String sell(a)
	{
		return Shaoguan local specialties: mushrooms, agaric......; }}// Wuyuan Online shop
class WuyuanShop implements Shop
{
	public String sell(a)
	{
		return "Wuyuan local specialties: green tea, fish with distiller's grains..."; }}/ / the customer
class Customer
{
	public void shopping(Shop shop)
	{
		/ / shoppingSystem.out.println(shop.sell()); }}Copy the code

The running results of the program are as follows:

Customers buy the following goods: Shaoguan local specialties: mushrooms, agaric...... Wuyuan local specialties: green tea, distiller's grains fish...Copy the code

The Interface Segregation Principle (ISP) requires programmers to break bloated interfaces into smaller, more specific interfaces, so that the interfaces contain only the methods that the customer is interested in.

In 2002, Robert C. Martin defined the “interface isolation principle” as: Clients should not be forced to depend on methods they do not use. There is another definition of this principle: The dependency of one class to another one should depend on The smallest possible interface. What these two definitions mean is that instead of trying to create a huge interface for all the classes that depend on it, create a special interface for each class.

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 principle of single-responsibility pays attention to responsibility, while interface isolation pays attention to isolating interface dependencies. The principle of single-responsibility, which governs classes, targets implementation and details in a program; The interface isolation principle mainly constrains interfaces and is aimed at abstraction and the construction of the overall framework of the program.

[Note] The single responsibility principle and the interface isolation principle are also referred to as the high cohesion and low coupling principle.

Advantages of interface isolation The interface isolation principle is used to constrain interfaces and reduce the dependency of classes on interfaces. It has the following advantages.

Buying a system by splitting a bloated interface into smaller-grained ones prevents the proliferation of external changes and increases the flexibility and maintainability of the system. Interface isolation boosts system cohesion, reduces external interactions, and reduces system coupling. Automatically defining the granularity of interfaces ensures system stability. However, if the definition is too small, it will lead to too many interfaces and complicate the design. If the definition is too large, flexibility is reduced and customization services cannot be provided, bringing unpredictable risks to the overall project. Using multiple dedicated interfaces also lends itself to hierarchies of objects, as the overall interface can be defined through interface inheritance. Buy a ticket to reduce code redundancy on a project. A large interface that is too large often places a lot of unnecessary methods inside it, forcing redundant code to be designed when implementing the interface.

The implementation of the interface isolation principle Is based on the following rules.

The interface to buy a ticket is small, but limited. An interface serves only one submodule or business logic. Queues customize services for classes that rely on interfaces. Provide only the methods needed by the caller and mask those that are not. Learn your environment by buying something to do, instead of blindly following your ideas. Each project or product has selected environmental factors, and depending on the environment, the criteria for interface separation will vary to gain insight into the business logic. Buy a way to promote cohesion and reduce external interactions. Make the interface do the most with the fewest methods.

The following uses the student score management program as an example to describe the application of the interface isolation principle.

The program of student achievement management.

Analysis: Student grade management procedures generally include insert, delete, modify the results, calculate the total score, divide calculation, printing performance information, query results, and other functions, if all these features into an interface obviously is not very reasonable, right, it is respectively in the input module, statistics module and print module three modules, Its class diagram is shown in Figure 7.

Figure 7 Class diagram of student score management program

The program code is as follows:

package principle;
public class ISPtest
{
	public static void main(String[] args)
	{
		InputModule input =StuScoreList.getInputModule();
		CountModule count =StuScoreList.getCountModule();
		PrintModule print =StuScoreList.getPrintModule();
		input.insert();
		count.countTotalScore();
		print.printStuInfo();
		//print.delete();}}// Input module interface
interface InputModule
{
	void insert(a);
	void delete(a);
	void modify(a);
}
// Statistics module interface
interface CountModule
{
	void countTotalScore(a);
	void countAverage(a);
}
// Print module interface
interface PrintModule
{
	void printStuInfo(a);
	void queryStuInfo(a);
}
/ / implementation class
class StuScoreList implements InputModule.CountModule.PrintModule
{
	private StuScoreList(a){}
	public static InputModule getInputModule(a)
	{
		return (InputModule)new StuScoreList();
	}
	public static CountModule getCountModule(a)
	{
		return (CountModule)new StuScoreList();
	}
	public static PrintModule getPrintModule(a)
	{
		return (PrintModule)new StuScoreList();
	}
	public void insert(a)
	{
		System.out.println("Insert () method of input module called!");
	}
	public void delete(a)
	{
		System.out.println("Input module's delete() method called!");
	}
	public void modify(a)
	{
		System.out.println("Input module's modify() method is called!");
	}
	public void countTotalScore(a)
	{
		System.out.println(The countTotalScore() method of the statistics module is called!);
	}
	public void countAverage(a)
	{
		System.out.println("The countAverage() method of the statistics module is called!");
	}
	public void printStuInfo(a)
	{
		System.out.println("The printStuInfo() method of the print module is called!");
	}
	public void queryStuInfo(a)
	{
		System.out.println("Print module's queryStuInfo() method called!"); }}Copy the code

The running results of the program are as follows:

The insert() method of the input module is called! The countTotalScore() method of the statistics module is called! The printStuInfo() method of the print module is called!Copy the code

Composite Reuse Principle (CRP) is also called Composition/Aggregate Reuse Principle (CARP). It requires that in software reuse, we should first use association relation such as combination or aggregation, and then consider using inheritance relation. If inheritance is to be used, the Richter substitution principle must be strictly followed. The principle of composite reuse and the Principle of Richter’s substitution complement each other.

The importance of the principle of composite reuse Usually class reuse is divided into inheritance reuse and composite reuse. Although inheritance reuse has the advantages of simplicity and easy implementation, it also has the following disadvantages.

Inherit reuse breaks the encapsulation of a class. Because inheritance exposes the implementation details of the parent class to the child class, the parent class is transparent to the child class, so this reuse is also known as “white box” reuse. Unconsciously, a subclass has a high coupling degree with its parent class. Any change in the implementation of the parent class results in a change in the implementation of the subclass, which is not conducive to the extension and maintenance of the class. Unconsciously it limits the flexibility of reuse. An implementation inherited from a parent class is static and defined at compile time, so it cannot be changed at run time.

When using composite or aggregate reuse, existing objects can be incorporated into the new object, making it a part of the new object. The new object can invoke the functions of the existing object, which has the following advantages.

Unconsciously, it maintains the encapsulation of a class. Because the internal details of component objects are invisible to the new object, this reuse is also known as “black box” reuse. Unconsciously there is low coupling between old and new classes. This reuse requires fewer dependencies, and the only way a new object can access a component object is through its interface. Lent reuse is flexible. This reuse can occur dynamically at run time, with new objects dynamically referencing objects of the same type as component objects.

The principle of composite reuse is implemented by incorporating existing objects into new objects as member objects of new objects. The new objects can call the functions of existing objects to achieve reuse.

The application of the principle of composite multiplexing is illustrated by the example of the vehicle classification management program.

The automobile classification management program. Analysis: according to the “power source” can be divided into gasoline vehicles, electric vehicles, etc. According to the “color” can be divided into white cars, black cars and red cars. If you consider both categories, the combinations are numerous. Figure 9 shows a class diagram of vehicle classification implemented with the stepnet: relation.

FIG. 9 Class diagram of automobile classification with inheritance relation

As you can see from Figure 9, the implementation of inheritance generates many subclasses, and adding a new “power source” or a new “color” requires modifying the source code, which violates the open closed principle and is clearly not desirable. However, the above problems can be well solved by using combinatorial relations, as shown in the figure for its class diagram.

FIG. 10 Class diagram of automobile classification realized by combinatorial relation

Combined with the content of the previous sections, we introduce seven design principles, which are open closed principle, Richter’s substitution principle, dependency inversion principle, single responsibility principle, interface isolation principle, Demeter’s rule and the composite reuse principle introduced in this section.

These seven design principles are the principles that software design patterns must follow, and they require different emphases. Among them, the open and closed principle is the general principle, it tells us to be open to expansion, to modify closed; Richter’s substitution tells us not to break the inheritance system; The dependency inversion principle tells us to program for interfaces; The single responsibility principle tells us to implement a class with a single responsibility; The principle of interface isolation tells us to keep interfaces simple and simple when designing them. Demeter’s rule tells us to reduce coupling; The principle of composite reuse tells us to use composite or aggregate relation reuse in preference to inheritance relation reuse.