[Tutor] dictionary dispatch for object instance attributes question

Kent Johnson kent37 at tds.net
Wed Feb 16 21:02:03 CET 2005


Brian van den Broek wrote:
> As for the code smell thing, I have a follow-up question. I now get the 
> point of the type-based conditional being a smell for classes. (I get it 
> due to a previous thread that an over-enthusiastic inbox purge prevents 
> me from citing with certainty, but I think it was Bill and Alan who 
> clarified it for me.)
> 
> My problem is that I've got a lot of code which was written before I got 
> that point and my code doesn't yet actually do much. (I do have working 
> code for parsing my original source files and storing all of their 
> metadata, etc., but I haven't yet got working code for doing the 
> manipulating the data in the ways I want.)
> 
> I had been thinking better to get everything working and then refactor. 
> Is that an unsound approach? My worry about refactoring now is that I 
> feel like I am rearranging deck-chairs when I should be worried about 
> getting the ship to float :-)

It's a hard question because it really comes down to programming style and judgement.

I like to work in a very incremental style - design a little, code a little, test a little, repeat 
as needed. I believe in 'Refactor Mercilessly' - another XP slogan. I have many years experience and 
a well-developed opinion of what is good design and bad design.

One consequence of this style is, I usually have working code and tests to go with it. It may not do 
very much, but it works.

So for me, if I smell something, and think that refactoring into subclasses - or some other change - 
is the best design for the problem as I understand it, I will probably do the refactoring. It's not 
going to be easier tomorrow :-) If it just smells a little, or the refactoring is major, I might 
think about how to get rid of the smell but put it off until I'm pretty sure it is a good idea.

I don't think of this as rearranging the deck chairs - it's more like building the right foundation. 
Clean, expressive, well-designed code is a pleasure to work with.

For you, it's probably not so cut-and-dried. If you don't have the experience to judge how bad a 
smell is, or to think through the possibilities so clearly, it's harder to know how to proceed. If 
you are in part dabbling with OOP design to learn about it, maybe you want to put off some changes 
until the code is working; then you could make the change and do a comparison and see which one 
feels cleaner to you.

I hope this helps at least a little :-)

Kent



More information about the Tutor mailing list