Design Patterns and read-create mode (updated on 06-12-03)

GOF Design Patterns chapter 3

* Design Patterns, a masterpiece of GOF, is undoubtedly a bible of Design Patterns. However, "in terms of style, this book is not so much a tutorial template for learners, it is better to say that it is an academic report that can be viewed by academics. It is rigorous and vivid." [Meng yan] This series parses important sentences in the Chinese version of "Design Patterns" (in combination with the English version) by sentence. As a self-study note, it also gives some reference to new users who are new to the Design model. The original article usesBoldMark. What I don't understand is[TODO :〕Mark, hope experts give more advice.

The Creation Mode abstracts the instantiation process.. Two problems:

1. What is the instantiation process?
2. What is abstraction?

The so-called instantiation process is simply the process of creating objects. In object-oriented language, it generally refers to the process of creating objects through constructor. In Java and C #, the keyword "new" is usually used to create objects. Of course, there are reflection methods, which are rarely used. An object may not be ready for use after it is instantiated. Complicated objects sometimes need to be assembled or initialized. There is no special description about instantiation, that is, the key object "new" is used to create objects. [E. g instance = new SomeConcreteClass ();]

How can this process be abstracted? The so-called abstraction is to cover up specific things. What is the specific concept here? It is obviously the constructor, that is, the SomeConcreteClass class. This is a specific class. When a specific class appears in our code, we rely on the specific implementation, which violates the DIP principle. Abstraction means that the client only needs an instance, but does not know the creation process of the instance, or does not know the signature of its constructor (including the name of the constructor, namely the class name and constructor parameter ).

They help a system to create, combine, and express its objects independently.. Original article: They help make a system independent of how it's objects created, composed and represented. the role of the Creation Mode is to make the system independent from the creation, combination, and representation of objects in the system. From this point of view, the previous sentence abstracted that the instantiation process in the instantiation process contains the assembly process (combination. The creation mode helps the system easily understand how to create and combine objects independently of the system. For example, the Factory Method returns an object instance through a return interface, and the client does not understand the object creation process. The Builder mode isolates the creation and combination of each part of the object. So how to understand it separately? "Representation" can be understood as different implementations of the same interface.

[E.g. (thanks to Lenny Primark)

List <Number> numbers = numbersFactory. createNumbers (5, 10); // create five numbers with values of 10

The instance returned by the factory method may be any of the following "representation ":

• It can give you need list <Number> or ArrayList <Number>
• It can give you List <IntegerNumber> or List <DoubleNumber>
• Or any other combination.

The Creation Mode returns an excuse, while the implementation and actual data presentation details are hidden.]

A class creation mode uses inheritance to change the class to be instantiated, while an object Creation Mode delegates the Instantiation to another object.

As the system evolves more and more dependent on Object composition rather than class inheritance, the creation mode becomes more important.First, we have pointed out the direction of evolution and are increasingly dependent on Object combination instead of inheritance. Then, on this premise, the application creation mode is encouraged.

In this case, the center of gravity is shifted from hard-coding to defining a small basic behavior set for a set of fixed behaviors, these actions can be combined into any number of more complex actions.Class inheritance is actually a "static" fixed behavior, which is determined during the compilation period. The object composite pursues a complex behavior through a small basic behavior set, it usually supports the combination mode changed during running.

In this way, creating objects with specific behaviors requires not only instantiating a class.That is, it may be responsible for the assembly process.

There are two main themes in these models. First, they all encapsulate information about the specific classes used by the system. Second, they hide how instances of these classes are created and put together.In the first package, the Customer Code does not know the specific classes they use. The second one is very clear, but compared with the first paragraph, it does not mention the meaning of "represented.

All objects in the system know interfaces defined by abstract classes.Here, the entire system actually refers to the Customer Code. If the entire system contains specific classes, you must understand the specific classes.

Therefore, the Creation Mode gives you great flexibility in what is created, who creates it, how it is created, and when it has been created.What is created: hide a specific class through the product interface. Who created it: hides a specific factory through the factory interface. How it is created: the Builder abstract method hides the creation process. When to create: Hide the creation time in single-piece mode. [TODO: What other modes are encapsulated here. 〕

They allow you to configure a system with "product" objects with very different structures and functions. The configuration can be static (specified during compilation) or dynamic (at runtime ).Products with very different structures and functions should implement the same interface.

Sometimes the creation mode is competing with each other. For example, Prototype or Abstract Factory works well in some cases. In other cases, they are complementary: Builder can use other modes to create a component. Prototype can be implemented using Singleton.

Next, I will give an example. I will not repeat it here. However, pay attention to the following points.

The author puts the Enter method into MapSite, instead of a class called Player. It contains a lot of wisdom and experience. Of course, I do not rule out that the Player class should contain a method similar to Move, but this method should call the Enter method of Mapsite. Imagine that if the Move action and its response are all put in the Player class, it will be the following effect:

[

Public void Move (Direction d)

{

If (currentRoom. GetSide (d) is Room ){}

Else if (currentRoom. GetSide (d) is Wall ){}

Else if (currentRoom. GetSide (d) is Door)

{

If (door. isOpen ){}

Else {}

}

}

] There is no doubt that this method is readable and has poor scalability.Enter provides a simple foundation for more complex game operations. In a real game, Enter can take the player object as a parameter.

The author's comment after giving the CreateMaze method,Considering that this function only creates a maze with two rooms, it is quite complicated.This complexity is because the client is responsible for too many functions.The Room constructor can use walls to initialize each side of the Room in advance.This will make the client code a little simpler.The real problem with this member function is not its size but its flexibility.

The create mode shows how to make the design more flexible, but not necessarily smaller.Therefore, when using the model, we should discard this idea and think that a good design is a small design, but a flexible and scalable design.

The current design is not easy to expand. The biggest obstacle is hard coding of the instantiated class.At the end of this chapter, the author provides a solution for creating a model.

• Factory Method: CreateMaze calls the virtual function instead of using new to create Room, Wall, and Door. Factory Method is actually simple to surprise you! At any time, when you have a virtual (abstract) function whose return value is an interface (abstract class), you are using the Factory Method. (To put it bluntly, understanding the simplicity of a pattern is sometimes more important than understanding its complexity. Many people may not understand the simplicity of the Factory Method pattern .) We recommend that you refer to my other article: "No Factory mode".
• Abstract Factory: CreateMaze does not call its own virtual function, but imports an object (Abstract Factory) from the outside to it. The CreateMaze method calls this object method (also a virtual method) to create Room, Wall, and Door.
• Builder :( TODO: wait until I finish reading the code :)
• Prototype :( TODO: I will try again after reading it :)
• Singleton: Make sure that each game has only one maze, and all objects can access it quickly-second, there is no need to turn to global variables or functions. Singleton also makes the maze easy to expand or replace without changing existing code. I won't say much about Singleton's controversy. At the end of the article, the author added "easy to expand or replace", and stressed that "No need to change existing code" is indeed confusing. (TODO: Which of the following experts will explain it ?)