Programming rules-three types of Design Rules (2) basic requirements of Class Design

 

 

3.3 basic requirements for Class Design

The above describes the basic rules of system design and class design, which are theoretically strong and difficult to understand for a while. The following describes the basic requirements of class design, which is easier to practice, you need to do well. The above rules can be gradually understood in the practice process. software design is a practical science, and it is always hard to get into the door on paper. Practice is the best teacher, however, you still need to try to understand the above principles and methods, which will reduce your detours. To put it simply, the basic requirements for design are:

1) Short categories and single responsibilities (single SRP responsibility principle)

2) classes require high cohesion and low coupling

3) The relationship between classes should have a reasonable structured system.

These items seem very simple, but the concept abstraction is still difficult to understand and grasp. The following describes the basic requirements of the popular class design before the description:

A) Class describes the real objects of objective business areas and solutions (technical areas;

B) the class should have an overall architecture system;

C) the class must have a concise name;

D) class should hide internal information as much as possible;

(A) tell us not to follow our imagination to design a category, but not to create a monster (the legendary wolf in software engineering is made in this way). object-oriented technology is not just OO technology, more importantly, you need to target objective business objects during design. Each class must correspond to objective things in the actual business and technical fields. If no corresponding things can be found, you should be aware that you may be creating monsters. You may say that I need this class, but I can't find the corresponding things. In this case, you need to change your mind. In fact, you need to think of the business field as a fully manual job system, at this time, all things are required in this field. In fact, it is to bring the business activities back to the original manual state (no computing system, how the pure manual system works ), for example, in a purely manual banking system, there will be clerks at the front desk of the Bank, and there will be accountants and bookkeepers at the back end. They will use various creden, account books, accounts and registers, these creden and books are the objective things for us to extract object objects. Various "members" are the objective things for us to extract operations and service objects. If such a manual bank is ready to implement a deposit/exchange, A centralized background Department is required. The front-end clerk needs to send the customer's business information to the background by phone or fax, the background processes the data based on the centralized ledger (in fact, the early banks did handle the business), which leads to communication, packets, and other things, it is closer to the current business system of the C/S (or B/S) model, and the affairs in the solution field will come out. At this time, you may find the true meaning of the object orientation and find the corresponding considerable things for your class. If you haven't found them yet, you have to review them, it is very likely that you are creating monsters.

Manual Simulation is often a derogatory term for software system design, but there are two aspects: first, the objective business field is formed by business development over decades, accumulating human wisdom, it should be an important reference for our system design. Second, we cannot blindly and mechanically imitate the design, but must analyze, abstract, and combine and extract the pseudoevidence. You will find that-The object is in reality, and truth exists, waiting for your intelligent brain to discover.

B) when designing a class, in addition to designing a specific class, you must also design a class-related architecture:

Package Structure DesignA package is a class container. A system usually has several classes. It is very important to have a clear organizational structure to organize these classes reasonably, the design of the package structure must be emphasized.

Class inheritance structure design,The class actually exists in an environment. It is far from enough to focus only on the design of the class itself. We must pay attention to the Inheritance and mutual relationship of the class (which will be introduced below). Many of our designs, the class is designed as an independent entity, and the world is unique. According to the principle in a), the class must correspond to objective things, in the objective world, there is no such thing as the only child and the only child. The monkeys popped out of the stone are only mythical stories. Therefore, our class design must not implement any interface or inherit any class design, unless you are an interface or base class, and the base class and interface must be designed by the general group.

In fact, classes are mainly divided into two categories: data classes (such as object objects and transmission objects, equivalent to Java Beans) and behavior classes (such as front-end AEM and backend services ), under our development system, their top-level interfaces and base classes have been determined separately. The classes we designed must follow this inheritance system. Even so, the design of the specific class inheritance system under this system is more important, involving your understanding of a business field. For example, when we design the transmission objects of the core banking system, how can we break down the requirements of thousands of Functions of a bank on transmission objects into several categories and divide them into several small categories, in this way, a set of reasonably structured and small-scale classes can meet the detailed requirements of all functions of the bank for data transmission. for businesses of the same type, the basic classes can be expanded to expand all related sub-classes, the modification of the underlying subclass does not affect other classes to achieve a balance between stability and expansion.

Class dependency level,Despite the constant emphasis on decoupling in the system design process! Decoupling, but if a class is not associated with any other class, the class will be useless. That is to say, the class will inevitably interact with other classes and be coupled, the key to the problem is that, if coupling is minimized, only coupling is required. According to the minimum knowledge principle and dependency inversion principle, a class should be as dependent as possible, when coupling with classes in the non-package, the interface, base class, or abstract class should be dependent, and the non-specific class of the package should not be dependent. A class dependency is provided:

 

 

Two packages use interface dependencies to obtain the actual objects in Package B through the factory method in the public package. The dependencies between classes in the same package must have a reasonable level, A reasonable dependency level can reduce the coupling of classes. To do so, class design should follow the principle of single responsibility and minimum knowledge, and only deal with the circle of friends rather than talking to strangers. In this way, the impact between classes can be minimized to facilitate system expansion and stability.

C) A class should have a concise name, and the class name should be able to describe its responsibilities well, accurately, and concisely. This is also a good way to insist on whether a class has too many responsibilities, if you cannot give a simple and accurate name to a class, it may mean: ① this class has too many responsibilities; ② this class has unclear responsibilities; ③ you have not yet determined a good name for it; if it is the last point, you can give it a simple name and express its responsibilities in a concise manner. Remember that when you have a more appropriate name, you must actively reconstruct it, A proper and accurate name is very important for a class, such as its Class and Class.

The class name should be a name or noun phrase, and should not be a verb.

D) classes should hide internal information as much as possible; we stipulate that class attributes must be privatized and do not provide setup methods (except for Data Objects and transmission objects) as far as possible ), you do not need to disclose the methods of the class. Internal data models (such as list, set, and map) are not allowed to leak out.

The following is a description of the previous 1)-3) Principles:

1) Short categories and single responsibilities (single SRP responsibility principle)

Short is not a goal, but a single and complete responsibility is the key. In fact, the evolutionary process of all things in the world is a process of increasingly simple and clear division of labor. Taking biological evolution as an example, the most primitive life is a pile of protein clusters, with no division of labor and loose organization, so it is also very fragile. Later, it gradually evolved. Some were responsible for walking, some were responsible for eating, and some were responsible for digestion, some are responsible for transportation, and gradually form the organization and organ, and gradually move to the advanced form of life;The software system is also an invisible bodyA system without strict division of labor and loose organization is a primitive software system. A software system with a good architecture and clear division of labor is a high-level software system. Class, as the basic unit of the software system, must have a single and complete function and follow the SRP principle.

2) classes require high cohesion and low coupling

If a class meets the single responsibility principle, it is usually highly cohesive, because it only focuses on a single responsibility, and focus is naturally cohesive. First, a class must have fewer attributes, all attributes are mandatory and excluded from those unrelated to their functions. To evaluate the cohesion of a class, we can examine the closeness between its methods and its attributes, if each method uses multiple attributes, it indicates that the cohesion is relatively high, and vice versa, the cohesion is relatively low, high Cohesion indicates that the attributes and methods of a class are mutually dependent and combined into a logical whole, focusing on one responsibility.

Low coupling, referClass dependency levelTo handle the class dependency.

3) The relationship between classes should have a reasonable structured system.

See the description above about B.