1. First, I need to design to clarify what the entire system or the entire module or component does, just For example, if you are going to start a company now, what kind of business should the company do
? 2. Then subcontract according to functions, and the responsibilities of the package should be as simple as possible. Department, Human Resources Department, Administration Department, Internal Control Department, R&D Department I, R&D Department II, etc. The responsibilities of the departments are single. Due to the different goals of R&D, the R&D department should also be subdivided;
3. Define the responsibilities of a class, the responsibilities of a class It is the value of the existence of this class. If you cannot clearly define responsibilities for this class, it probably means that the class has no value in existence. The responsibilities of the class are as single as possible, so that the possibility of future changes is also single. The smaller the class variability, the smaller the opportunity to modify the class, thereby improving maintainability and reducing bugs. At this time, the class is equivalent to the position in the department, and the object is equivalent to the person.
4. Define the name of the class, find a good name as the class name, and basically know the responsibilities of the class through the name. The standard of a good name is to use the name to express the intention. First of all, it must be meaningful. If you can't find a meaningful name to define it, it only means that the responsibilities of the class are not well defined. Generally, we use English nouns as class names, just like converter is better than convert;
5. Interface-oriented design, like Spring's design, try to design by implementing interfaces as much as possible, and extract the public method set into interfaces. The interface should have complete methods and no redundant methods (of course, there are exceptions, sometimes in order to improve the class Convenience will have some redundant methods). The advantage of the interface is that the interface and the implementation are separated and abstracted. In the case that a method needs to have many implementations, the interface can reflect the advantages. The disadvantage is that the design becomes more difficult. If it changes, the implementation will be messed up. In my understanding, the interface is quite similar to the role in the organizational structure of the enterprise. For example, the position in the company may only be a R&D engineer, but there is no subdivision designer, dba, and demand analyst. The latter is the so-called role. Maybe this concept is a bit far-fetched. I only say this for understanding.
6. The last two steps are not actually in the design stage. They are things that need to be done in actual development, but they must be thought out in advance;
7. The specification of the class can be written with javadoc. This department is in a hurry. case is often ignored.
8. Write unit tests to use your own interface. Here is a good way to promote TDD development. When I was doing development myself, I liked to write unit tests first. By constantly excluding Failed from unit tests, the interface and implementation classes were slowly knocked out.
In addition, there are a few details that need to be paid attention to, which are basically known to all java learners:
1. When designing classes, encapsulation and information hiding are all object-oriented design specifications, just pay attention;
2. Interfaces The naming and class naming are consistent, for example, the interface starts with I, the control class is xxxcontroller, the service class is xxxservice, etc.;
3. Do not use too many basic types in a class. If there are too many basic types, according to the responsibilities function to encapsulate into a new business object class;
4. We are going to adopt the Rest-ful architecture for this project, so the design of the API is also critical. A good API should be extensible and easy to reuse. When it's finished, it should be taken out separately.
Since it comes to class design, it also mentions the class relationship in the basic UML.
There are many kinds of inter-class relationships, which can be divided into two types in large categories: vertical relationships and horizontal relationships.
The vertical relationship is the inheritance relationship. Its concept is very clear, and it has become one of the three important characteristics of OO. There is not much discussion here.
The horizontal relationship is relatively subtle, and can be roughly divided into four types according to the UML recommendation:
1. Dependency: dashed line + arrow
2. Association: solid line + arrow
3. Aggregation: hollow diamond + solid line + Arrow
4. Composition: Solid diamond + solid line + arrow
Their strong and weak relationships are indisputable: Dependency < Association < Aggregation < Combination. However, the differences between the four of them are not so easy to grasp and need to be well understood.
Just say it here.
Dependency is the relationship of use a, that is, the function of one class uses another class without holding it.
An association is a long-term holding of a reference to an object, and the relationship can be mutual. When it comes to ending the relationship, it can be ended as long as both parties agree. For example, friends, you have a set of friends, and you are also one of his friends. When you have a conflict, you can disconnect the reference relationship.
Aggregates are strong versions of associations. The aggregated objects can also be associated with other objects, so the aggregated objects can be shared. Although shared, aggregation represents a more intimate relationship. Home, for example, can be shared with your wife, but you won't share it with your friends at will, and the relationship is not mutual.
Composition is the strongest version of the relationship, and it directly requires the containing object's ownership of the contained object and the relationship between the containing object and the contained object's lifetime. such as the heart.