Sixty one catch all for object oriented analysis design in PHP

(1) all data should be hidden inside the class.
(2) the user of a class must rely on the common interface of the class, but the class cannot rely on its user.
(3) minimize messages in the protocol of the class.
(4) implement the most basic public interface that all classes understand [for example, copy operations (deep and shallow), equality judgments, correct output, parsing from ASCII descriptions, and so on].
(5) do not place implementation details (such as private functions that place Shared code) in the public interface of a class.
If the two methods of a class have a piece of public code, you can create a private function that prevents that public code.
(6) do not disturb the public interface of a class with something that the user cannot use or is not interested in.
(7) there should be zero coupling between classes, or only exported coupling relationships. That is, a class either has nothing to do with another class or only USES operations in the public interface of another class.
(8) the class should represent only one key abstraction.
All classes in a package should be collectively closed to changes in the same class property. A change that affects one package will affect all classes in the package, but not all other packages.
(9) centralize relevant data and behaviors.
Designers should be aware of objects that fetch data from other objects through operations such as get. This type of behavior implies that the rule of thumb has been violated.
(10) put irrelevant information in another class (i.e., non-communicative behavior).
Rely in the direction of stability.
(11) make sure that the abstraction you're modeling is a class, not just an object's role.
(12) distribute system functions horizontally as uniformly as possible, i.e., the top-level classes should share work uniformly by design.
(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 instead of implementing one.
(14) be careful about classes that have a large number of access methods defined in the public interface. A large number of access methods means that the relevant data and behavior is not centralized.
(15) be careful of classes that contain too much non-communicating behavior.
Another manifestation of this problem is the creation of many get and set functions in the public interface of 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, the interface should depend on the model.
(17) model as much as possible according to the real world (which we often violate in order to comply with the principle of distribution of system functions, the principle of avoiding all-powerful classes, and the principle of centralizing relevant data and behavior).
(18) remove unwanted classes from your design.
In general, we degrade this class to a property.
(19) remove classes outside the system.
The characteristic of out-of-system classes is that, abstractly, they only send messages to the system domain but do not accept messages from other classes in the system domain.
(20) don't turn an operation into a class. Question any class whose name is a verb or derives an automatic word, especially one that has only one meaningful behavior. Consider whether that meaningful behavior should be migrated to a class that already exists or has not yet been discovered.
(21) we often introduce proxy classes when creating analysis models for our applications. During the design phase, we often find that many agents are useless and should be removed.
(22) minimize the number of class collaborators.
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 the class contains an object of another class, the containing class should send a message to the contained object. That is, including relationships always means using them.
(27) most of the methods defined in the class should use most of the data members most of the time.
(28) classes should not contain more objects than the developer's short-term memory. This number is often 6.
When a class contains more than six data members, logically related data members can be grouped and a new inclusion class can be used to contain 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 leads to class flooding, in which case the constraint should be implemented in the behavior of the class, usually in the constructor, but not necessarily.
(31) when implementing the semantic constraint in the constructor of a class, place the constraint test at the deepest possible level of inclusion allowed by the constructor domain.
(32) if the semantic information on which the constraint depends changes frequently, it is best to place it in a centralized third party object.
(33) if the semantic information on which the constraint depends changes little, it is better to distribute it among the classes involved in the constraint.
(34) a class must know what it contains, but it cannot know who contains it.
(35) objects that share a literal scope (that is, are contained by the same class) should not have usage relationships with each other.
(36) inheritance should only be used to model the specialization hierarchy.
Derived classes must know the base classes, and base classes should not know anything about their derived classes.
(38) all data in the base class should be private, do not use protected data.
The designer of a class should never put something in a public interface that the user of the class does not need.
(39) in theory, the inheritance hierarchy system should be as deep as possible.
(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 the commonality of data, behavior, and/or interfaces as high up in the inheritance hierarchy as possible.
(44) if two or more classes share public data (but no public behavior), the public data should be placed in a class, and each class that shares this data contains this class.
(45) if two or more classes have data and behavior in common (that is, methods), each of those classes should inherit from a common base class that represents those data and methods.
(46) if two or more classes share a public interface (meaning a message, not a method), they should inherit from a common base class only if they need to be used polymorphism.
(47) the sub-case analysis of the display of object types is generally wrong. In most of these cases, the designer should use polymorphism.
(48) the sub-case analysis of the display of attribute values is often wrong. Classes should be decoupled into an inheritance hierarchy, where each attribute value is transformed into a derived class.
(49) do not model the dynamic semantics of classes through inheritance relationships. Trying to model dynamic semantics with static semantic relationships results in switching types at run time.
(50) do not turn an object of a class into a derived class. Be careful with any derived class that has only one instance.
(51) if you feel the need to create a new class at runtime, take a step back to recognize that you are creating an object. Now, summarize these objects into a class.
It should be illegal to override a method in a base class with an empty method (that is, a method that does nothing) in a derived class.
(53) do not confuse optional inclusion with the need for inheritance. Modeling alternative inclusions as inheritance can lead to a proliferation of classes.
(54) when creating inheritance layers, try to create reusable frameworks, not reusable components.
(55) if you use multiple inheritance in your design, assume you've made a mistake. If you haven't made a mistake, you need to try to prove it.
(56) whenever inheritance is used in object-oriented design, ask yourself two questions :(1) is the derived class a special type of what it inherits? (2) is the base class part of a derived class?
(57) if you find multiple inheritance relationships in an object-oriented design, make sure that none of the base classes are actually derived from another base class.
(58) in object-oriented design, if you need to make a choice between the inclusion relation and the association relation, please choose the inclusion relation.
(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 allow physical design principles to undermine their logical design. However, physical design criteria are often used in making decisions about logical design.
(61) do not modify the state of an object by bypassing the public interface.