General Guidelines OO Guidelines Reuse-specific Guidelines
Anal 1. Gather information from as many sources as possible. [p299]

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.

7. Use inheritance to express specialization on types. 8. Analyze existing applications within the domain and identify commonalities. [p302]

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.

11. Make optional parts of the system as subsystems. [p308]

12. Distribute system intelligence evenly.

13. Make subsystems of strongly coupled classes that implement one unit of functionality.

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.

19. Create as many abstract classes as possible. [p310]

20. Introduce subsystems late in the architectural design phase.

  21. If general properties of some classes can be identified and viewed as making up a generalization or abstraction of the classes, create a superclass for this generalization, gathering the identified general properties using inheritance. [p311]

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.

29. Use abstract classes as far as possible in inheritance hierarchies.

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]

Imple   34. Do not use multiple inheritance just to minimize code. [p330]

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.

51. Inhibit classes intended to be abstract from being instantiated. [p334]

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.

Test 54. If a component is small and will be reused many times, or if is vital that it is totally reliable, it is better to perform a proof of correctness than to use conventional testing. [p336] 55. Couple specific test cases and test beds to the component they are intended for. [p339]
56. Couple specific test cases and test beds to the component, components, or users they are intended to represent.
57. Couple specific test cases and test beds, or parts of them, to the parts of the component that represent specific functionality.
58. Record the test beds used for a component.