You do not have to strictly adhere to these principles, and there are no religious penalties for violating them. But you should think of these principles as alarm bells. If one of them is violated, the alarm bell will sound.
(1) All data should be hidden inside the class where it is located.
(2) Users of a class must rely on the shared 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 piece of code, you can create a private function that prevents that common code.
(6) Do not disturb the public interface of the 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) A class 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 be aware of 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 category (that is, the behavior of not communicating with each other). Make dependencies toward stability.
(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 the 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 classes in your application.
(16) In an application consisting 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 according to the real world as much as possible (we often violate this principle in order to comply with the principle of system function distribution, avoid the all-purpose class principle, and centrally place relevant data and behaviors).
(18) Remove unnecessary classes from your design. Generally, we would 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 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 a class contains an object of another class, the containing class should send a message to the contained object. That is: an inclusion relation always implies a use relation.
(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) Let system functions be distributed vertically in a narrow and deep inheritance system.
(30) When implementing semantic constraints, it is best to implement them according to 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 domain of the constructor.
(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 constraints rely rarely changes, it is best distributed among the classes involved in the constraints.
(34) A 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 about base classes, 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 a public interface 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 data, behavior and/or interface commonality as high 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 inherit from a common base class only if they need to be used polymorphically.
(47) Case-by-case analysis of the display of object types is generally wrong. In most such cases, designers should use polymorphism.
(48) Case-by-case 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) Do not 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 have made a mistake. If you didn't make 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 the thing it inherits? (2) Is the base class part of the derived class?
(57) If you find multiple inheritance 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 objects of a class. Class variables or class methods should be used.
(60) Object-oriented designers should not let physical design principles undermine their logical designs. 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.