The Artima Developer Community
Sponsored Link

Weblogs Forum
Implementation Driven Design

2 replies on 1 page. Most recent reply: Nov 20, 2004 11:09 AM by Christopher Diggins

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 2 replies on 1 page
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Implementation Driven Design (View in Weblogs)
Posted: Nov 19, 2004 11:45 AM
Reply to this message Reply
Summary
There are many different "[insert-buzzword-here] Driven Design" methodologies, i.e. Policy Driven Design, UI Driven Design, Data Driven Design. I would like to propose a new one: "Implementation Driven Design".
Advertisement
Previously I referred to an approach that I used for arriving upon a Bank Account design ( See my entries titled, OOP Case Study: The Bank Account Class Part 1, Part 2 and Part 3 ) as a bottom-up approach. I think by using the more descriptive term "Implementation Driven Design" it helps describe more the approach I am advocating.

The basis of Implementation Driven Design ( or IDD ) is built upon the core assumption that software requirements are rarely complete nor static. As much as I would love to force clients to completely specify their requirements before I start implementing their software, this never occurs. Being in the business of writing software, it is my job then to make them happy. The common response I hear from programmers is to gripe about how the customer is a moron, or something to that effect. This doesn't hold water for me. Sometimes I am my own client, and no matter how hard I try, even I can never know in advance exactly how my own software is going to turn out in the end. I envy those who work with a static software specifciation, programming must be so much easier.

The purpose of IDD is to make every part of the software as reusable as possible. This is done by avoiding overspecifying the role of any component of the software. If at any point a function or class is too specific, I refactor it into more reusable components. This approach is counter-intutitive, because at first it appears to take more time and effort to write reusable components. As a project continues and the requirements inevitably evolve, this approach pays off enormously. Since I started using IDD, I actually have a very large reusable code base, which has paid for the extra original effort required several times over.

This approach has a wonderful side-benefit of implicit testing. If a portion of code is reused significantly, then every time it is run it is tested again and again. Part of the goal of IDD is to write classes and functions that are so simple, so as to be easily verified upon simple inspection and rarely need modification. If at any point a change is required, I look for new opportunities for refactoring and often find some.

The reason I am calling this approach Implementation Driven Design is because of the goal of reusable components, I now think about software more from the ground up in terms of the components needed to eventually represent the abstractions present in the software. I don't trust the details at the highest level of abstraction to remain consistent, but I do trust that the tools needed won't vary.

This brings me back again to the Bank Account class. In the absence of specific details, I know that any implementation of a Bank Account is going to do the following two things:

  • view balance
  • modify balance
The next specification is that likely it will be multithreaded, therefore I will need
  • lock
  • unlock
Another specification that it likely going to want to log transactions
  • view transaction history
  • apply transaction
Finally yet another specification that makes a lot of sense:
  • getting the balance at a specific date
Many programmers / architects try simply to anticipate all of these specializations and start by writing a single perfect class which incorporates all of them. This is often an iterative process that involves rewriting over and over the class as specifications change or get added. The IDD approach is to start from the ground up writing four separate classes, each one using or inheriting from the previous. What is perhaps unclear here, is how I arrange these specifications in some kind of order. This comes with experience, and thinking about what a logical sequence of classes are. Clearly in any kind of hierarchy we want to start with the most non-specific class as the root. This is the most reusable case, and the simplest to implement or describe.

I should point out that a pitfall that must be wary of with IDD is to avoid overspecifying the general purpose classes. It is tempting to include lots of useful functionality in a class that we want to see reused. We have to keep in mind that the kind of reuse we want to encourage is that of the definition of new types or the writing of new functions. We can't get caught up early on trying to anticipate every possible change, we need instead to make it easy for other to adapt our solution to their needs.

The IDD approach is in large part the philosophy that we see embodied in the C++ Standard Template Library (STL). The STL was designed not to anticipate every possible use, but rather to be general enough as to be useful as a basis for our new types and algorithms which are specific to the problem domain.

I think the only big obstacles to IDD is what I perceive as a generalized fear to specialize existing types, or to design new types for specialization. I want to encourage programmers to break out of their shell, and start generalizing more.


Steve Holden

Posts: 42
Nickname: holdenweb
Registered: Apr, 2003

Re: Implementation Driven Design Posted: Nov 19, 2004 8:35 PM
Reply to this message Reply
There is a reason that the word "specification" begins with "specific". You say:

"""
In the absence of specific details, I know that any implementation of a Bank Account is going to do the following two things:

* view balance
* modify balance

The next specification is that likely it will be multithreaded, therefore I will need

* lock
* unlock

Another specification that it likely going to want to log transactions

* view transaction history
* apply transaction

Finally yet another specification that makes a lot of sense:

* getting the balance at a specific date
"""

With respect, in the absence of specific details you don't have a specification, you have a set of ideas for implementing a framework to provide solutions to a class of problems. Hopefully the actual customer's actual problem will be a member of that class, but do you seriously suggest they should pay you for solving your next customer's problems?

In the XP world no customer would say anything "likely wants to be ..." anything. As far as they are concerned they want an implementation for a particular story, and the only thing of importance thereafter is the estimated (and, later, actual) cost. This allows them to prioritize the story, and hence guide the developers.

You follow this by using the word "specialization": was this a typo?

It seems to me that you are attempting to solve problems by generating YAGNIs, unless there's something I am seriously misunderstanding here. "A generalized fear to specialize existing types" is actually quite sensible given what we might call a "traditional" XP approach in which implementations are specific to customer stories. Apparently the new XP is BigUpFrontDesign :-)

In fairness, I might add that while I do all I can to avoid BigUpFronDesign myself, I have been known to build YAGNI code in anticipation of future generalizations. It's courageous of you to try and make this explicit, but if you are to persisit with this effort it would be politic to try and persuade the customers of some potential benefit.

[PS: watch the explicit HTML markup: better to use the Artima formatting suggestions, which make your post easier to quote]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Implementation Driven Design Posted: Nov 20, 2004 11:09 AM
Reply to this message Reply
> With respect, in the absence of specific details you don't
> have a specification, you have a set of ideas for
> implementing a framework to provide solutions to a class
> of problems.

I find that in practice specific details are hard to come by and are usually relatively unreliable.

> Hopefully the actual customer's actual
> problem will be a member of that class, but do you
> seriously suggest they should pay you for solving your
> next customer's problems?

The goal is to avoid solving the next customer's problems, but rather to design for eventualities that will inevitably arise. It is a misnomer that writing generic code increases cost.

> In the XP world no customer would say anything "likely
> wants to be ..." anything. As far as they are concerned
> they want an implementation for a particular story, and
> the only thing of importance thereafter is the estimated
> (and, later, actual) cost. This allows them to prioritize
> the story, and hence guide the developers.

I don't know what you mean by a story. I find the distinction of an "XP world" to be an artificial one, clients are clients are clients.

> You follow this by using the word "specialization": was
> this a typo?

No. I attemp to write generic types and functions which I then specialize by providing appropriate parameters (i.e. type parameters, or function parameters) which are applicable to the specific problem I am faced.

> It seems to me that you are attempting to solve problems
> by generating YAGNIs,

YAGNI = "you aren't going to need it", for the uninitiated.

Overly specialized code, is one of the biggest obstacles to code reuse, as well as is enemy of maintainability and refactoring. As an XP practitioner you should be able to appreciate designing defensively for the inevitable refactoring that occurs.

> unless there's something I am
> seriously misunderstanding here. "A generalized fear to
> specialize existing types" is actually quite sensible
> given what we might call a "traditional" XP approach in
> which implementations are specific to customer stories.
> Apparently the new XP is BigUpFrontDesign :-)

Okay at this point I have to protest the overuse of specialty terms that no one can possibly know. BigUpFrontDesign reveals only 4 google hits!

> In fairness, I might add that while I do all I can to
> avoid BigUpFronDesign myself, I have been known to build
> YAGNI code in anticipation of future generalizations. It's
> courageous of you to try and make this explicit, but if
> you are to persisit with this effort it would be politic
> to try and persuade the customers of some potential
> benefit.

The customer should not see any difference in terms of cost (which of course includes time to delivery) with careful application of IDD. It is an approach which need not cost more once a programmer gets used to the approach. Solving general forms of problems need not be more expensive than solving specific forms of the problems, it in fact often simplifies a problem to generalize it.

Flat View: This topic has 2 replies on 1 page
Topic: Is It High Time To Get Rid Of Classes? Previous Topic   Next Topic Topic: Constrained Value Types using Policies in C++

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use