Geeks With Blogs
Dynamic Concepts (in) Development Musings of TheCPUWizard

This post was originally written in May 2008...

It probably took longer to pick a title for this post than it will take to write the actual post......

This post is part of a multi-part series on developing Agile Software (see What Is Agile Software ). In this installment we will examine some of the issues that can help that class definitions are stable and reusable.  Experience has repeatedly shown that two primary factors had severe negative impact in reaching this goal:

  • Feature Creep  (constantly adding functionallity)
  • Changing Requirements (typically initialided by the "Business Department")

Each of these tend to require the modification of existing code in many designs which directly results in "code churn". It is not at all uncommon for this to break existing functionallity (often in subtle ways). Also these items tend to prevent the class from being re-used.

During my training sessions, I will often ask the class members to (individually or in pairs) design the exposed interface to a "Ball" class and to write an application which can perform a small set of operations. Assuming 20 students and a pair programming setup, I typically get 10 radically different designs. Yet each team was presented with the same (albiet vague) requirements.

Even more revealing is gathering both the "ball" and "application" portions of the design from each team, shuffleing them, and then randomly assigning hem back to the teams [OK, I cheat...I make sure no team gets back either part they submitted]. The teams are then tasked with getting the combination they were given to properly work.

Some teams will make changes at one "layer" to make it play with the other, while other teams will modify both portions to get a working compromising solution, and a few will scrap (nearly) the whole thing.

After the exercise is complete, I usually have a room full of very fustrated people. Clearly a simple task such as this should not be so difficult........

The most common root cause is that the original developers had included operations that included as members functionallity that was related to things you could "Do TO" and object, rather than restricting the class definition to what was intrinsic in the concept represented by the class. These items are readily identifiable because they can be implemented completely in terms of existing public methods and properties.  For the scenario given above, this is often seen in the "Ball" class getting methods such as "Throw", "Catch", "Kick", "Bounce". These actions are not inherent in the ball itself, and can best be handled by being implemented outside of the class.

 By factoring out the extrinsic operations, we immediately see significant benefits. First, we effectively establish an upper bound on the functionallity of the class itself. This in turn yields a stable implementation that can be thoroughly tested and then used in a variety of scenarios. Second, we avoid complex class hierarchies by isolating the coupling between concepts. This improves the re-usability of each component simply because they are more tightly focused.

We are on our way to developing a solution that eliminates on-going modifications to existing codebases, and yields well defined building blocks that can be leveraged into a flexible solution.

Posted on Saturday, May 3, 2008 12:45 AM Developing Agile Software | Back to top

Comments on this post: Ask NOT what you can Do TO your object...

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © David V. Corbin | Powered by: