Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain’s Random Thoughts on Software Development and Adventure Sports
     
`
 
Discovering...
Industrial Logic

Microblog Feed
    Previous Feeds...
    Recent Thoughts

    Recent Comments
    Categories
    Archives
    October 2009
    M T W T F S S
    « Sep   Nov »
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
    RSS Feed
    Add to Technorati Favorites

    Goodbye Simplicity; I’m Object Obsessed

    In retrospect, I think Object Orientation has tremendously helped me become a better programmer. But at the same time, its also made me vulnerable to including extra complexity (or at least thinking in terms of more complex solutions) in my code.

    One of the important lessons I learned a few years ago was, not to try and model my software on real world (my perception of reality). This leads to my software solution ending up as complex and easy to misunderstood as the real world. Soon I started embracing “There is no Spoon” philosophy and really focusing on abstractions.

    Last year, I was again caught red handed, trying to sneak in too many objects (and hence complexity) into my code. This time I was pairing with another developer new to TDD and we were building a Snakes and Ladders game using TDD. The focus was really demonstrate TDD in a very different context.

    (I’m sure everyone is aware of the Snakes and Ladders board game).

    Snakes And Ladders

    30 mins into the pairing, we had the following classes with wonderful tests for almost each class:

    • Game
    • Board
    • Player
    • Dice
    • Snake
    • Ladder

    Just then Sandeep Shetty was passing by and he looked at the beautiful piece of mess we had created. He was surprised how royally we were wasting our time. The following 15 min discussion helped all of us realize how we were so caught up in TDD and coming up with all those (useless) abstractions when simply we could just have

    • one class called Game (place holder, the class is not really required) with
    • one method called move(int number_on_the_dice)
    • a list to hold the current position of each player on the board (there can be more than 2 players)
    • a hashmap with starting and ending points on the board (represents both the snakes and ladders, how does it matter whether its a snake or a ladder, they are just starting and ending points on the board)
    • a counter to calculate player’s turn
    • and … and what? …that’s it

    Can you beat the simplicity of these 15 odd lines of code? Its not really about the number of lines of code, its about the conciseness and simplicity of it.

    Refactoring Teaser IV is another great example of “Death by Objects” pattern. Solution Summary highlights the real difference.

    I would also suggest reading Embrace Simple Design, an analogy.

    • Share/Bookmark
    • coreyfurman
      Non Sequitor. Your logic withstands the smell test only for the trivial or nearly trivial code base. With any sufficiently complex solution, modeling the objects on the real world helps the developer formulate and verify the algorithm.
    • Nice!
    • some minor typos

      "helped me become a better program."

      should be "helped me become a better programmer."

      " coming up with all those (unless) abstractions"

      "unless" should be "useless" I think
    blog comments powered by Disqus
        Licensed under
    Creative Commons License
    Design by vikivix