Sunday, November 20, 2005

From medium to fine grained...

I'm trying to make the step from medium to fine grained objects.

1) Try to create an object with everything it needs at constructor time.
2) Try to have at most one public method to do the work in the class.
3) All other methods are simply for inspecting the state of the object.

I shouldn't have to call a setter on an object once I've built it. Otherwise I've introduced coupling.

What is your object level

In the OO world there is much complaining about how everybody else is a bad OO developer. I'm beginning to understand how lacking my own skills are and am working on improving. However, I believe the vast majority of developers have not evolved their skills enough.

Working with a large team I get to see many of the different skill levels in OO that exist.

1 Modular developer.

Most of the code is organized along similarity lines. This is actually not bad. It can often be refactored into a set of parameter objects, method objects and data objects and which can then be reconstructed as first class objects.

Some smells are: Lots of static methods, Difficulty applying Gang of four patterns, Lots of parameters being passed to methods. Lots of ifs. Some apps look like PLSQL rather than OO.

2 Coarse Grained Object developer

There are a few key objects in the system. Often you'll see deep hierarchy trees with few branches. When you ask yourself the responsibility of an object you can come up with a list, or it is not clear.

Some smells are: it's a little harder to figure out where the behaviour for an object is. Often you'll find more coupling as two object call one another, this is due to the fact that they both have lots of responsibility. Lots of ifs.

3 Medium Grained Object developer

There are a large number of objects in the system, but it is still difficult to make changes sometimes. Each class has a few responsibilities. Not always alot of subclassing. Subclassing tends to override large portions of the super class.

Some smells are: incremental behaviour is hard to add and requires more work than you would think. Things feel good though.

4 Fine Grained Object developer

At most objects have two responsibilities, maybe one. You find that incremental change is really easy, adding a new way of doing something is straight forward.


Our code lives in all four levels. We have some modular code (Look at our test helpers) as well as some really clean objects (look at our allocation results). Most of our code varies between coarse grained objects and medium grained objects.

I think my skill level right now is certainly at the medium grained objects and I'm pushing myself to fine grained objects. It's fun and I'm learning stuff.

An important thing to remember for the OO community is that you can't go from modular to fine grained in a day. It takes years (decades?). YOu need to figure out how to make those steps incrementally.

I'm trying to apply patterns from Ken Becks Smalltalk Best Practice Patterns.

Thursday, November 17, 2005

Embarrassing

Homeless shelters over capacity

Alberta's surplus projected to climb to $8.7 billion

Make sure you give a lot more to charity this year. This is really stupid.

Thursday, November 03, 2005

Requirements gatherer

I think on my next project I'll endeavour to find a requirements gatherer. This is something that has worked out interestingly in our project and I think it is one of the missing pieces in XP.

When you have a customer they often lack the ability to express and prioritize their needs sprint by sprint. They need a grasp of the whole product. They need a grasp of what is important. They need to be able to help the customer prioritize to build a better product.

This is the person that needs to understand the big picture as well as the small. They also need to understand in their bones that development won't be able to build everything the customer believes is essential.

Wednesday, November 02, 2005

Watir

We've been using watir on the project for a couple of weeks now. It is far superior to JWebUnit which we used previously. Great for testing your GUI througha browser. Ruby makes a good scripting language (I guess that's what it is supposed to be) and using the IE Ole Control as the browser engine for the testing harness is a stroke of brilliant simplicity. Stuff like JWebUnit tries to simulate browsers. Makes all those nasty "doesn't run the javascript right" problems go away.

You can find it here:

http://wtr.rubyforge.org/

Hah...

Just spent some time explaining blocks to people who are writing tests in Ruby. To me, it is thank god their back (I started using then 15 years ago with Big Dave Thomas), but there is a whole generation who have never played with Smalltalk.