OOP for OOP: GRASP

GRASP - General Responsibility Assignment Software Patterns (Basic Software Responsibility Patterns)

When it comes to the term "OOP", all certainly imply Object-Oriented Programming, but today it is not about it. Nearly. Today I would like to talk about the principles of Object Oriented Design, and in particular about the GRAPS patterns and their field of application.

GRASP consists of 9 templates:

• Creator
• Controller
• Pure fabrication
• Information expert
• High cohesion
• Indirection
• Low coupling
• Polymorphism
• Protected Variations

But today not all will be considered, but only the main ones. At the same time I want to add that not all templates are “software”. Some of them (for example, High Cohesion and Low Coupling) are principles, not examples of implementation.

The more experience a software developer has, the more he understands the meaning of preliminary design and prototyping, and the later he proceeds to develop the system directly, even if it is a database of four tables. It is laziness that responds to it :) After all, it was due to the fact that in a few previous projects the design was given too little time, as a result, the system corresponded by 40-60 %%, and the average thinking programmer does not like to do the same thing many times , here it is “necessary” to devote more time to the preliminary analysis. And it is here that he becomes interested in such aspects of software development as object-oriented analysis and design.
')
So, having understood that it is necessary to devote more time to modeling, the following question becomes relevant: “Well, what is there to do with this, if everything is clear?” In general, if there is a rather large load of knowledge and experience behind, and with OOA / P did not have to face, then all decisions are made at the level of intuition, and reading the literature leads only to the systematization of knowledge and, possibly, new approaches. So, over time, discover for themselves GRASP.

As mentioned earlier, GRASP are design patterns. Namely - the templates that are responsible for the relationship of objects in the system. How many times have you thought about where the new object will be generated? In this article I want to consider the basic GRAS templates (I omit the “P” to avoid tautology, since it is replaced by the catch “templates” in the abbreviation), using the example of a blog.

Creator.

How often did you have to think about who should create an X object? Often they come to the conclusion that an object should be created independently of someone; often this task is assigned to the object storage (collection class), and sometimes to other objects of the system. What is right and which option to choose?
The creator template tells us what conditions must be met, so that the objects would truly spawn each other. There are several rules for this:
object A must generate object B if:

• object A contains or aggregates objects B ^{(contains as a property or a collection)}
• object A actively uses objects B ^{(most of the work with object B occurs through object A)}
• object A has object B initialization data ^{(each time object B is created, data is taken from object A)}

So, looking at the relationship diagram, based on the Creator template, we can conclude that instances of the Post class should be created inside the Blog class, and Comment should be created in the Post. Why so and not otherwise? For example, why Comment should not be created in a blog? Well, if only because Post contains copies of Comment, as well as Post has information to create a Comment instance (in our case, this is just a pointer to the parent, but even this does not have a Blog in relation to Comment).

Information expert

Information expert, as the name implies, is engaged in nothing more than the provision of information about the object. In our case, Information Expert should answer such questions:

• Who should know the number of comments to the post?
• Who should know the total number of comments on the blog?

Trying to answer these questions, we need to determine which of the participants in the system has the necessary information. So getCommentsCount () should be assigned to the Post object, and the Blog object, based on the intermediate values ​​of each of its incoming object, Post will receive the total amount of getTotalComments () comments.



But at the same time, Post should be responsible for such aspects as “get the name of the post” (getTitle ()), “get the post”, “get the author”, etc.

Controller

Well, everything is simple. This is nothing more than C from MVC abbreviation :) This template is responsible for who exactly the calls from V (View) should address and to whom C should delegate execution requests (which M model should process them)

Low coupling

Low connectivity, is responsible for ensuring that the objects in the system know about each other as little as possible. After all, the less an object knows about other objects, the more it will be isolated and the less edits will need to be made if something changes in the system.
Everything is fine on our charts. Blog knows nothing about Comment, and the degree of connectedness of each class is only one. In more complex communication systems, there is much more, and the Low Coupling pattern allows you to avoid the following problems:

• When changing to related classes, you must make local changes to this class.
• Understanding each class separately is complicated and requires the study of all related classes.
• Reuse becomes impossible due to the fact that having tugged a part of the system, it is necessary to pull almost the entire system.

High cohesion

High degree of gearing - this is how the name of the template is translated. This is a counterweight to the previous pattern. Engagement is the process of class interaction with other system classes and the area of ​​responsibility for actions. Consider two charts:





What do you think is more correct? Answering this question from the point of view of Low Coupling, then the first, but is it good when one class is responsible for measuring the temperature outside the window and for the movement of the metro and for calculating pi to 87342 decimal places? That is why High Cohesion insists that the class should try to perform as few non-specific tasks as possible, and have a well-defined scope. Only with experience comes an understanding of the balancing between these two patterns.

Everything. For the first time is enough :) If the article is successful, I promise to tell you about some other GRASP templates, as well as about GoF templates and many other things from the world of OOA / OOP.

original article in my blog