The experience principle of object-oriented analysis Design in PHP _php skills

(1) All data should be hidden inside the class in which it is located.
(2) The consumer of a class must rely on the common interface of the class, but the class cannot rely on its users.
(3) Minimize the message in the class protocol.
(4) Implement the most basic public interfaces understood by all classes [for example, copy operations (deep and shallow copies), equality judgments, correct output, parsing from ASCII, and so on].
(5) Do not place implementation details (such as private functions that place common code) into the public interface of the class.
If the two methods of a class have a piece of common code, you can create a private function that prevents these common code.
(6) Do not disturb the public interface of the class with something that the user cannot use or is not interested in.
(7) The class should be 0 coupled, or only the coupling relationship should be derived. That is, a class has nothing to do with another class, or it uses only operations in the public interface of another class.
(8) A class should only represent a critical abstraction.
All classes in a package should be closed together for changes of the same nature. If a change affects a package, it will have an effect on all classes in the package and not on the other packages.
(9) Place the relevant data and behavior in a centralized position.
Designers should be aware of objects that fetch data from other objects through a get operation. This type of behavior implies that the rule of thumb has been violated.
(10) To put irrelevant information in another class (i.e., the behavior of mutual communication).
depend on the direction of stability.
(11) Make sure that the abstract concept you are modeling is a class, not just the role of the object.
(12) Distribute the system function as uniformly as possible in the horizontal direction, namely: according to the design, the top-level class should share the work uniformly.
(13) Do not create a universal class/object in your system. Be especially careful with names that contain driver, Manager, System, and Susystem classes.
Plan an interface instead of implementing an interface.
(14) Be more careful with classes that define a large number of access methods in the public interface. A large number of access methods means that the relevant data and behavior are not centrally stored.
(15) Be more careful with classes that contain too much communication behavior.
Another manifestation of this problem is the creation of many get and set functions in the public interface of the classes in your application.
(16) In an application composed of an object-oriented model interacting with the user interface, the model should not be dependent on the interface, and the interface should be dependent on the model.
(17) modeling as much as possible in the real world (we often violate this principle in order to comply with the principle of system function distribution, to avoid the principle of universal class and to centralize the relevant data and behavior).
(18) Remove unwanted classes from your design.
In general, we will demote this class to a property.
(19) Remove the class outside the system.
Classes outside the system are characterized by an abstraction that sends messages only to the system domain but does not accept messages from other classes in the system domain.
(20) Do not turn the operation into a class. Question any class whose name is a verb or a derived automatic word, especially one that has only a meaningful behavior. Consider whether the 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 an application's analysis model. In the design phase, we often find that many agents are not used, should be removed.
(22) Minimizing the number of collaborators in the class.
The number of other classes used by a class should be as small as possible.
(23) Minimizing the number of messages passed between classes and collaborators.
(24) Minimizing the amount of collaboration between classes and collaborators, i.e. reducing the number of different messages passed between classes and collaborators.
(25) To minimize the fan out of the class, that is, reduce the number of messages defined by the class and the number of messages sent by the product.
(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 relationships.
(27) Most of the methods defined in the class should use most of the data members for most of the time.
(28) The class contains no more objects than the developer's short-term memory capacity. This number is often 6.
When a class contains more than 6 data members, you can divide the logically related data members into one group and then use a new containing class to include the members of the group.
(29) Let the system function in the narrow and deep inheritance system vertical distribution.
(30) When implementing semantic constraints, it is best to implement them according to class definitions. This often leads to a class overrun, in which the constraint should be implemented in the behavior of the class, usually in a constructor, but not necessarily.
(31) When semantic constraints are implemented in the constructor of a class, the constraint test is placed in the deepest level of inclusion allowed in the domain of the constructor function.
(32) If the semantic information on which the constraint is dependent is frequently changed, it is best to place it in a centralized 3rd party object.
(33) If the semantic information that the constraint relies on is rarely changed, it is best 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 range (that is, that is contained by the same class) should not have a use relationship with each other.
(36) Inheritance should only be used to model a specific hierarchy.
(37) Derived classes 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 and do not use protected data.
The designer of a class should never put something that the user of a class does not need in the public interface.
(39) In theory, the hierarchy of succession should be deeper, the deeper the better.
(40) In practice, the depth of the inheritance hierarchy should not exceed the short-term memory ability 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) To put the data, behavior and/or interface of the commonality as far as possible to the hierarchy of inheritance system high-end.
(44) If two or more classes share public data (but no public behavior), then the public data should be placed in a class, and each class that shares the data contains that class.
(45) If two or more classes have common data and behavior (that is, methods), each of these classes should inherit from a common base class that represents the data and methods.
(46) If two or more classes share a common interface (a message, not a method), then they should inherit from a common base class only if they need to be used in a polymorphic way.
(47) The analysis of the display of the object type is generally wrong. In most of these cases, the designer should use polymorphism.
(48) A partial analysis of the display of attribute values is often wrong. A class should be decoupled into an inheritance hierarchy, and each property value is transformed into a derived class.
(49) Do not model the dynamic semantics of a class by inheriting relationships. Attempting to model dynamic semantics with a static semantic relationship causes the type to be switched at run time.
(50) Do not turn the object of the class into a derived class. Be careful with any derived class that has only one instance.
(51) If you feel you need to create a new class at run time, step back to see what you are creating. Now, generalize these objects into a class.
(52) It is illegal to overwrite methods in a base class in a derived class by using an empty method (that is, a method of doing nothing).
(53) Do not confuse the optional inclusion with the need for inheritance. Modeling an optional inclusion into inheritance can lead to an overrun class.
(54) When creating an inheritance hierarchy, try to create a reusable framework, rather than a reusable component.
(55) If you use multiple inheritance in your design, let's assume you made a mistake. If you don't make a mistake, you need to try to prove it.
(56) As long as you use inheritance 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 a 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 object-oriented design, if you need to make a choice between the inclusion and the associated relationship, select the inclusion relationship.
(59) Do not use global data or global functions for the thin work of objects of the class. class variables or class methods should be used.
(60) Object-oriented designers should not allow physical design guidelines to undermine their logical design. However, in the process of making decisions about logical design, we often use physical design guidelines.
(61) Do not bypass the public interface to modify the state of the object.