Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 543 posts at DZone. You can read more from them at their website. View Full User Profile

Coding: Another Outside In Example

04.19.2010
| 3770 views |
  • submit to reddit

I've written before about my thoughts on outside in development and we came across another example last week where we made our life difficult by not initially following this approach.

The rough design of what we were working on looked like this:

outsideIn1.gif

My pair and I were working on the code to do the calculations and we deliberately chose not to drive the functionality from the UI because the other pair were reworking all our validation code and we didn't want to step on each others toes.

We therefore started driving the code directly from the individual calculations and decided to create an object to represent each of the types of calculation. It worked quite well for all but one of the calculation classes, 'Calculation3, which became increasingly complicated as we added more test cases.

At this stage we rotated pairs and still unable to see a way to simplify 'Calculation3′ we decided to try and drive it from the object which would actually make use of it.

As Darren Hobbs pointed out in another discussion:

Don't design an API. Write the code that you'd want to be able to write to use your API.

In this case it became clear that the missing object which could drive out the Calculation objects was a 'Calculator':

outsideIn2.gif

We started writing tests for the calculator and initially it didn't seem to make that much difference – the design of nearly all the individual 'Calculation' objects remained the same.

However, once we got to the tests which would drive out the functionality currently in 'Calculation3′ it became clear that we had actually got 3 objects inside 1 and that what we really needed in this case was an orchestrating class which could delegate down to small objects to do the calculations.

outsideIn3.gif

The most interesting thing about this situation for me is that I often do drive code from the outside in and I've even previously written about the benefits of doing so but in this context I got it wrong and it was a slightly painful lesson!

From http://www.markhneedham.com/blog/2010/04/18/coding-another-outside-in-example

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: