Comfort with tradeoffs and ambiguity

11 January 2014

Here are some rules, ideas and techniques you’re supposed to follow when writing object-oriented software:

• Encapsulation - objects should hide their internal state from other objects.
• Polymorphism - similar objects should present similar interfaces to other objects.
• Inheritance - classes should form a type hierarchy in order to promote code re-use.
• Composition - objects should contain other objects in order to promote code re-use.
• Composition over inheritance - composition is often preferable to inheritance.
• Law of Demeter - objects should not invoke methods on far away objects.
• Single Responsibility Principle - classes should have only a single responsibility.
• Open/Closed Principle - classes should be open for extension but closed for modification, whatever that means.
• Liskov Substitution Principle - you should be able to substitute a parent type with any of its subtypes without breaking the program.
• Interface separation Principle - clients should only depend on interfaces they use.
• Dependency Injection - objects should be initialized with their dependencies rather than create dependencies themselves.
• Tell, don’t ask - objects should tell other objects what to do rather than make decisions based on other objects’ internal state.
• Don’t repeat yourself - each piece of logic should have a single authoritative representation in the program.
• Keep it simple, stupid - keep the program as simple as possible.

As you can see, there are a lot of rules. They’re a pain. They conflict with each other, they push over-engineering as the solution to every problem, and the advice they offer is shallow and tactical at best. Yet despite all of this, developers often treat them as laws to be obeyed rather than mere suggestions.

I think people like rules like this because they offer absolute guidance; they seem to eliminate the need for developers to think carefully about the design of their programs. Take the Liskov substitution principle for example – you can find a formal definition on Wikipedia:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Given this definition, it’d be easy to automatically check a program for compliance with Liskov’s principle. Isn’t that awesome? Why bother to think about the design of our programs, when we can have the design checked by other programs! We won’t have to make any decisions at all!

That’s bullshit. In reality, program design is about weighing tradeoffs, not following absolute rules. There are only two questions you really have to think about:

• Is this design easy to understand?
• Is this design easy to change?

These concerns are vague, strategic, and high-level. They don’t offer absolute guidance, only ambiguity. But guess what? If you’re a software developer, making sense of tradeoffs and ambiguity in design is your job. So stop quoting Wikipedia and make some decisions for yourself.

comments powered by Disqus