This article is intended for the following people:
The following people are not eligible.
Speaking of object-oriented, there are a lot of terms such as interface, message, hiding, encapsulation, and none of them seem to be related, so I don't understand the meaning. I'm not saying that I was pretending.
If you have experience working in Japan, you can understand this in one word. It's a responsibility.
When you work, you set the person in charge or the person in charge at work. These responsible persons have a fixed scope of responsibility. We will take full responsibility for what we are entrusted with. And don't step into the work area that other people are in charge of. "I can't handle that, but Suzuki is in charge, so let me introduce you to that," he said.
Each object has a scope of responsibility. If you think a class isn't beautifully designed, it's basic to consider whether the class's responsibilities are appropriate. Should the class really take charge of the job? Wasn't it supposed to be in charge of another class? Or should I be assigned to a new class separately? It works well if you apply classes to occupations, objects to individuals, and anthropomorphize them. It's dangerous if the object starts to say "I can't deal with that matter ..." in my head.
Just as humans get out of hand when they do too much, objects get out of control when they take too much responsibility.
If a man who is a sales representative starts cleaning just because the lobby is dirty, it may delay the time to go outside, and the suit may get dirty and hinder work. If the general affairs have already arranged a cleaner in the afternoon, the work will be wasted.
Even if you think that you can do this kind of cleaning yourself, do not dare to do it, but contact the general affairs and ask them to arrange a cleaning staff. The general affairs will know about the cleaning staff's arrangements, so they will do well to avoid unnecessary duplicate work.
This is a mistake caused by a sales class male object accessing a global variable called lobby.
To recapitulate what I want to say so far, when thinking about object-oriented design, if you anthropomorphize an object and let it talk about responsibility, you will be quite addicted to it.
If the number of member functions and member variables increases, it is highly possible that the class is overly responsible. On the other hand, if there are too few objects, it may be an unnecessary object that is skipping work. Keep it at a reasonable particle size.
Alright, if you keep the object's responsibilities properly, it will work. I feel like I can make it well ... For a while, as the program gets bigger, it still gets messy. Why is this the limit of object orientation ...
No, keeping an object's scope of responsibility at the right level of granularity is just the basis of object orientation. From that point on, "relationship" becomes important. An association is a connection between objects. Speaking of a company, it is an organizational chart or a contact point.
How should we think about the relationship in terms of object orientation? You can refer to the design pattern as one of the methods. A design pattern is a catalog of software designs created in an object-oriented manner. If you google, various things will come out, so I will omit the details.
This design pattern, GoF, is famous, but to be clear, it's not so neatly organized. Some people use it often, others don't use it like this. In addition to GoF, various patterns are naturally conceivable, but there is no trend to research and systematize the entire industry.
Still, a quick look at GoF will give you an idea of what beautiful object-oriented design is.
UML
Another way is to illustrate. It doesn't have to be UML, but it's standardized, so let's use UML. There are various diagrams, but class diagrams are important in object-oriented design.
Roughly speaking, a beautiful design will make the class diagram beautiful, and a dirty design will make the class diagram dirty. If the related lines get messed up, just fix them and the design will be semi-automatically beautiful. Also, if you make a diagram, it will be easier to receive reviews (advice from other people).
UML drawing has its own tools, but I'm Visio or handwritten. If you try to write the detailed design of the software in Visio, you will die, but it is wrong to use UML in the first place. When drawing a diagram, you should focus on the points you want to consider. Not the entire software, but only the library or specific functions. Only in places where it has become difficult to make. It is foolish to draw a line related to the string class from all classes.
Drawing a diagram with a focus on the points makes it easier to think about the design, make it easier to review, and make the document easier to read. While drawing a diagram that exceeds A4 in Visio, I can not say that I have a proper sense of particle size.
If you don't understand inheritance and polymorphism, you can't say that you understand object-oriented programming. But inheritance and polymorphism are just one type of relationship between objects. If you're reading this article, you're a good person, and you'll understand it after playing around with the right object-oriented language for a while. Therefore, the explanation is omitted.
Considering the relationships between objects based on the basics of object responsibility, it turns out that object-oriented design is nothing more than designing relationships between objects. It should come.
Well, if you keep the scope of responsibility of the objects compact and think carefully about the relationships between each object using design patterns and UML, you can create a beautiful program.
However, when the program becomes huge, it is difficult to do so. The most common mistake is relaying the message of a message game.
"I would like to purchase your company's parts. Could you give me an estimate?" "Please wait a moment." "Company A wants to buy those parts." "If you do not get wholesale from company B, it will sell. Check with Company B to see if it's not there. "" I'd like to purchase your company's parts. Can you give me an estimate? "
It is still permissible if there are only 2 or 3 characters in such a message game, but be careful if the hierarchy becomes deeper with 4 or 5 people. Especially, it is dangerous to call it twice or three times just to get the data.
Put a database to solve this problem. A database is like a message board. If the price was posted on Company B's web page, it was not necessary to contact Company A.
The database here is used in a broad sense as a mere common data storage area. It can be a real relational DB, an in-memory DB, a file, or a globally accessible key-value pair of memory storage.
It is also possible to split a process if the database is out of the process's memory. If it is possible to divide the entire application into smaller processes and implement the entire application, the granularity of each process can be reduced.
This database is the global variable itself. Even though we have separated the scope of responsibility in an object-oriented manner, what should we do with all the responsibilities?
Since the database is a global variable, it is better not to introduce it. Small programs should be manageable within the object-oriented range as much as possible. If your program grows huge and you start to feel that the whispers game is over, then consider introducing a database for the first time.
Global variables often have dire consequences. It easily breaks down if the amount of code increases even a little. With the introduction of object-orientation, you can withstand a significant amount of code. However, if the program becomes too large, it will cause a storm of message games and cause another ruin.
Databases handled by less-skilled programmers can be disastrous. However, if the heroes who have mastered object-oriented programming gather and access the database within the scope of responsibility of each class, it will be possible to achieve both object-oriented programming and database at a high level. The only way to balance that is to work hard with high aspirations.