GRASP (General Responsibility Assignment software principles) consists of nine modes, which describe the basic principles of Object Design and Responsibility Assignment. That is to say, how to abstract the business functions of the real world into objects, how to determine the number of objects in a system, and what responsibilities each object includes, the GRASP mode provides the most basic guiding principles. Beginners should master and understand these principles as soon as possible, because this is the basis for designing an object-oriented system. It can be said that grasp is the basis for learning to use design patterns.
1. Information expert)
The information expert model is the most basic principle of object-oriented design. It is the most commonly used principle that should be integrated with our ideas. That is to say, when we design an object (class), if a class has all the information required to complete a specific responsibility, this responsibility should be assigned to this class for implementation. At this time, this class is the information expert relative to this responsibility.
For example, for a shopping cart (shopcar) in a common online store, you need to make each item (SKU) appear only once in the shopping cart. To buy the same item, you only need to update the quantity of the item. To solve this problem, we need to weigh whether the same methods of products need to be put into the class for implementation? The analysis business knows that the product must be uniquely identified by the product number (skuid), and the product number is unique in the product class. Therefore, according to the information expert model, whether the methods for comparing commodities are the same should be put in the commodity class.
2. creator (creator)
In practice, Class A should be used to create Class B when any of the following conditions are met. At this time, a is the creator of Class B:
A. A is the aggregation of B.
B. A is the container of B.
C. A holds the information of initializing B (data)
D. A record B's instance
E. A frequent use of B
If one class creates another class, the two classes are coupled and can be said to have dependencies. There is no error in dependency or coupling, but the problems they bring about are that they will generate a chain reaction in future maintenance, and the necessary coupling cannot be escaped, what we can do is to correctly create Coupling Relationships and do not randomly establish dependencies between classes. What should we do? It is necessary to abide by the basic principles stipulated by the Creator mode. If the above conditions are not met, a cannot be used to create B.
For example, because order is the container of a commodity (SKU), the order should be used to create a commodity. This is because the order is the container of the product and only the information of the initial product is held by the order. Therefore, this coupling relationship is correct and cannot be avoided. Therefore, the order is used to create the product.
3. Low coupling (low coupling)
The low coupling mode means we need to minimize the connections between classes. Its role is very important:
A. Low coupling reduces the impact on other classes due to changes in one class.
B. Low coupling makes the class easier to understand, because the class will become simpler and more cohesive.
The following situations may cause coupling between Class A and Class B:
A. A is the property of B.
B. A method for calling B's instance
The C. A method references B. For example, B is the return value or parameter of method.
D. A is a subclass of B, or a implements B
There are also some basic principles for low coupling:
A. don't talk to strangers principle: that is to say, there is no unnecessary connection between two objects that do not need to communicate. If the connection is established, problems may occur. If it is not connected, it will be a hundred times!
B. If a is connected to B, and B is not assigned the responsibility of A (in violation of the information expert model), B is assigned the responsibility of B.
C. Internal classes of two different modules cannot be directly connected; otherwise, you will be rewarded! Hey!
For example, in the example of the Creator model, another shipping person is required in the actual business to check the goods (SKU) on the order and calculate the total price of the goods, however, because the coupling between orders and commodities already exists, it is more appropriate to assign this responsibility to orders, which can reduce coupling and reduce system complexity. Here we add a totalprice () method to the order class to calculate the total price without adding unnecessary coupling.
4. High Cohesion (High Cohesion)
High Cohesion means assigning cohesion responsibilities to classes as much as possible. It can also be said to be functional cohesion responsibilities. That is, the function is closely related to the responsibilities should be put in a class, and the limited functions should be completed together, that is, high internal aggregation. This is more conducive to class understanding and reuse, and also facilitates class maintenance.
High cohesion can also be said to be an isolation. The human body is composed of many independent cells. The building consists of many bricks, steel bars, and concrete. Each part (class) each part has its own independent responsibilities and features. If a problem occurs in each part, it will not affect other parts, because highly cohesive objects are isolated.
For example, for an order Data Access class (orderdao), an order can be saved as an Excel mode or saved to a database. Therefore, different responsibilities are best achieved by different classes, this is the design of high cohesion. Here we put two different data storage functions in two classes to implement them. In this way, if the function to save to excel is incorrect in the future, then you can check the orderdaoexcel class, which makes the system more modular and facilitates task division. For example, the two classes can be allocated to different persons for simultaneous development, this also improves the team collaboration and development progress.
5. Controller)
The responsibility for receiving and processing system events should generally be assigned to a class that can represent the entire system, such classes are usually named "XX processor", "XX coordinator", or "XX session ". The following principles apply to the Controller class:
A. the receiving and processing of system events are usually replaced by an advanced class.
B. A sub-system has many controller classes to process different transactions respectively.
6. polymorphism (polymorphism)
Polymorphism here is the same as "polymorphism", one of the three basic features of OO.
For example, we want to design a drawing. Program To support drawing different types of images, we define an abstract class shape, rectangle and circle to inherit this abstract class and override them) the draw () method in the shape class, so that we can use the same interface (shape abstract class) to draw different images. This design is more in line with the principles of high cohesion and low coupling, although we have added a diamond class, which has no impact on the entire system structure, we only need to add a class that inherits the shape.
7. pure fabrication (purely fictitious)
The pure fiction here is similar to the pure fiction function we often call. High Cohesion and low coupling are the ultimate goal of system design, but cohesion and coupling are always contradictory. High Cohesion thinks that this splits more classes, but objects need to collaborate to complete the task, which in turn leads to high coupling. How can we solve this contradiction? In this case, we need to use a purely fictitious class to coordinate cohesion and coupling, which can solve the above problem to a certain extent.
For example, in the example of the above multi-state mode, if our plotting program needs to support different systems, because the API structure of different systems is different, the drawing function also needs different implementation methods, so how should we design it more appropriately? Here we can see that the pure imaginary class abstractshape is added, and no system can draw images through the abstractshape class. We didn't reduce the original cohesion or increase too many coupling, it can be both fish and bear's paw. Hahaha!
8. indirection (indirect)
As the name implies, "indirect" means that this task cannot be handled directly, and you need to make a detour. The benefit of turning around is that objects that are directly connected together are isolated from each other, and one change will not affect the other. Just as I said in the previous low coupling mode, "Internal classes of two different modules cannot be directly connected", but we can indirectly connect two different modules through intermediate classes, in this way, there is still no coupling/dependency between the two modules.
9. Protected variations (protected changes)
Locate unstable changes in advance and encapsulate them with a unified interface. If future changes occur, you can use the interface to expand new functions without modifying the original implementation. This mode can also be understood as the OCP principle, that is to say, a software entity should be responsible for extension development, and the modification should be disabled. When designing a module, make sure that the module can be expanded without being modified. The advantage of doing so is to provide new responsibilities to the system through expansion to meet new requirements without changing the original functions of the system.
