Home > Blogs > Super Smelly Code

Super Smelly Code

Spotting code that needs refactoring is half the battle ... or maybe a third. Martin Fowler's Refactoring gives a nice list of things to look (smell) for. One smells that was particularly familiar to me was Parallel Inheritance Hierarchies.

I think these smells are most common for developers who create frameworks for other developers to use. The Parallel Inheritance Hierarchy is only briefly described in the book, so maybe my experience with it can shed some extra light on how it occurs. Here is an example of how this kind of smell can sneak in.

Last year I was working with one other developer on creating a new sub-system to a large framework. This new sub-system took an XML file and generated both Java and ActionScript code. The Java code was essentially an SPI and the ActionScript was the corresponding API. For example, in the XML file you could describe a property, like Email. There were different strategies that could be used to provide the Email. These were generated in the Java code. There was an API for accessing the Email that was generated in the ActionScript. The Email property may be a simple type like a string, but often was a complex type. So there would also be an Email Java class and an Email ActionScript class.

Now on the project, we were both writing Java code, it just produced either more Java or ActionScript. One of us did the Java code generation while the other did the ActionScript code generation. It was a very obvious way to split up the work. But the work was very similar and a very similar set of classe and hierarchy resulted. In the Java code generator, there was a Type interface with SimpleType, ComplexType, and CollectionType subclasses. There was basically the same hierarchy in the ActionScript.

Now Fowler says that general strategy for dealing with this is to make the the second hierarchy refer to the first. I don't think that would work so well here. I can't really use the Java code generator to produce ActionScript. Instead I extracted common interfaces in each step of the hierarchy. Then then specific generators were implementations of the same interface. So there was a SimpleType interface that was implemented by JavaSimpleType and ActionScriptSimpleType. Essentially I used Extract Interface and Extract Hierarchy.

This was ok, but I thought that it was possible to do better. Each implementation had as a similar structure. Thus it was possible to introduce a template, i.e. Form Template Method. I thought about putting specific metadata in its own hierarchy, i.e. like how a "long" would map to a java.lang.Long or to an ActionScript Number. It was easier to Extract Interface for this, but to use Inline Class for such simple information.