Opening of OOD Design Principles

When I want to record something, I first think of these good principles. To be honest, my own understanding of these principles can only be a bit confusing. I have been doing good by myself for some years, but in actual projects, the design is based on the requirements of these principles, and I know it has not reached that level. These principles are like the hot design patterns that have been around for years and cannot be used as a reference. They can be used to "assemble" qualified designs or codes, nor can they be used as a yardstick, check the design and code one by one. However, the reason why these principles can be established is that they can be widely circulated or even regarded as a GUI. Remember Arthur J. Riel 《Object-oriented design heuristicsAs mentioned in the book (the original article does not remember), these are not laws or the Bible, and they will not be punished if they violate it. However, we should regard them as warning bells. Once a violation occurs, the warning bells will ring. This is probably the meaning.

In fact, violations of these principles will actually be punished. However, it may not be the first designer to be punished. It may be your partner, your successor, or someone else you have taken on your behalf. Such a scenario often occurs when the project is completed, during testing, and during re-development, it may suddenly jump out when you don't care at all. I have seen that many projects do not even have the most basic UML diagrams. Except for the designers themselves, it is basically difficult for others to understand the structure of the system. All these projects are called OOA/ood projects. Therefore, it is exaggerated to say that many actual projects are called oo only because the C ++/Java language is used and the Code contains a bunch of classes.

Why is it like this? I am afraid I am not able to clarify this issue. However, in my experience, there are two similar mistakes. One is education, and the other is practice. I have taught a few oo classes, and I don't even know what the program is. They only want to learn something, get a certificate, and then go out to a job. Such a course cannot be called Oo, and what you learn diligently is the language itself. In the future, when they get to work, the actual work will only be coding. There will be a bunch of coding people together, and no one will do OOA/ood. That's it.

It's too far away. We also talk about these good principles. I have also worked on a number of projects and made numerous troubles for others and helped others solve them, so that I realized the importance of these principles. There are actually many such principles. riel mentioned about 60 in his book. What I want to record is only a small part of it, which is widely known and often ignored. There will be the principle of open and closed, the principle of replacement by the river, and the principle of dependency reversal. Interface isolation principle, single responsibility principle, and so on.