Things to know about object-oriented design in PHP_PHP tutorial

You do not have to strictly adhere to these principles, and there are no religious penalties for violating them. But you should think of these principles as alarm bells. If one of them is violated, the alarm bell will sound. -----Arthur J.Riel

1. All data should be hidden inside the class.
2. Users of a class must rely on the public interface of the class, but a class cannot depend on its users.
3. Minimize messages in class protocols.
4. Implement the most basic public interface that all classes understand [for example, copy operations (deep copy and shallow copy), equality judgment, correct output content, parsing from ASCII description, etc.].
5. Don’t put implementation details (such as placing private functions with shared code) in the public interface of the class. If two methods of a class have a common piece of code, you can create a private function that prevents that common code.
6. Don’t mess with the public interface of a class with things that users can’t use or are not interested in.
7. There should be zero coupling between classes, or only exported coupling relationships. That is, one class either has nothing to do with another class, or it only uses operations in the public interface of another class.
8. A class should represent only one key abstraction. All classes in the package should be jointly closed for changes in the same type of properties. If a change affects a package, it will affect all classes in the package, but will not have any impact on other packages.
9. Place relevant data and behaviors in one place. Designers should be aware of objects that obtain data from other objects through operations such as get. This type of behavior implies that this empirical principle is violated.
10. Put irrelevant information in another class (ie: behavior that does not communicate with each other). Dependence towards stability.
11. Make sure the abstractions you model are classes, not just the roles played by objects.
12. Distribute system functions as uniformly as possible in the horizontal direction, that is: by design, top-level classes should share work uniformly.
13. Do not create catch-all classes/objects in your system. Be especially careful with classes whose names include Driver, Manager, System, and Susystem. Plan an interface rather than implement an interface.
14. Be careful with classes that have a large number of access methods defined in their public interface. The large number of access methods means that relevant data and behavior are not stored centrally.
15. Be careful with classes that contain too many behaviors that don’t communicate with each other. Another manifestation of this problem is creating a lot of get and set functions in the public interface of the classes in your application.
16. In an application composed of an object-oriented model that interacts with the user interface, the model should not depend on the interface, but the interface should depend on the model.
17. Model the real world as much as possible (we often violate this principle in order to comply with the principle of system function distribution, avoid the principle of all-purpose classes, and centrally place relevant data and behaviors).
18. Remove unnecessary classes from your design. Generally, we would downgrade this class to a property.
19. Remove classes outside the system. The characteristic of classes outside the system is that, in abstract terms, they only send messages to the system domain but do not accept messages from other classes in the system domain.
20. Don’t turn operations into classes. Question any class whose name is a verb or derived from a verb, especially a class with only one meaningful action. Consider whether the meaningful behavior should be moved to a class that already exists or has not yet been discovered.
21. We often introduce proxy classes when creating analysis models of applications. During the design phase, we often find that many agents are useless and should be removed.
22. Minimize the number of collaborators for a class. The number of other classes used by a class should be kept to a minimum.
23. Minimize the number of messages passed between classes and collaborators.
24. Minimize the amount of collaboration between classes and collaborators, that is: reduce the number of different messages passed between classes and collaborators.
25. Minimize the fan-out of the class, that is: reduce the product of the number of messages defined by the class and the number of messages sent.
26. If a class contains an object of another class, the containing class should send a message to the contained object. That is: an inclusion relation always implies a use relation.
27. Most methods defined in a class should use most data members most of the time.
28. The number of objects contained in a class should not exceed the capacity of the developer's short-term memory. This number is often 6. When a class contains more than 6 data members, you can divide logically related data members into a group, and then use a new containing class to contain this group of members.
29. Let system functions be distributed vertically in a narrow and deep inheritance hierarchy.
30. When implementing semantic constraints, it is best to implement them based on class definitions. This often leads to class overflow, in which case the constraints should be implemented in the behavior of the class, usually but not necessarily in the constructor.
31. When implementing semantic constraints in the constructor of a class, place the constraint test at the deepest inclusion level allowed by the constructor domain.
32. If the semantic information that the constraints rely on changes frequently, it is best to put it in a centralized 3rd party object.
33. If the semantic information on which a constraint relies rarely changes, it is best distributed among the classes involved in the constraint.
34. A class must know what it contains, but not who contains it.
35. Objects that share literal scope (that is, are contained by the same class) should not have a usage relationship with each other.
36. Inheritance should only be used to model specialization hierarchies.
37. Derived classes must know about the base class, base classes should not know anything about their derived classes.
38. All data in base classes should be private, do not use protected data. Class designers should never put things in a public interface that are not needed by users of the class.
39. In theory, the inheritance hierarchy should be deeper, the deeper the better.
40. In practice, the depth of the inheritance hierarchy should not exceed the short-term memory capacity of an average person. A widely accepted depth value is 6.
41. All abstract classes should be base classes.
42. All base classes should be abstract classes.
43. Place commonalities in data, behavior, and/or interfaces as high up in the inheritance hierarchy as possible.
44. If two or more classes share common data (but no common behavior), then the common data should be placed in a class that is included in each class that shares this data.
45. If two or more classes have common data and behavior (that is, methods), then each of these classes should inherit from a common base class that represents these data and methods.
46. If two or more classes share a common interface (referring to messages, not methods), then they should inherit from a common base class only if they need to be used polymorphically.
47. Case-by-case analysis of the display of object types is generally wrong. In most such cases, designers should use polymorphism.
48. Case-by-case analysis of the display of attribute values ​​is often wrong. Classes should be decoupled into an inheritance hierarchy, with each attribute value transformed into a derived class.
49. Don’t model the dynamic semantics of a class through inheritance relationships. Attempting to model dynamic semantics with static semantic relations results in switching types at runtime.
50. Don’t turn objects of a class into derived classes. Be careful with any derived class that has only one instance.
51. If you feel you need to create a new class at runtime, take a step back and realize that you are creating objects. Now, generalize these objects into a class.
52. It should be illegal to use empty methods (that is, methods that do nothing) in derived classes to override methods in base classes.
53. Don’t confuse optional inclusion with the need for inheritance. Modeling optional inclusion as inheritance leads to a proliferation of classes.
54. When creating inheritance hierarchies, try to create reusable frameworks rather than reusable components.
55. If you use multiple inheritance in your design, assume you have made a mistake. If you didn't make a mistake, you need to try to prove it.
56. As long as inheritance is used in object-oriented design, ask yourself two questions: (1) Is the derived class a special type of the thing it inherits? (2) Is the base class part of the derived class?
57. If you find multiple inheritance in an object-oriented design, make sure that no base class is actually a derived class of another base class.
58. In object-oriented design, if you need to choose between inclusion and association, please choose inclusion.
59. Do not use global data or global functions for bookkeeping of objects of a class. Class variables or class methods should be used.
60. Object-oriented designers should not let physical design principles undermine their logical designs. However, we often use physical design criteria in making decisions about logical design.
61. Do not bypass the public interface to modify the state of the object.

http://www.bkjia.com/PHPjc/752490.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/752490.htmlTechArticleYou do not have to strictly adhere to these principles, and there will be no religious penalties for violating them. But you should think of these principles as alarm bells. If one of them is violated, the alarm bell will sound. ...