A brief discussion on GRASP software development model

Are you a good software developer? Do you know GRASP? GRASP software development model, the full name is General Responsibility Assignment Software Patterns, is another software development model as famous as the famous software model GoF (Gang of Four, the 23 software development models we often call). model. But unlike GoF, it does not propose some specific software organizational structures, but rather proposes what we should follow in the process of abstracting real-world business functions into concrete objects in software development. Some Basic Principles. Only by following these basic principles can we develop high-quality software. For the software projects we want to develop, we don’t have to use factory pattern, we don’t have to use single case pattern, we don’t have to use observer pattern, but It is impossible for us not to abstract real-world business functions into concrete objects in software development. From this perspective, we need to improve the quality of our software development. A deep understanding of GRASP is more important than a deep understanding of GoF. But I see that there are many articles introducing GoF and few articles introducing GRASP. Because of this, I now introduce GRASP to everyone.
GRASP contains 9 patterns, which are 9 basic principles. This is explained in depth in the classic book "UML and Pattern Application" by software design guru Craig Larman. GRASP is called the General Responsibility Assignment Software Pattern. To understand GRASP, the first question we must understand is why we need to assign responsibilities during the object analysis and design process.

1. Responsibility allocation and responsibility-driven design

At the beginning of a software project, we usually need to conduct a requirements analysis to understand what kind of software the customer needs to design and what functions the software should have. Requirements analysis understands the business functions required by customers in the real world. Each business function is often a business process, that is, the business process that customers continue to complete in their daily work. At the same time, in the user's problem world, there must be some things or things that are related to each other.
Take a software review management system as an example. The business requirements of the review management system are as follows:
1. The review organizer develops a review plan, submits it to the leader for approval, and then notifies the reviewers via email.
2. The reviewers are notified to review the review objects respectively, fill in the review form, and can raise questions about the review objects.
3. The review organizer summarizes the reviewers' questions and holds a review meeting to discuss these questions. At the meeting, some questions became problems, some questions were not problems, and some still could not be confirmed.
4. After the meeting, the review organizer will sort out the questions and form a review report, and then the reviewers will vote on whether the review is passed or not. Finally, the review organizer summarizes the voting results and forms a review conclusion.
5． Review organizers track resolution of issues.
Through the description of the above requirements, it is not difficult for us to find related things in the entire problem world: review organizer, review plan, reviewer, review object, review form, questions, review report, review conclusion, and questions. It is not difficult for us to analyze the relationship between these things. For example, the review plan and reviewers are one-to-many, while the review report and review conclusions are one-to-one.
In RUP, business requirements will form use cases Model and use cases in their description documents, and things and their relationships will form objects in the domain model. Of course, how to make use case models and domain models is beyond this article Regarding the scope of the discussion, interested friends can read relevant articles.
The objects in the domain model will become the basis for forming specific objects in software development (what objects are formed in software development is determined according to the specific needs of software development, and does not necessarily have to be consistent with the objects of the domain model). The use cases in the use case model will be implemented by assigning behaviors to these objects. Now the question arises, how should the functions in the use case model, or a series of behaviors, be assigned to these objects. In other words, in order to complete the same task, I can assign behavior A to object X or to object Y. Although my specific implementation of behavior A is different when I hand it over to object X and when I hand it over to object Y, both can complete the task of behavior A. So, should I hand it over to object X or object Y? Is there a basic principle? Yes, that is to allocate tasks according to responsibilities. Although in theory, I can define objects arbitrarily, make objects meaningless, or perform arbitrary tasks, but usually we do not design in this way. Usually we connect objects with real-world objects, such as designing a review plan object and reviewer object. And we should achieve "low representation difference" when designing objects. Low representation difference means that the objects 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 behaviors we assign to reviewer objects should be as consistent as possible with the real world, such as adding reviewers, modifying reviewers, and obtaining reviewer information. So which behaviors should be assigned to this object should be determined by responsibilities.
We design the objects in the software system through analysis of the real world, or analysis of the domain model. At this time, we should assign responsibilities to each object. What is the responsibility of an object? Of course, it is defined through the analysis of the real world and the tasks that this object should complete. For example, the responsibility of the reviewer object is to access data related to the reviewer. Of course, the responsibility of an object does not necessarily have to be the same. For example, the review plan contains the sub-items of the review object and the reviewer, so it can handle the information access of the review object and reviewer on behalf of the review object when the work is not busy. But an object should not have too many responsibilities (just 2 or 3) and should be highly related. For example, if the object of the evaluation form is assigned the responsibility to process the evaluation form and also process the data of the evaluation plan, this is called responsibility-independent.
Responsibility distribution is now generally recognized as a principle that an excellent software design should follow. It has the following benefits:
1. Low representation differences make software clearly structured and easy to understand because software development is not a one-person affair. In software projects developed by multiple people, a clear software structure can avoid unnecessary errors caused by developers' misunderstandings.
2. Easy to maintain and change. If there is a problem with the review plan or needs to be modified, we will go to the review plan. If it is a problem with the reviewer, we will go to the reviewer, and it will never have anything to do with other parties.
This kind of object design and component approach that considers objects, responsibilities, and collaboration is called "Responsibility Drive Design (RDD)". Responsibility-driven design involves first designing use case models, use case model descriptions, operation contracts, system sequence diagrams, domain models, and glossaries, and then step by step making analysis models and design models, and writing interaction diagrams and class diagrams for each function. I won’t go into details about the complicated process here. But please pay attention to a very important detail. As we said earlier, objects in software systems are abstracted from the real world. The allocation of object responsibilities is based on the definition of the object, assigning some few and highly related tasks. However, even if we follow these principles, we still have considerable design flexibility. Different people still have different designs for the same function based on their own understanding. GRASP is translated as "General Responsibility Assignment Software Pattern" in Chinese, which puts forward several basic principles for the issue of responsibility assignment in object analysis and design. At the same time, these basic principles should also be grasped to a certain extent, that is, they are not applicable in all situations, nor are they an absolute indicator. For example, low coupling does not mean absolute non-coupling. Without coupling, software cannot be designed; high cohesion cannot be infinitely high, otherwise the system will be complicated and abnormal.

2. Analysis of GRASP patterns one by one

GRASP softwareDesign patternIncludes 9 patterns: Creator, Information Expert, Low Coupling , Controller, high cohesion, polymorphism, pure fiction, indirectness, prevention of mutation.

The above is the detailed content of A brief discussion on GRASP software development model. For more information, please follow other related articles on the PHP Chinese website!