What Makes A Good Object-Oriented Design?

Related Sites

I'm reviewing an object-oriented design for what I consider a complex application. What are some characteristics of good designs? When looking at class or object interaction diagrams, what are signs of inefficient, inflexible designs?

See the paper on the principles of object oriented design at our web site. It will help you to spot poor uses of inheritance and poor dependency structures, among other kinds of design errors.

[The thumbnails for the principles in this paper are:

1. The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.
2. The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference. [See previous tip about LSP]
3. The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details.
4. The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface/
5. The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.
6. The Common Closure Principle: Classes that change together, belong together.
7. The Common Reuse Principle: CClasses that aren't reused together should not be grouped together.
8. The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.
9. The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
10. The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.

[...]

Also look for good things.

Look for simplicity. If you don't have it, make sure that there are reasons that more complexity was exposed. Accept good answers, but only good answers.

[...]

I have tried from time to time to come up with a theory of "needless contrivance" where you can recognize the the difficulty of using an interface that the interface is inappropriate, and in what way. I guess what I'm saying is that if you see a design with a lot of "patching up around the edges" then the problem isn't the edges: its the core.

[...]

A less formal way of saying it is "If it seems like you're swimming against the stream, consider that perhaps you are." Or "don't force it".

Arthur Riel published an interesting book Object-Oriented Design Heuristics. The book contains about 50 heuristics to follow when using OO in the design phase - e.g. 'Do not create god classes/objects in your design', 'Do not change the state of an object without going through its public interface', 'All abstract classes must be base classes', 'All base classes should be abstract'.
[See More Info for the complete list of heuristics -YS]

Arthur Riel's 60 OOD Heuristics

OOD Principles by Robert C. Martin:

• The Open Closed Principle
• The Liskov Substitution Principle
• The Dependency Inversion Principle
• Granularity (Discusses the Reuse/Release Equivalency Principle, The Common Closure Principle, The Common Reuse Principle, and the Acyclic Dependencies Principle)
• Stability (Discusses the Stable Dependencies Principle and the Stable Abstractions Principle)
• The Interface Segregation Principle