1) There are approximately 3-5 responsibilities for each class. ?? Generally, the class should be as simple as possible. This usually restricts the number of 3-5 responsibilities that can be supported. 2) There is no independent class. Good The essence of OO analysis and design is to benefit each other. Similarly, each class should work together to provide all the desired features. Classes can entrust their responsibilities to other functions Assisted class. 3) Be careful to have a very small class. Sometimes it is difficult to get the right balance. If the model looks a lot of very small classes, only one or two duties of each class, then you should look carefully Integrate these small classes into a larger class. 4) Be careful to have a few very large classes? The above-mentioned reverse is that the model has few classes, but each class has a large amount (more than 5) responsibilities. The problem-solving strategy is an observation of these classes. See if each class can be decomposed into two or more smaller classes that can bear the appropriate number of responsibilities. 5) Be careful to "pseudo" pseudo-class is actually general process Function, it is camouflaged to class .Grady Booch told a anecdote, a very simple system, thousands of classes. Carefully review, each class has a Dolt () (fool) operation, When analysts are accustomed to the technical decomposition of the top-down functional decomposition, when the OO analysis is dealt, the pseudo-class is always dangerous to him. 6) Be careful that the "universal class" seems to be able to bear any work Class. Look at the class named System and Controller, the policy to handle this problem is to look at the universal subsidy to decompose unplugged subset. If it can, each collection of these co-gather responsibilities can be separated into a separate class. These smaller classes are collaborated to achieve behavior provided by the original universal class. 7) Avoiding the inheritance of the inheritance of the inheritance tree in the inheritance, which should have a good definition of each time the sub-level in the inheritance level. Easy to add Many actually can't serve the level of any purposes. In fact, mistakes are inheritance to implement a functional decomposition, of which each abstract hierarch is just a responsibility. No matter which aspect, this is meaningless In the analysis, inheritance, inheritance, inheritance is only used in the presence of the presence of the problem domain, clear and obvious inheritance, which is taken from << UML and unified procedures. Analysis and Design>
> One book P108 Page
