1) There are approximately 3-5 responsibilities for each class.
In general, 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.
The essence of good OO analysis and design is to benefit each other. Similarly, each class should work together to provide all the desired features. Categories can entrust their responsibilities to specific functions Other auxiliary classes.
3) Beware of some very small classes.
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 to integrate these small classes into a bigger class. .
4) Be careful of several very large classes
The above-described side is that the model has few classes, but each class has a large number of duties (more than 5) duties. Solving the problem is to view these classes at a time. See if each class can be decomposed into two Or multiple smaller classes that can undertake appropriate number of responsibilities.
5) Be careful "pseudo"
The pseudo-class is actually a function of the general process, which 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 function, the first time the OO analysis is designed, the pseudo-class is always dangerous to him.
6) Be careful "universal class"
There is a class that seems to be able to assume any work. Look at the class named System and Controller, the policy to handle this problem is to see the universal sake of decomposition unplustered subsets. If it can, each collection of these consolidation duties It can be separated into a separate class. These smaller classes work together to achieve behavior provided by the original universal class.
7) Avoid depth inheritance
The essence of a good inheritance level is to have a good definition in the inheritance level. It is easy to add a lot of hierarchies that actually can't serve any purposes. In fact, the mistakes are used to implement one. Features, each abstract hierarchy is just a responsibility. No matter which aspect, this is meaningless, which will cause complex immature models, in the analysis, inheritance is only used in the problem domain. , Clear, obvious inheritance hierarchy.
From << UML and unified procedures to use the reading of the read-ups>
> One book P108 Page
