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 536 posts at DZone. You can read more from them at their website. View Full User Profile

Waiting for the Abstractions to Emerge

03.20.2012
| 2552 views |
  • submit to reddit

One of the things that I’ve learnt while developing code in an incremental way is that the way the code should be designed isn’t going to be obvious straight away so we need to be patience and wait for it to emerge.

There’s often a tendency to pull out classes or methods but more recently I’ve been trying to follow an approach where I leave the code in one class/method and play around with/study it until I see a good abstraction to make.

More often than not it takes a few times over multiple days before anything reveals itself.

I recently watched Venkat Subramaniam’s Agile India presentation ‘How to Approach Refactoring‘ in which amongst other bits of advice he suggests that we ‘make it work then make it evolve‘ which sounds like it’s covering the same type of ground.

Sometimes in the rush to abstract code to make it easier to test or to reduce the size of a class we end up creating an abstraction which doesn’t really make sense in the business domain.

Having big methods of inline code goes against what we’ve learnt but putting all the code together makes it much easier to see the real abstractions in the code than if some premature abstractions have been made and we have to remember those as well.

It’s still useful to be driven by the goal of pulling out small classes of behaviour/data that are easy to test but spending a bit more time understanding the domain before doing so seems to work better.

We recently had some unwieldy code which we couldn’t quite work out how to abstract so we left the logic inline until we knew better even though it looked quite messy.

Eventually when talking to one of the subject matter experts they mentioned a term that they used which actually combined two things together which we’d originally thought were independent.

A simple rule of thumb is that if there is no name in the domain for what you’re abstracting then it might not make sense to do so.

It doesn’t always work but at least gets your thinking about whether you’re improving the code with the abstraction you’re about to make!

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

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