61 experience principles for object-oriented design
"You don't have to strictly abide by these principles, and violate them will not be punished by religious punishment. But you should look into a warning, if you violate one of them, then the alarm bell will ring." ------ ---- Arthur J.Riel
(1) All data should be hidden inside the location of the class. (2) The user of the class must depend on the co-interfaces, but the class cannot rely on its users. (3) Try to minimize news in the protocol of the class. (4) Implementing all kinds of basic public interfaces, for example, copy operation (deep copy and shallow copy), equivalent judgment, correct output, from ASCII description analysis, etc.]. (5) Do not put the implementation details (such as a private function to place a shared code) in the public interface of the class.
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. (7) There should be zero coupling between the class, 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. (8) The class should only represent a key abstraction. All classes in the 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. The designer should pay attention to the 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). During the stable direction. (11) Make sure your abstraction concept is class, not just the role of the object. (12) Distribute system functions as much as possible in the horizontal direction, namely: according to the design, the top class should be uniformly shared. (13) Do not create a full range / object in your system. It is particularly careful to include Driver, Manager, System, and Susystem. Plan 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. (15) Careful care of the class containing too many mutual communication. Another expression of this problem is to create a lot of GET and SET functions in the public interface of the class 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. (17) In accordance with real-world modeling (we often avoid this principle in order to abide by the principles of system functionality, avoiding all principles of all-round principles, and concentrating relevant data and behavior). (18) Remove unwanted classes from your design. In general, we will degrade this class into an attribute. (19) Remove the class outside the system. The feature of the system outside the system is that it is abstracting the message to send messages to the system in the system but does not accept messages emitted 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. (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. (22) minimize the number of collaborators of classes. The number of other classes used by a class should be as small as possible. (23) minimize the number of messages transmitted between classes and collaborators. (24) minimize the collaboration between classes and collaborators, namely: the number of different messages transmitted between classes and collaborators. (25) Try to minimize the fan out of the class, that is, reducing the number of messages defined and the product of the number of messages sent. (26) If the class contains an object of another class, then the included object should send a message to the included object. That is, the relationship is always means using the relationship. (27) Most methods defined in the class should be used in most of the time. (28) The number of objects contained in the class should not exceed the cost of developers short-term memory. This number is often 6. When the class contains more than 6 data members, logic-related data members can be divided into a group, and then use a new containing class to contain this group of members. (29) Let the system function vertically distributed in a narrow and deep inheritance system. (30) It is best to be implemented according to the class definition when implementing semantic constraints. 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.
(31) When the semantic constraint is implemented in the constructor of the class, the constraint test is placed in the field of constructive functionally allowed contained in the same level. (32) Semantic information depends on the constraint If it is often changed, it is preferably placed in a centralized third-party object. (33) Semantic information relying on constraint If few changes, it is best to be distributed in the various classes involved in the constraint. (34) Class must know what it contains, but can't know who contains it. (35) The shared literal range (which is also included in the same class) should not have a relationship with each other. (36) The inheritance should only be used to model the primitive hierarchy. (37) Detective class must know the base class, the base class should not know any information about their derived class. (38) All data in the base class should be private, do not use protection data. The designer of the class should never put things that are not needed in the public interface. (39) In theory, the inheritance hierarchy should be a little deep, the better the better. (40) In practice, the depth of the inheritance hierarchy should not exceed a short-term memory capability of an ordinary person. A widely accepted depth value is 6. (41) All abstractions should be base classes. (42) All base classes should be an abstract class. (43) Putting the commonality of the data, behavior, and / or interface to the high end of the inheritance hierarchy. (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. (45) If two or more class has a common data and behavior (that is, method), each of these classes should be inherited from a public base class that represents these data and methods. (46) If the two or more class shares (referring to messages, not a method), only when they need to be used polymorphically, they should inherit from one public base class. (47) Analysis of the display of the display of the object type is generally wrong. In most cases, the designer should use the polymorphism. (48) The analysis of the display of attribute values is often wrong. The class should decouple a synthesis of a inheritance hierarchy, each attribute value being transformed into a derived class. (49) Do not model the dynamic semantic mode of the class by inheritance. Trying to use static semantic relationships to model dynamic semantic switches. (50) Do not turn the objects of the class into a school. Be careful with any exemplary derived class. (51) If you feel that you need to create a new class at runtime, let's take a step back to recognize the object you want to create. Now, these objects are now summarized into a class. (52) The method of overwriting the base class in the derived class (that is, what is not doing the method) should be illegal. (53) Do not confuse the optional containing the need for inheritance. The optional containment to build a category that will bring inheritance. (54) Try creating a reused framework when creating inheritance hierarchy, not a reusable component. (55) If you use multiple inheritance in the design, you must assume that you have made mistakes. If you don't make mistakes, you need to try to prove. (56) As long as inheriting in the 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? (57) If you find multiple inheritance relationships in an object-oriented design, make sure no base class is actually a derived class for another base class. (58) In the object-oriented design, if you need to make a selection between the relationship and association relationship, select the relationship. (59) Do not work with global data or global functions for the work of the object of the class. Class variables or class methods should be used. (60) Object-oriented designers should not allow physical design guidelines to destroy their logic design. However, we often use physical design guidelines during decisions for logic design. (61) Do not circumvent the status of the object to modify the object.
