2. Capture all requirements as parts of the analysis models. [p300]
3. Use a notation that is easy to understand.
4. Present the models in a clearly visible way to all project members.
5. Refine and formalize the analysis models. [p301]
6. Conduct a formal review of the outputs from the analysis phase.
9. Generalize in such a way that future alterations of the component are supported (i.e. introduce high level abstractions).
10. Pinpoint variants among existing and future systems within the domain.
12. Distribute system intelligence evenly.
14. Factor common responsibilities as high as possible up the inheritance hierarchy.
15. State responsibilities as generally as possible. [p309]
16. Minimize the number of collaborations a class has with other classes or subsystems
17. Minimize the number of subsystems.
18. Make subsystems out of classes which are likely to be affected by the same minor change in requirements.
20. Introduce subsystems late in the architectural design phase.
22. Use multiple inheritance rarely.
23. If an operation X of a class is implemented by performing a similar operation on another class, then that operation should also be named X (recursion introduction). [p312]
24. One task - one method. Each method should perform only one task to keep it simple. For example, decompose a method called "put_and_print" into two methods.
25. Subclasses should be specializations.
26. The top of a class hierarchy should be abstract. [p313]
27. Keep a small total protocol for a class.
28. Keep classes small - avoid introducing too many methods.
30. Class hierarchies should be fairly deep and narrow. [p314]
31. Factor implementation differences into new abstractions.
32. Favor uniformity over specificity in naming conventions.
33. Keep method signatures consistent. [p315]
35. All methods intended to be overloaded or redefined in subclasses must be declared as virtual.
36. Do not cast down the inheritance hier. unnecessarily.
36. Try to avoid inheritance with cancellation.
38. Do not use private inheritance. [p331]
39. Keep classes small - avoid large total protocols.
40. Keep classes small - avoid the introduction of too many methods.
41. Keep the number of method arguments small.
42. Keep methods small.
43. Declare member methods "const" when possible. [p332]
44. Declare parameters "const" when possible.
45. Always make destructors virtual in the base class.
46. Eliminate "switch" statements on object types.
47. Specify attributes as "private". [p333]
48. Use "protected" methods instead of protected attributes in the base class, for interfacing the subclasses.
49. Avoid using "friends" if possible.
50. Avoid implicit "inline", that is, implementation and code in header files.
52. Implement implicitly generated class methods: constructor, destructor, copy constructor, and assignment operator.
53. When copying or assignment makes no sense, hide the copy constructor and the assignment operator in the "private" part of the class specification.