Here are some of the OOD design that I have accumulated from all walks of life, that is, where you need to pay attention to the object-oriented design, integrated use of the following points to help plan a good design. I hope that this information can be useful to everyone, I will slowly accumulate some other design means over time, so I hope everyone will come to my blog to see. ^ _ ^
Commonality-Variability searching Decomposing a problem domain by the responsibilities involved. Specifying relationship between objects. Objects are well defined responsibilities. Objects are responsible for themselves. Think of inheritance as a method of conceptualizing variation, not for making special cases of existing objects. Try Hard to apply the once and only overce rule.
CommONAalog-variability search: Another sentence describes it is: "Find what varies and encapsulate it!". This is the basics of design, design when designers should find out which parts are constant or not good in the system, which parts are good or must change, so that the part of the good changes can be made. Package. This is a key part of object-oriented design principles OCP (Open-Close Princi), because the unclear part can be packaged in the future, and the constant part is sealed, thus The purpose of reaching the modification is not allowed.
Decomponsibilities Involved: Put the problem according to the responsibilities, so that the design idea can be established through OOD, and the object is to define a clear duty, then the problem is equivalent to dividing the demand object. But actually these two definitions are not equal. The first one is abstract, which describes the problem of responsibility, but the definition of the specific responsibility has not been explained, but the second is more embassy, which uses the responsibilities to define a clear target to achieve duty. Note that the design means is very abstract, which is very compliant with the DIP (Dependency Inversion Princi) in the OOD.
Specifying Relationship Between Objects: The relationship between the specified object is meaningless. It must have some relationship between the objects to make them interact, this step is to consider the relationship between the objects during design. It is not appropriate to see that the relationship is not suitable, or the object definition is not accurate. Note that the relationship between objects is not equivalent to coupling between them, and abstraction has a lot of contributions in loose coupling.
Objects Are Well Defined Responsibilities: Object is a clear definition responsibility. In general, people look at the collection of data methods, or someone does not consider objects, but considers classes. People don't spend too much time to consider what is an object, how to define an object, which makes the coupling of the objects in the system high, the system is very bloated or transitional, which makes the expansion become an incredible jobs. Note that classes and objects are different, and the object is multiple concept. When designing the object as a responsibility will lead the designer in the correct design idea from the beginning.
Objects Are Responsible for themselves: The object is the most basic unit in OOP. It can be said that it is an original unit (Atomic), the object is responsible for yourself, that is, a design proper object cannot wait for another object to perform himself Perform the duties. For example, a file object (physical file) should handle the opening and closing of a particular file, rather than opening it in an object and waiting another object to close it. Think of Inheritance As a Method Of Conceptualizing Variation, Not for Making Special Cases of Existing Objects: This design means suggests that inheritance in OO is a means of changing concepts, not as a means of special cases of objects. The so-called special case is, such as a series of special cases for an existing "cat" object, such as "Persian Cat", "Garfield". The so-called change is referred to as inheritance methods used in factory method patterns. In fact, the design mode is the means of application inheritance as a means of changing. In most of the ready-made design patterns, we can use it to reuse as long as the design mode is an embodiment of the OOD principle. In complex systems, it is more important to pay more attention to this design, because complex object special cases make the entire system difficult to maintain, that is, it is not good to support OCP.
Try Hard to Apply The overce and only overce rule: "Once, only once" rules say that good habits are only written in one place, the same code is not written twice. One approach is to extract the same part of the similar code in the similar code, and the other is to redistribute roles (responsibilities). This not only reduces the control of the bug that may be generated during the change, but also requires the programmer to consider how to plan the duties before writing the code, and do the best design. Therefore, please apply this rule as much as possible.
Some of the above design methods are definitely not all design methods, and some other design methods are waiting for us to discover, and these are all experienced accumulation, so they are very valuable, I hope to help everyone, In addition, I hope that everyone will summarize their design experience to blog. After all, the purpose is to share valuable experience! ^ _ ^
Reference "Design Patterns Explained" Other
