(1) All data should be hidden inside the class in which it resides.
(2) The consumer of a class must depend on the common interface of the class, but the class cannot rely on its consumer.
(3) Minimize the message in the class's protocol.
(4) Implement the most basic public interfaces understood by all classes [for example, copy operations (deep and shallow copies), equality judgments, correct output content, parsing from ASCII descriptions, etc.].
(5) Do not place implementation details (such as private functions that place common code) in the public interface of the class.
If the two methods of a class have a 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 exported. That is, one class has nothing to do with another class, or it only uses operations in the public interface of another class.
(8) A class should only represent a critical abstraction.
All classes in the package should be closed together for changes of the same class nature. If a change affects one package, it will affect all classes in the package, without any impact on the other packages.
(9) Put the relevant data and behavior in a centralized position.
Designers should be aware of objects that get data from other objects through operations such as get. This type of behavior implies that the rule of thumb has been violated.
(10) Placing irrelevant information in another class (i.e., non-communicating behavior).
To rely on in a stable direction.
(11) Ensure that the abstract concept you are modeling is a class, not just the role that the object plays.
(12) in the horizontal direction as far as possible uniformly distributed system functions, namely: according to design, the top class should be unified to share the work.
(13) Do not create an almighty class/object in your system. Be especially careful with classes whose names contain driver, Manager, System, Susystem.
Plan an interface instead of implementing one.
(14) Be cautious 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 are not centrally stored.
(15) Be cautious about classes that contain too many non-communicating behaviors.
Another manifestation of this problem is that many get and set functions are created in the public interface of the class in your application.
(16) In an application that is composed of an object-oriented model that interacts with the user interface, the model should not be dependent on the interface, and the interface should be dependent on the model.
(17) as much as possible according to the real World modeling (we often violate this principle in order to comply with the principle of system function distribution, avoid the principle of universal class and the principle of centralizing the relevant data and behavior).
(18) Remove unwanted classes from your design.
In general, we will downgrade this class to an attribute.
(19) Remove the class outside the system.
Classes outside the system are characterized by the abstract view that they only send messages to the system domain but do not accept messages from other classes in the system domain.
(20) Do not turn the operation into a class. Challenge any class whose name is a verb or derive an automatic word, especially one that has a 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 an analytic model of an application. In the design phase, we often find that many agents are useless and should be removed.
(22) Minimize the number of collaborators in the class.
The number of other classes used by a class should be as few as possible.
(23) Minimize the number of messages that are 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) Minimize the fan-out of the class, that is, reduce 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 relationships.
Most of the methods defined in the (27) class should use most data members for 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 often 6.
When a class contains more than 6 data members, you can divide the logically related data members into a group, and then use a new containing class to contain the set of members.
(29) The system function is distributed vertically 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 a class overrun, in which case the constraints should be implemented in the behavior of the class, usually implemented in constructors, but not required.
(31) When implementing semantic constraints in the constructor of a class, the constraint test is placed in the deepest inclusion level allowed in the domain of the constructor.
(32) The semantic information on which the constraint relies is often changed, preferably 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 in the various classes involved in the constraint.
(34) A class must know what it contains, but cannot know who contains it.
(35) objects that share literal scope (that is, are contained by the same class) should not be used in relation to each other.
(36) Inheritance should only be used to model the hierarchical structure of 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 protection data.
The designer of a class should never put something that the user of the class does not need in the public interface.
(39) In theory, the hierarchy system of inheritance should be deeper, the deeper the better.
(40) In practice, the depth of the hierarchy of inheritance 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) Put the generality of data, behavior and/or interface as far as possible to the high end of the inheritance hierarchy system.
(44) If two or more classes share common data (but no public behavior), then the public data should be placed in a class, and each class that shares the data contains this 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 (that is, messages, not methods), they should inherit from a common base class only if they need to be used in a polymorphic manner.
(47) The analysis of the display of the object type is generally wrong. In most of these cases, the designer should use polymorphism.
(48) The analysis of the display of attribute values is often wrong. Classes 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. Attempts to model dynamic semantics with static semantic relationships can result in switching types 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, take a step back and recognize that you are creating an object. Now, summarize these objects into one class.
(52) It should be illegal to overwrite 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 the optional inclusion with the need for inheritance. Modeling an optional inclusion into a class where inheritance can lead to flooding.
(54) When creating an inheritance hierarchy, try creating a reusable framework, rather than a reusable component.
(55) If you use multiple inheritance in your design, let's say you made a mistake. If you don't make a mistake, you need to try to prove it.
(56) If you use inheritance in object-oriented design, ask yourself two questions: (1) is the derived class A special type of the thing it inherits from? (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 an inclusive relationship and an associated relationship, select include relationship.
(59) Do not use global data or global functions for the thin-work of objects of a class. You should use class variables or class methods.
(60) Object-oriented designers should not let physical design guidelines undermine their logical design. However, in the process of making decisions on logical design, we often use physical design guidelines.
(61) Do not bypass the public interface to modify the state of the object.
The above describes the object-oriented approach to PHP object-oriented analysis of the design of the 61 military summary, including the object-oriented approach to the content, I hope that the PHP tutorial interested in a friend helpful.
