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
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
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
No client should be forced to depend on methods it does not use. (Strongly related to low coupling.)
— Robert C. Martin, Agile Software Development