Archive for the 'Design' Category

Don’t peak
Monday, April 26th, 2010

When I talked to Michael Feathers about why constraints are good, he also mentioned an example of where he thought things were going wrong.

Some people who use test-driven development, also use tools that allow the to peek into classes and read private variables. That is an efficient way to ensure that some method altered the [...]

Exception Handling Policy – Catching Exceptions
Monday, July 6th, 2009

This is the third installment in my series on sensible exception handling and will cover when and how to catch exceptions.

To quickly summarize, the series looks as follows:

Throwing Exceptions Using Assertions Catching Exceptions (this one) Logging Exceptions

The information in this post is divided [...]

Exception Handling Policy – Using Assertions
Monday, June 29th, 2009

This is the second part in a series of four on exception handling and it focuses on an area related to exceptions — assertions.

A quick summary of posts in this series:

Throwing Exceptions Using Assertions (this one) Catching Exceptions Logging Exceptions

Guidelines for assertions

An assertion [...]

Exception Handling Policy – Throwing Exceptions
Monday, June 22nd, 2009

This is the first post in a series of four on exception handling. The series will cover what I think is a good and sound strategy for handling exceptions and errors in your application. It is written with Java in mind, but is applicable to most languages which feature exceptions. This first issue will go through the art of throwing exceptions.

Common Conception Of Agile Missing The Point?
Monday, March 9th, 2009

This is a bit of a rant, but I just gotta get it out of my system.

I’m getting frustrated by people I talk to who seem to misunderstand the whole point of agile software development (IMHO).

Different ways of reducing risk

The point with agile, as far as I understand, is to reduce risk and thereby costs [...]

Constructors and Creation Methods
Saturday, September 22nd, 2007

Sometimes a constructor doesn’t communicate intention very effectively. This could be because instantiating the class in question isn’t as straight-forward as “creating a new object”, or because there are many alternative constructors. In those circumstances it might be useful to use well-named static or non-static methods to create instances of the class instead.

Testability vs coupling
Friday, July 13th, 2007

I want to describe a situation I came across where designing for testability seems to be in conflict with the always-valuable principle of loose coupling.

Slightly different and even simpler
Monday, June 11th, 2007

I’m constantly trying to become better at estimating how long a development task will take. As one step in this process I decided to create a simple web-based timer which I could use to measure time. Shouldn’t be too hard, I just needed a simple stop watch — the simplest thing that that could possibly work. That’s what I thought at least.

Do design, just not Big and Up Front
Thursday, February 8th, 2007

While evolving a design is good and nice one has to remember that even though big design up front might not be a good idea, all the hard design work still needs to be done at some point. Otherwise you’ll just end up with a big piece of garbage. Therefore, while starting with a story, do take time and think it through and answer a couple of the following questions for yourself.

Non-obvious duplication
Monday, August 28th, 2006

I just wanted to describe what for me became an “eye-opener” regarding Test-Driven Development; that when you remove duplication, you should look for not only duplication of logic, but also duplication of data.