Discussion on GRASP software development model

Are you an excellent software developer? Do you know grasp? GRASP software development model, full name generic duty distribution software model (general Responsibility Assignment software Patterns), is with the famous software model Gof (Gang of four, That is, we often say that the 23 software development model) is the same as another software development model. However, unlike GOF, it does not propose specific software organizational structures, but it suggests that in the process of abstracting real-world business functions into specific objects in software development, we should follow some basic principles. By following these basic principles, we can develop high-quality software. For the software project we are going to develop, we can not use the Factory mode, we can not use the singleton mode, we can not use the observer pattern, but we cannot not abstract the real-world business functions into the software development of specific objects. From this point of view, we need to improve the quality of our software development, in-depth understanding of grasp is more important than understanding gof in depth. But I see now introduce GOF article more, introduce grasp article less. Because of this, I now introduce grasp to you.
The GRASP contains 9 patterns, which are 9 basic principles. This is explained in depth in the classic "UML and Schema Application" of the Software Design Master Craig Larman. Grasp called the general responsibility Distribution software model, to understand grasp, we must first understand the question is, we in the object analysis and design process why to carry out responsibility assignment.

I. Responsibility allocation and responsibility-driven design

At the beginning of a software project, we usually need to conduct a requirement analysis to understand what kind of software the customer needs to design and what functions should be in the software. Requirements analysis is about the business functions of the real-world customer needs, and each business function is often a business process, that is, the business process that customers are constantly completing in their daily work. At the same time, in the user's problem world, there must be some things or things, there is a correlation between them.
Take a software review management system as an example. The business requirements of the review management system are as follows:
1. The review organizer will prepare a review plan, submit the leader's approval, and notify the reviewer by email.
2. The reviewers were informed to review the subjects, fill in the Review form, and ask questions about the object of the review.
3. The review organizer summarizes the questions of the reviewer and holds a review meeting to discuss these questions. At the meeting, some questions become problems, some of them are not problems, and some are still not able to be confirmed.
4. After the meeting, the review organizers collate questions, form a review report, and then by the reviewers vote on whether the review passed. Finally, the organizer summarizes the results of the voting and concludes the review.
5. Review Organizer to track problem resolution.
Through the description of the above requirements, we are not difficult to find the whole problem in the world of related things: Review organizer, review plan, reviewers, review objects, review form, questions, review reports, review conclusions, issues. It is not difficult to analyze the relationship between these things, such as the review plan and the reviewer is a one-to-many, and the review report and the conclusion is one-to-another.
In Rup, the business requirements will form the use case model and the use case in the description document, and the things and their relationships will form the objects in the domain model, and of course how to make use case models and domain models is beyond the scope of this article, and interested friends can look at related articles.
The object in the domain model will be the basis of the concrete object in software development (what is formed in software development depends on the specific requirements of software development, and does not necessarily conform to the object of the domain model). Use cases in the use case model are implemented by assigning these object behaviors. Now the question comes out, how does a function in a use case model, or a series of behaviors, be assigned to these objects? In other words, in order to accomplish the same task, I can give the behavior a to object x, or I can give it to object Y. Although given to object X and to object y, I do not have a specific implementation of behavior a, but can complete the task of behavior A. So, should I give it to object x or object Y? Is there a basic principle? Yes, it is to assign tasks according to responsibilities. Although in theory, I can define objects arbitrarily, can make the object meaningless, or to do arbitrary work, but usually we do not design. Often we associate objects with real-world objects, such as designing a review plan object and reviewer object. And we should do "low representation difference" when designing objects. The low representation difference is that the object we design should be as consistent as possible with real-world objects. For example, we design an object called "reviewer" because we have reviewers in the real world. At the same time, the behavior we assign to reviewers should be as consistent as possible with the real world, such as adding reviewers, revising reviewers, and getting reviewers ' information. So what is the behavior that this object should be given, which should be decided by the responsibility.
We design the objects in the software system by analyzing the real world, or by analyzing the domain models, and we should assign responsibilities to each object. What is the object of responsibility, of course, is through the analysis of the real world, defined by this object should accomplish the task. For example, the reviewer object is responsible for accessing data related to reviewers. Of course, the responsibility of the object is not necessarily one, such as the review plan contains the review object and the reviewer's child, so it can be in the work is not busy in the case of the review object and the reviewer's information access. But the responsibility of an object should not be too much (also 2, 3 on the line) and highly correlated. For example, the evaluation table object if the allocation of responsibility to process the review table, but also to deal with the review plan data, this is called responsibility irrelevant.
The assignment of responsibilities has now been widely recognized as a principle that good software design should follow, and it has the following benefits:
1. The low representation difference makes the software structure clear and easy to understand, because software development is not a person's business. In software projects developed by many people, a glance at the software structure avoids unnecessary errors caused by misunderstanding by developers.
2. Easy to maintain and change. If the review plan has a problem or needs to be modified, we will go to the review plan, and if it is the reviewer's question we will go to the reviewers, and will not be related to other objects.
This is referred to as "responsibility-driven Design" (rdd,responsibility) by considering objects, responsibilities, collaborative object design, and component methods. Responsibility-driven design is to design the use case model, use case model description, Operation contract, System sequence diagram, domain model, glossary, then step by step make analysis model, design model, write out each function interactive diagram, class diagram of very complex process, I am not detailed here. But please pay attention to a very important detail, before we say that the object in the software system is based on the real world abstraction, the assignment of object responsibility is based on the definition of objects, assigning a few and highly related tasks. However, even if we follow these principles, there are quite a lot of design flexibility space, different people according to their own understanding, for the same function still have their own different design. The translation of grasp into "general responsibility distribution software Model" is to put forward several basic principles on the assignment of responsibility in object analysis and design. At the same time, these basic principles should also grasp a degree, that is, not all cases are applicable, nor is it an absolute indicator. For example, low coupling, not absolute decoupling, non-coupling software can not be designed, high cohesion can not be unlimited high cohesion, otherwise the system is complicated.

Two. Grasp mode analysis

The GRASP Software design pattern consists of 9 modes: Creator, information expert, low coupling, controller, high cohesion, polymorphism, pure fiction, indirection, and prevention of mutation.