OO Design inspection checklist
This inspection checklist was originally created to support my OO courses,
but turned out to be very effective for live use on projects. There is a companion
checklist that covers use cases, Enjoy.
- Does the development team understand the Use Cases that this design supports?
- Can every member of the development team trace a Use Case Scenario through
the design s using a small number of high level components?
- Are the bulk of the Class names understandable and recognizable by the
- Do the Class names reflect the overall responsibility of the Class with
respect to the Use Cases and the design?
- Does the name of every Message reflect the intended outcome of the Method?
(There should be no actions that could not be inferred from the Message name.)
- Does the purpose of the Method match the overall responsibility of the
Class that it is in? (Should the method be moved to another class, or does
it belong in a different place in the inheritance hierarchy?)
- Have the Class diagrams been drawn to emphasize the Classes used by a set
of Use Cases?
- Have Packages been used to group related Classes, and are dependencies
between packages noted?
- Are all parameters specified for every message on the interaction diagrams,
and is there a way for the sending object to know the parameters it is passing?
- Is flow of control obvious and correct within the interaction diagrams?
(Hyperspace leaps are not allowed.)
- Do Object names on Interaction Diagrams conform to coding guidelines?
- Do Parameter names in Messages conform to coding guidelines?
- For cases when there are more than one message to the same object, could
this set of messages be replaced with a single message?
- Is the design supposed to conform to the Law Of Demeter? (An object can
only send Messages to Itself, It’s Attributes and passed parameters)
- Does each Method have a set of Unit Tests defined?
- Are all of the Failure Conditions from each Use Case tested for?
- Does the implementation of every Method on a Class use at least one attribute
or method in that class? (If a Method does not refer to it’s object,
then it is just a utility function attached to the class, so it should be
- Overall, is the an even balance of responsibilities between the classes?
(No Workaholics allowed)
- Do the bulk of the Classes have an even balance of methods and attributes?
(Trivial accessor methods do not count.)
- For Messages with similar groups of parameters, can a simple data holder
class be defined to simplify the message?
- Whenever Inheritance is used, is the phrase "Sub-class is a kind of
Super-class" correct for the life of the object?
- Does Interface Inheritance make more sense than Implementation Inheritance?
- Even where inheritance is not applicable, are consistent names used for
- Are all Attributes private?
- Is the visibility of Methods appropriate? (If a Method is not invoked from
outside the class it should be private.)
- Are there any unused Attributes or Methods on a Class? (Unused implies
untested which implies code defects.)
- Is Run Time Type Information used to switch behavior? (This is only needed
for interaction with non-object systems.)
- Are the Classes partitioned so that as many Classes as possible are platform
- Is the persistence and transaction policy defined?
- For containers, is ownership of the contained objects defined? (If the
container is deleted, are the contents also deleted?)
- Has the design been tested by the development of an Executable Architecture?
(C) 2000 Software Craftsmanship Inc., all rights reserved.