This course is about good software design, from an object-oriented perspective. But what does that mean? Here are a set of principles that characterize “good object-oriented design.” Keep this handy; we’ll be returning to these principles frequently during the course.

Don’t Repeat Yourself (DRY)

Every piece of knowledge in a system should have a single, unambiguous, authoritative representation.

— Andy Hunt and Dave Thomas, The Pragmatic Programmer

Single Responsibility

Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. (Strongly related to high cohesion.)

— Robert C. Martin, Principles of Object-Oriented Design


Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

— Bertrand Meyer, Object-oriented Software Construction

Liskov Substitutability

If S is a subtype of T, then objects of type S may be substituted for objects of type T without altering any of the desirable properties of a program.

— Barbara Liskov, Data abstraction and hierarchy

Interface Segregation

No client should be forced to depend on methods it does not use. (Strongly related to low coupling.)

— Robert C. Martin, Agile Software Development