Principles in software design (GRASP)

The several software models mentioned here belong to the principle level, which is higher than the software design modes such as GoF. Following these principles can make the software we designed more reusable and maintainability. Similarly, software design patterns such as GoF follow this principle.

The following is a brief introduction, so that you may forget to visit it occasionally. For details, see Java mode and UML and pattern application-Introduction to object-oriented analysis and design.

• GRASP Mode

GRASP is short for General Responsibility Assignment Software Pattern.

1) Expert mode (Expert)

Solution: assign responsibilities to categories with information required for performing duties

The general point is: what should we do? Don't worry about other people's business or I am responsible for doing this. Other things don't matter.

For example, if a class specifically processes string-related classes, this class can only have string processing-related methods, rather than adding date processing methods. That is, the principle of improving software cohesion.

2) Creator)

Solution: Assign the responsibilities of creating an instance of Class A to the instance of Class B if the following conditions are met:

A) B Aggregates object.

B) B contains object.

C) B records the instance of object

D) B. Use object A frequently.

E) When an instance of A is created, B has the initialization data to be passed to A (that is, B is the information expert who creates the instance of)

F) B is the creator of object.

If more than one of the above conditions is true, it is best to let B gather or contain

The general point is: I want to use you, so I will create you. Please do not let others create you

This mode is an embodiment of the low coupling principle.

3) High Cohesion)

Solution: maintain the high degree of polymerization of the class when assigning a responsibility.

The degree of polymerization or cohesion (cohesion) is a measurement of the degree of relevance and concentration between various responsibilities in a class. A class with a high degree of relevant responsibilities and the workload that this class can accomplish is not very huge, so it has a high degree of polymerization.

4) Low Coupling or Low Coupling)

Solution: maintain a low coupling level when assigning a responsibility.

Coupling is a measure of the intensity of a class associated with other classes, information about other classes, or dependency on other classes. A low (weak) coupling class does not depend on too many other classes.

5) Controller)

Solution: assign the responsibility for processing system event messages to the following categories:

A) represents the entire "system" Class (Virtual packet Controller)

B) classes representing the entire enterprise or organization (Virtual packet controllers)

C) indicates the active object class (for example, the role of a person) involved in the role (role Controller) in the real world)

D) represents the human handler class for all events in a use case. Generally, the class is named as "<Use Case Name> handler" (Use Case Controller)

This is a rule for assigning roles and responsibilities of controllers.

6) polymorphism

When the relevant optional methods or actions change with the type, assign the responsibility of the action-use a multi-state action-to the type of behavior changes

That is to say, we should try to program the abstraction layer and use the multi-state method to determine which class should be used, instead of using if instanceof to determine what the class is and what to execute.

7) purely fictitious

A pure fiction means to create something, rather than making it happen.

For example, the data of our Sale class must be stored in the database, but it must be connected to the database interface. If we put the interface connection into the Sale class, the coupling of this class will inevitably be increased, therefore, we can create a fictitious class to deal with the connection to the database interface. This class is a fictional thing.

8) intermediary

Assign responsibilities to an intermediate object for arbitration between other components or services, so that these components or services are not directly coupled. This intermediate object (intermediary) creates an Indirection between other components or services ). This intermediate object is also a pure fiction in case 7.

9) do not speak to strangers

Assign responsibility to a client's direct object so that it can collaborate with an indirect object, so that the client does not need to know this indirect object.

This mode is also called the Demeter criterion.

The common point is: only communicate with your friends.

Don't talk to strangers

Each software organization has only the minimum knowledge of other units and is limited to software units closely related to the same unit.

• 2. Other Design Principles

1) "Open-Closed" Principle (Open-Closed Principle, or OCP)

A software entity should be open to extensions and closed to modifications.

This means that when designing a module, the module should be extended without being modified. In other words, you can change the behavior of this module without modifying the code.

2) liskey replacement Principle (Liskov Substitution Principle, or LSP)

This is how to program with polymorphism, that is, polymorphism in the GRASP mode.

3) Dependency Inversion Principle (Dependency Inversion Principle, or DIP)

The principle of dependency inversion is: to rely on abstraction, not specific

That is to say, we should do our best to control programming at the abstraction layer, and do not implement programming at the interface.

4) Interface Segregation Principle or ISP)

It is better to use multiple dedicated interfaces than to use a single total interface. That is, from the perspective of a customer class: the dependence of a class on another class should be based on the smallest interface.

5) principle of combination/aggregation reuse (Composition/aggregation principle, or CARP)

This is also called the merging Reuse Principle. The principle is to use some existing objects in a new object to make them part of the new object: new objects reuse existing functions by delegating these objects. That is to say, we should try to use the synthesis and reuse of classes, and do not use inheritance as much as possible.

6) Change and unchanged Separation
Another step of expansion is to isolate different components. The simplest example is the accessor In the JavaBean. It isolates unchanged interfaces and changed internal attributes. In this regard, I think the best embodiment is eclipse. Through the changed plug-in, eclipse can be used to implement any function.