Thoughts on Technology, Methodology and Programming.

Everything you know is wrong

Posted by Marcus Wyatt on 5 May 2006

While I was searching for more information on Behaviour Driven Development, I ended up at Dave Astels blog. Now, many of you in the same headspace as me would probably point out that Dave is one of the pioneering thinkers in this area. Rightly so, but what I found was an interesting post regarding Agile. The first line of the post reads as follows:

I’m in Allen Holub’s talk this morning… “Everything you know is wrong: Inheritance and getters/setters are evil”.

When I read this statement, I found myself almost instantly offended. How can you make a statement like this? Do you want to tell me most of the other leading technical thinkers are WRONG? I mean, come on… We have been practicing Object-Orientation since the middle eighties and all our languages today is build to enable us to develop Object-Oriented software. I continued to read the post and then I found this paragraph:

Allen started off with the classic “tell, don’t ask” talk. He makes a very good point that hadn’t occurred to me before. To really get benefit out of an Agile process (specifically XP) you NEED to be doing OO properly. If you aren’t, you will fail.

I have made this exact point a while back when we where discussing Test-Driven Development. As any TDD zealot knows, you cannot effectively do test-driven development without having loosely coupled objects. Why? The reason is that when you are test-driving a piece of behaviour, you want to be able to test the behaviour in isolation. And to be able to do that, you need to Mock out external dependencies, and to mock the dependencies, you need to expose the dependencies as an interfaces. This brings me back, to another point. State based vs. Interaction based testing. When I started to get into TDD a few years back, I found doing Test-Driven Development was really-really hard. Why? Because I was only doing, state based testing. Since I learned to think in terms of the behaviour that I am trying to implement, I found writing the specifications (tests) are easier and my objects became more cohesive. On to the next interesting bit:

Next Allen moved to why encapsulation is so important and why getters & setters are such a problem. Don’t bother getting flustered about that idea.. he’s 100% on the money. If you disagree you need to learn what OO is. One nice soundbite: “Doing it this way (interface based, using design patterns) lets me have to think less. Thinking is hard… I’d rather just program.”

I agree with Dave on this one. Take for instance the Command-query Separation principle, as soon as you know and understand the principle, you consciously try to adhere to the rules of the principle. By doing this, your code starts to have less public properties and you get methods that are performing only one responsibility. I’m not trying to say that the Command-query Separation principle is the solution to the problem, but that knowledge of Object-Oriented principles will lead you to writing better, more bullet prove code. The Command-query Separation principle is only one in a multitude of Object-Oriented principles.

The bottom line(s):

  1. There is no such thing as perfect
  2. Design is a series of trade-offs
  3. assess risk, then make reasonable decisions
  4. there’s often is a better way of doing things than the first way you think of

tags: , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: