I'm an engineering manager at Braintree. I write about politics, psychology, and software.
Recent blog posts:
11 January 2014
Here are some rules, ideas and techniques you’re supposed to follow when writing object-oriented software:
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:
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