61 experience principles for object-oriented design
Excerpt from "OOD Revelation" --Arthur J.RIL
(1) All data should be hidden inside the location of the class. The user of the P13 (2) class must depend on the common interface of the class, but the class cannot rely on its users. P15 (3) minimize the message in the protocol of the class. P16 (4) Implementing all classes of the most basic public interface [for example, copy operation (deep copy and shallow copy), equivalent judgment, correct output content, from ASCII description, etc.]. P16 (5) Do not place the implementation details (such as a private function to place a shared code) in the public interface of the class. P17 If two methods of the class have a public code, you can create a private function that prevents these public code. (6) Do not disturb the public interfaces that users who cannot use or not interested. The P17 (7) class should be zero or only the export coupling relationship. That is, a class either does not have a relationship with another class, or only the operation in another class's public interface. The P18 (8) class should only represent a key abstraction. All classes in the P19 package should be commonly closed for changes in the same type of nature. A variation is influenced to a packet, it will affect all classes in the package, and other packets do not have any effects. (9) Content set the relevant data and behavior. P19 designers should pay attention to objects that get data from other objects through the GET. This type of behavior suggests that this experience principle is violated. (10) Place the unrelated information in another class (that is, the behavior that does not communicate with each other). P19 is dependent on a stable direction. (11) Make sure the abstraction of your modeling is class, not just the role of the object. P23 (12) is uniformly distributed in the horizontal direction, namely: according to the design, the top level should be unified to share the work. P30 (13) Do not create a full range / object in your system. It is particularly careful to include Driver, Manager, System, and Susystem. P30 plans an interface instead of implementing an interface. (14) Carefulness to 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 centralized. P30 (15) is more careful to the class containing too many mutual communication. Another expression of P31 This is a lot of GET and SET functions in the public interface of the classes in your application. (16) In applications consisting of object-oriented models interacting with the user interface, the model should not depend on the interface, and the interface should depend on the model. P33 (17) is modeled as much as possible (we often avoid this principle in order to comply with the principles of system functionality, avoid all-round principles, and the principles of focus on relevant data and behavior). P36 (18) removes unwanted classes from your design. P38 Generally, we will degrade this class into an attribute. (19) Remove the class outside the system. The features of the P39 system are characterized by abstraction to send messages to the system field but do not accept other classes in the system. (20) Do not turn the operation into a class. Questioning any name is a verb or derived automatic word, especially if there is only one meaningful class. Consider whether the meaningful behavior should be migrated to a certain class that already exists or has not found out. P40 (21) We often introduce proxy classes when creating an application's analysis model. In the design phase, we will often find that many agents are useless and should be removed. P43 (22) minimize the number of collaborators of classes. The number of other classes used by P52 should be as small as possible. (23) minimize the number of messages transmitted between classes and collaborators. P55 (24) minus the collaboration between classes and collaborators, namely: reducing the number of different messages transmitted between classes and collaborators. P55 (25) minimize the fan out of the class, that is, reduces the number of messages defined and the number of messages transmitted. P55 (26) If the class contains another class, then the included object should send a message to the included object. That is, the relationship is always means using the relationship. Most methods defined in the P55 (27) class should be used in most of the time. The number of objects included in the P57 (28) class should not exceed the cost of developers short-term memory. This number is often 6. P57 When the class contains more than 6 data members, the logical data member can be divided into a group, and then use a new containment class to contain this group of members.
(29) Let the system function vertically distributed in a narrow and deep inheritance system. P58 (30) When implementing semantic constraints, it is best to implement according to class definitions. This often leads to the class flooding, in which case the constraint should be implemented in the behavior of the class, usually implemented in the constructor, but it is not necessary. When P60 (31) implements semantic constraints in the constructor of the class, the Constraint Test is placed in the area of the constructor in the field of constructors. The semantic information depented by the P60 (32) constraint If it is often changed, it is preferably placed in a centralized third-party object. Semantic information relying on the P60 (33) constraint If few changes, it is best to distribute the various classes involved in the constraint. P60 (34) class must know what it contains, but can't know who contains it. P61 (35) Sharing Field Range (that is, objects included by the same class) should not have a relationship with each other. P61 (36) Inherit should only be used to model the primitive hierarchy. P74 (37) Detective class must know the base class, the base class should not know any information about their derived class. All data in the P74 (38) base class should be private, do not use protection data. P75 designers will never put things that users don't need in the public interface. (39) In theory, the inheritance hierarchy should be a little deep, the better the better. P77 (40) In practice, the depth of inheritance hierarchy should not exceed a short-term memory capability of an ordinary person. A widely accepted depth value is 6. All abstractions of P77 (41) should be base classes. All base classes of P81 (42) should be an abstract class. P82 (43) Put the commonality of data, behavior, and / or interface to the high end of the inheritance hierarchy. P85 (44) If two or more class shares public data (but no public behavior), the public data should be placed in a class, and each sharing of this data contains this class. P88 (45) If two or more class has a common data and behavior (that is, method), each of these classes should be inherited from a common base class that represents these data and methods. P89 (46) If two or more class shares public interfaces (referring to messages, not methods), then they should only inherit from one public base class when they need to be used polymorphically. P89 (47) Analysis of the display of the display of the object type is generally wrong. In most cases, the designer should use the polymorphism. P89 (48) The analysis of the display of attribute values is often erroneous. The class should decouple a synthesis of a inheritance hierarchy, each attribute value being transformed into a derived class. P96 (49) Do not model the dynamic semantic modeling of the class by inheritance relationship. Trying to use static semantic relationships to model dynamic semantic switches. P97 (50) Do not turn the objects of the class into a school. Be careful with any exemplary derived class. P99 (51) If you feel that you need to create a new class at runtime, then let's take a step to recognize the object you want to create. Now, these objects are now summarized into a class. P103 (52) The method of overwriting the base class in the derived class (that is, what is not doing the method) should be illegal. P103 (53) Do not confuse the optional containing the need for inheritance. The optional containment to build a category that will bring inheritance. P108 (54) Try creating a reused framework when creating inheritance hierarchies, not a reusable component. P112 (55) If you use multiple inherits in the design, you must assume that you have made mistakes. If you don't make mistakes, you need to try to prove. P120 (56) As long as the inheritance is used in object-oriented design, ask yourself two questions: (1) Is the derived class a special type of what it inherited? (2) Is the base class not part of the derived class? P121 (57) If you find multiple inheritance relationships in an object-oriented design, make sure no base class is actually a derived class of another base class. P122 (58) If you need to make a selection between the relationship and association relationships in the object-oriented design, select the relationship. P123 (59) Do not work for global data or global functions for the meter of the object of the class. Class variables or class methods should be used.
