OO Software Design Principles

Question

I am a huge fan of software design principles such as SOLID and DRY. What other principles exist for OO software design?

Note. I’m not looking for answers like "comment your code" but instead looking for OO design principles like the ones discussed by Uncle Bob.

Answer 1

A fairly comprehensive list from Wikipedia:

http://en.wikipedia.org/wiki/List_of_software_development_philosophies

• Agile software development
• Agile Unified Process (AUP)
• Behavior Driven Development (BDD)
• Big Design Up Front (BDUF)
• Brooks's law
• Cathedral and the Bazaar
• Code and fix
• Constructionist design methodology (CDM)
• Cowboy coding
• Crystal Clear
• Design-driven development (D3)
• Don't repeat yourself (DRY) or Once and Only Once (OAOO), Single Point of Truth (SPoT)
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature Driven Development
• Hollywood Principle
• Iterative and incremental development
• Joint application design, aka JAD or "Joint Application Development"
• Kaizen
• Kanban
• KISS principle (Keep It Simple, Stupid)
• Lean software development
• Microsoft Solutions Framework (MSF)
• Model-driven architecture (MDA)
• Open source
• Open Unified Process
• Quick-and-dirty
• Rational Unified Process (RUP)
• Scrum
• Smart (agile development)
• Separation of concerns (SoC)
• Service-oriented modeling
• Software Craftsmanship
• Software System Safety
• Spiral model
• Test-driven development (TDD)
• Unified Process (UP)
• V-Model
• Waterfall model
• Wheel and spoke model
• Worse is better (New Jersey style, as contrasted with the MIT approach)
• Xtreme
• You Ain't Gonna Need It (YAGNI)
• Zero One Infinity

Answer 2

High Cohesion - How focused are the responsibilities of the modules you are designing.

Low Coupling - The degree to which modules rely on other modules.

Answer 3

KISS

Answer 4

Chose composition over inheritance, is one.

Many people, especially those new to OO will start extending classes when all they really need to is to use composition. Really if you should ask your self, is the new class B a Class A? If not then you shouldn't extend.

For example, let's say I have a Person Class, a Car Class, and I would like to make a new class called a DrivenCar class. A naive implementation would be to say (let's pretend we got multiple inheritance)

class DrivenCar extends Person, Car  { ... }

Is the DrivenCar a type of Person? No so it shouldn't be extending Person. Is the DrivenCar a Car? yes so it makes sense to extend

Using composition the implmentation would look like

class DrivenCar extends Car {
    private Person driver;
}

Answer 5

The GRASP patterns. Yes, they seem rather trivial. More like distillation down to core qualities that other, more involved patterns demonstrate.

Answer 6

YAGNI

Answer 7

Interface. Most design patterns are based on separation of interface & implementation.

Answer 8

When your API are expected to grow, use Abstract class instead of Interface. Adding a new method in Interface requires to change ALL the classes which implement it.