Arthur J. Riel once said that you do not have to strictly adhere to these principles, and there will be no religious penalty for violating them. But you should think of these principles as alarm bells. If one of them is violated, the alarm bell will sound. Therefore, no matter what we do, we must have a principle. Programming is no exception. The following introduces the principles of PHP object-oriented analysis and design.
(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 rely on its users.
(3) Minimize the messages in the class protocol.
(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) Do not put implementation details (such as private functions that place shared code) into the public interface of the class.
If two methods of a class have a common code, then you can create a private function that prevents this common code.
(6) Do not disturb the public interface of a class with things that users cannot use or are not interested in.
(7) There should be zero coupling between classes, or only derived 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) Classes 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) Centralize related data and behaviors.
Designers should pay attention to 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 (that is, the behavior of not communicating with each other).
Move towards stable dependencies.
(11) Make sure that the abstract concepts 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: according to design, top-level classes should share work uniformly.
(13) Do not create omnipotent 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 define a large number of access methods in the 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 do not communicate with each other.
Another manifestation of this problem is creating a lot of get and set functions in the public interface of the class 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 as much as possible according to the real world (we often violate this principle in order to comply with the system function distribution principle, avoid the all-purpose class principle, and centrally place related data and behaviors).
(18) Remove unnecessary classes from your design.
Generally speaking, we will 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 that 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 of a class.
The number of other classes used by a class should be as small as possible.
(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) Try to reduce 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 relationship always implies a use relationship.
(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) Allow system functions to be distributed vertically in a narrow and deep inheritance system.
(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 in the deepest inclusion level allowed by the constructor domain.
(32) If the semantic information that 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 depends rarely changes, it is best distributed among the various classes involved in the constraint.
(34) The class must know what it contains, but it cannot know 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 the base class, and base classes should not know any information about their derived classes.
(38) All data in the base class should be private, do not use protected data.
Class designers should never put things in public interfaces 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) Put commonalities in data, behavior, and/or interfaces as high-end as possible in the inheritance hierarchy.
(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 start from a common base class only when they need to be used polymorphically. inherit.
(47) The case-by-case analysis of the display of object types is generally wrong. In most such cases, designers should use polymorphism.
(48) Situational 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) Do not 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) Do not turn class objects into derived classes. Be careful with any derived class that has only one instance.
(51) If you think 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 an empty method (that is, a method that does nothing) in a derived class to override a method in the base class.
(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 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 derived? Part of a class?
(57) If you find multiple inheritance relationships 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 class objects. Class variables or class methods should be used.
(60) Object-oriented designers should not let physical design principles undermine their logical design. 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.
I hope the 61 PHP programming principles introduced above can help you.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
