Rules of the analysis class

1)Each category has three to five responsibilities..

In general, classes should be kept as simple as possible. This usually limits the number of 3-5 roles that a class can support.

2)No independent class exists.

The essence of good OO analysis and design is that the mutual collaboration between classes will benefit users. similarly, each class should collaborate with a small number of classes to provide all the expected functions. classes can delegate some of their responsibilities to other auxiliary classes that focus on specific functions.

3)Be careful with some very small classes.

Sometimes it is difficult to strike a correct balance. if the model seems to have a large number of very small classes and each class has only one or two responsibilities, you should take a closer look to integrate these small classes into a larger class.

4) Beware of several very large classes

? The opposite is that the model has very few classes, but each class has a large number of (more than five) responsibilities. the policy for solving the problem is to view these classes at a time. check whether each class can be divided into two or more smaller classes that can take appropriate responsibilities.

5) Be careful with "pseudo classes"

A pseudo-class is actually a function of a general process. It is disguised as a class. grady Booch tells an anecdote that a very simple system has thousands of classes. after careful review, each class has an operation named Dolt () (dumb). When analysts are used to top-down functional decomposition techniques, the first time they were dealing with OO analysis design, the pseudo class is always dangerous to him.

6) Be careful about "omnipotent"

There seems to be a class capable of undertaking any work. let's look at the classes named "System" and "Controller". The strategy to solve this problem is to look at the responsibilities of the omnipotent classes to break down the uncohesive subset. if possible, each set of these cohesion responsibilities can be separated into independent classes. these smaller classes collaborate to implement the behavior provided by the original omnipotent class.

7) Avoid the deep inheritance tree

The essence of a well-designed hierarchy is that each level in the hierarchy should have a well-defined purpose. it is easy to add many levels that actually do not serve any purpose. in fact, a common mistake is to use inheritance to implement a Function Decomposition. Each abstraction layer has a responsibility. in any aspect, this is meaningless and will lead to complicated and difficult-to-understand models. In analysis, inheritance is only used to exist in the problematic domain and is clear, this is an obvious inheritance level scenario.

From <UML and Unified Process use read-oriented analysis and design> > P108 pages