Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the principles of Java object-oriented design". In daily operation, I believe that many people have doubts about the principles of Java object-oriented design. I have consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what are the principles of Java object-oriented design?" Next, please follow the editor to study!

(1) all data should be hidden inside the class.

(2) the consumer of a class must rely on the common interface of the class, but the class cannot rely on its consumer.

(3) minimize the messages in the protocol of the class.

(4) implement the most basic public interface that all classes understand [for example, copy operation (deep copy and shallow copy), equality judgment, correct output, parsing from ASCII description, etc.].

(5) do not put implementation details (such as private functions that place shared code) in the public interface of the class.

If the two methods of the class have a piece of common code, you can create a private function that prevents that public code.

(6) do not disturb the public interface of the class with something that the user cannot use or is not interested in.

(7) there should be zero coupling or only derived coupling between classes. That is, one class either has nothing to do with another class, or only uses operations in the public interface of another class.

(8) the class should represent only one key abstraction.

All classes in the package should be closed together for changes in the same kind of nature. If a change affects a package, it will affect all classes in the package, but not other packages.

(9) centralize the relevant data and behaviors.

Designers should pay attention to objects that get data from other objects through operations such as get. This type of behavior implies that this empirical principle has been violated.

(10) put irrelevant information in another category (that is, the act of not communicating with each other).

Rely on in the direction of stability.

(11) make sure that the abstract concept you are modeling is a class, not just the role played by the object. Classes should share work uniformly.

Do not create omnipotent classes / objects in your system. Be especially careful with classes whose names contain Driver, Manager, System, and Susystem.

Plan an interface instead of implementing an interface.

(14) be careful with classes that define a large number of access methods in the public interface. A large number of access methods mean that related data and behaviors are not centrally stored.

(15) be careful with classes that contain too many behaviors that do not communicate with each other.

Another manifestation of this problem is the creation of a lot of get and set functions in the public interface of the class in your application.

(16) in an application consisting of an Java object-oriented model that interacts with the user interface, the model should not depend on the interface, and the interface should depend on the model.

(17) Model in the real world as much as possible (we often violate this principle in order to comply with the principle of functional distribution of the system, the principle of avoiding omnipotence, and the principle of centralizing relevant data and behaviors).

(18) remove unnecessary classes from your design.

In general, we will downgrade this class to an attribute.

(19) remove classes outside the system.

The characteristic of classes outside the system is that they only send messages to the system domain but do not accept messages sent by other classes in the system domain.

(20) do not turn operations into classes. Question any class whose name is a verb or derived automatic word, especially if there is only one meaningful act. 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 analytical models of applications. In the design stage, 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 small as possible.

(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 transmitted 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 the class contains an object of another class, the containing class should send a message to the included object. That is, including relationships always means using relationships.

Most of the methods defined in the class should use most of the data members 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 six data members, logically related data members can be divided into a group, and then a new inclusion class is used to include this group of members.

(29) allow system functions to be distributed vertically in a narrow and deep inheritance system.

(30) when implementing semantic constraints, * * is implemented according to the class definition. This often leads to flooding of classes, in which case constraints should be implemented in the behavior of the class, usually in the constructor, but not necessarily.

(31) when implementing semantic constraints in the constructor of a class, the constraint test is placed in the inclusion level as deep as possible in the constructor field.

(32) in Java object-oriented, if the semantic information that constraints depend on changes frequently, then * * is placed in a centralized third-party object.

(33) if the semantic information on which the constraint depends is rarely changed, then * * is distributed in all the classes involved in the constraint.

The (34) class must know what it contains, but not who contains it.

(35) objects that share a literal scope (that is, contained by the same class) should not have a usage relationship with each other.

(36) inheritance should only be used to model specialized hierarchies.

(37) derived classes must know base classes, and base classes 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 in a public interface what the user of the class does not need.

(39) in theory, the hierarchical system of inheritance should be deeper, and 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.

(43) put the commonness of data, behavior, and / or interfaces at the top of the inheritance hierarchy as much as possible.

(44) if two or more classes share common data (but no public behavior), the public data should be placed in a class that each class that shares the data contains.

(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 (messages, not methods), they should inherit from a common base class only if they need to be used polymorphically.

(47) the sub-case analysis of the display of object types is generally wrong. In most of these cases, designers should use polymorphism.

(48) the case-by-case analysis of the display of attribute values is often wrong. The class should be decoupled into an inheritance hierarchy, with each attribute value transformed into a derived class.

(49) do not model the dynamic semantics of classes through inheritance relationships. Trying to model dynamic semantics with static semantic relationships results in switching types at run time.

(50) do not turn the object of a class into a derived class. Be careful with any derived class that has only one instance.

(51) if you feel the need to create a new class at run time, step back to recognize that you are creating an object. Now, summarize these objects into a class.

(52) it should be illegal to override methods in a base class with empty methods (that is, methods that do nothing) in a derived class.

(53) do not confuse optional inclusion with the need for inheritance. Model optional inclusions as classes that are flooded with inheritance.

(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, assume that you have made a mistake. If you haven't made a mistake, you need to try to prove it.

(56) whenever inheritance is used in Java object-oriented design, ask yourself two questions: (1) is a derived class a special type of something it inherits? (2) is the base class part of the derived class?

(57) if you find multiple inheritance relationships in an object-oriented design, make sure that no base class is actually a derivative of another base class.

(58) if you need to choose between inclusion relationships and association relationships in object-oriented design, select inclusion relationships.

(59) do not use global data or global functions for the bookkeeping of objects of a class. You should use class variables or class methods.

(60) Java object-oriented designers should not let physical design guidelines undermine their logical design. However, we often use physical design criteria in the process of making decisions about logical design.

(61) do not bypass the public interface to modify the state of the object.

At this point, the study of "what are the principles of Java object-oriented design" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.