Thursday, August 03, 2006

The Measure of a Design

Before we get into looking at the various design strategies for solving the problem of allowing the user to capture intermediate data that is not completely valid, I want to spend some time looking at measuring the value of the various alternative design strategies.  This isn’t meant to be an exhaustive analysis that can be carved in stone for the ages. This is a lot closer to a “back of the envelope” type of analysis that provides some suggested guidance in our choices.

I think that the most important characteristic is to preserve the sense of common values.  Using our example, what we want is a single address with evolving values.  From the perspective of the end user or the client software, I think it’s really important that it appear that there is a single entity that evolves as new data is added and existing data is modified.  That’s not to say that we couldn’t have different classes that play the same role, but I don’t think it is appropriate to select a design that makes the substitution of one class instance with another class instance visible to the client.

Along that same line I think that the complexity of the solution should be minimal.  I have a tendency to create very complex designs and I have to work very hard to keep saying to keep it simple.  Again we might have a really complex structure under the covers but none of that should be visible to the end user or the client software.  Another closely related concept is the ease of use.  Just because we want to be reasonably accommodating of flaky data early on should not mean that the client software should have to work very hard to use the design.

Finally, the design that we come up with should be fairly easy to implement.  Although we’ve been talking about a single type of data, namely the contents of a single address, the reality is that we might have to create many different classes based on the same approach.  We would like to go do this in a fairly easy way.  We would also like for the design to be intellectually accessible to those who follow along behind us who will maintain the software for the decades to come during which this application will live and prosper.  (If you think that is a fantasy, think back to all the software that had to be remediated during the Y2K crisis.  Some of that software was 30 years old and is still going strong.)

Next we’ll look at our toolbox of possible design approaches.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home