61 articles on Object-Oriented Analysis and Design in PHP

(1) All data should be hidden inside the class.
(2) A class user must depend on the common interfaces of the class, but the class cannot depend on its users.
(3) Minimize messages in the protocol of the class.
(4) implement the most basic public interfaces that all classes understand [for example, copy operations (deep copy and shallow copy), equality judgment, correct output content, parsing from ASCII descriptions, etc.].
(5) do not share implementation details (such as sharing Code To the public interface of the class.
If two methods of the class have a piece of public code, you can create a private function to prevent the public code.
(6) do not disturb the public interface of the class with something that the user cannot use or is not interested in.
(7) There should be zero coupling between classes, or only export Coupling Relationships. That is, a class is either unrelated to the other class, or only uses operations in the public interface of the other class.
(8) the class should only represent a key abstraction.
All classes in the package should be closed for changes to the same class nature. If a change affects a package, it will affect all classes in the package, without affecting other packages.
(9) place relevant data and behaviors in a centralized manner.
Designers should pay attention to the objects that obtain data from other objects through get and other operations. This type of behavior implies that this principle of experience has been violated.
(10) Place irrelevant information in another class (that is, non-communication behavior ).
Dependency in a stable direction.
(11) Make sure that the abstract concept you are modeling for is a class, not just the role played by an object.
(12) Distribution of system functions in the horizontal direction as much as possible, that is, the top-level classes should share work in a unified manner according to the design.
(13) do not create all-powerful classes/objects in your system. Be especially careful about the classes whose names include driver, Manager, system, and susystem.
Plan an interface instead of implementing an interface.
(14) Be careful with classes that define a large number of access methods in public interfaces. A large number of access methods mean that related data and behaviors are not stored in a centralized manner.
(15) Be careful with classes that contain too many non-communication behaviors.
Another manifestation of this problem is in your application. Program Many get and set functions are created in the public interface of the class.
(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) modeling in the real world as much as possible (we often violate this principle in order to comply with the principles of system function distribution, to avoid all-encompassing principles, and to centralize the placement of relevant data and behavior ).
(18) Remove unnecessary classes from your design.
In general, we will downgrade this class to an attribute.
(19) Remove classes outside the system.
Classes outside the system are abstracted to send messages only to the system domain, but do not accept messages sent from other classes in the system domain.
(20) do not change operations into classes. Question any class whose name is a verb or a derived Automatic Word, especially a class with only one meaningful action. Consider whether the meaningful behavior should be migrated to an existing or undiscovered class.
(21) We often introduce a proxy class when creating an analysis model for an application. In the design phase, we often find that many agents are useless and should be removed.
(22) Minimize the number of collaborators of classes.
The number of other classes used by a class should be as small as possible.
(23) Minimize the number of messages transmitted between classes and collaborators.
(24) minimize the amount of collaboration between classes and collaborators, that is, reduce the number of different messages transmitted between classes and collaborators.
(25) Minimize fan-out of a class, that is, reduce the product of the number of messages defined by the class and the number of messages sent.
(26) if the class contains an object of another class, the containing class should send a message to the contained object. That is, the inclusion relationship always means that the link is used.
(27) Most methods defined in a class should use most data members most of the time.
(28) The number of objects contained in the class should not exceed the developer's short-term memory capacity. This number is usually 6.
When a class contains more than 6 data members, you can divide Logical Data members into a group, and then use a new include class to include the group members.
(29) vertical distribution of system functions in a narrow and deep inheritance system.
(30) when implementing semantic constraints, it is best to implement them according to the class definition. This often causes class flooding. In this case, constraints should be implemented in class behavior, usually in constructors, but not necessarily.
(31) when implementing semantic constraints in class constructor, place the constraint test in the include level as deep as possible allowed in the constructor field.
(32) if the semantic information on which the constraint depends changes frequently, it is best to put it in a centralized 3rd-party object.
(33) if the semantic information on which the constraint depends is rarely changed, it is best to distribute it among the classes involved in the constraint.
(34) The class must know what it contains, but cannot know who contains it.
(35) objects in the shared literal scope (that is, objects contained by the same class) should not be used with each other.
(36) inheritance should only be used to model the special hierarchies.
(37) The derived class must know the base class, and the base class should not know any information about their derived classes.
(38) All data in the base class should be private. Do not use data protection.
Class designers should never put things that class users don't need in public interfaces.
(39) theoretically, the hierarchy of inheritance should be deeper, the deeper the better.
(40) In practice, the depth of the hierarchy should not exceed the short-term memory capacity of an ordinary 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 data, behavior, and/or interface commonalities as high as possible in the inheritance hierarchy.
(44) If two or more classes share public data (but there is no public behavior), put public data in one class, each class that shares this data includes this class.
(45) If two or more classes share the same data and behavior (that is, the method ), each of these classes should inherit from a public base class that represents the data and methods.
(46) If two or more classes share public interfaces (refers to messages, rather than methods), only when they need to be used in a polymorphism, they should inherit from a public base class.
(47) The analysis of the points displayed on the object type is generally incorrect. In most cases, the designer should use polymorphism.
(48) The analysis of the score displayed for the attribute value is often incorrect. Class should be decoupled into an inheritance hierarchy, and each property value is transformed into a derived class.
(49) do not use inheritance relationships to model the dynamic semantics of classes. If you try to use a static semantic relationship to model dynamic semantics, the type will be switched during runtime.
(50) do not convert the class object into a derived class. Be careful with any Derived classes that only have one instance.
(51) If you think you need to create a new class at runtime, take a step back to recognize that you want to create an object. Now, we can generalize these objects into a class.
(52) it should be illegal to overwrite the methods in the base class by using an empty method (that is, a method that does nothing) in the derived class.
(53) do not confuse optional items with the requirements for inheritance. Model the optional include into a class that inherits and can cause flooding.
(54) try to create reusable frameworks rather than reusable components when creating an inheritance hierarchy.
(55) If you use multiple inheritance in the design, first assume that you have made a mistake. If you do not make a mistake, try to prove it.
(56) as long as inheritance is used in object-oriented design, I have 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 relationships in an object-oriented design, make sure that no base class is actually a derived class of another base class.
(58) in the object-oriented design, if you need to select between the included and associated relationships, select the included relationship.
(59) do not use global data or global functions to note the work 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 principles when making decisions on logical design.
(61) do not modify the object state without bypassing the public interface.