Don’t Play with Yourself

Some two years ago I had the pleasure of working with a code base that relied heavily on the spring SimpleForm framework. The thing I didn’t like about this framework was the whole controller class hierarchy. Essentially there is about ten super classes and calls get delegated up the whole chain. In theory this is all good OO. So I struggled a bit understanding why I didn’t like it. And as so often when you are struggling a bit of sketching goes a long way:

This sequence diagram degenerated into a christmas tree shape. What is the problem with that? Well these methods operate on different layers. In the case of the SimpleFormController there is methods dealing with Requests and then there is methods dealing with FormBackingObjects. Different levels of abstraction get mixed into a single object (even if they are structured by the inheritance hierarchy). Also this is a point where I struggled a lot with idiomatic smalltalk code. This kind of code might be fine if you are a genius. If you are just a simple developer like I am, probably somethings like this might be much more intelligible to you:

Here each object lives only in a single layer. The same argument can also be used in the long standing debate over private methods, because the receiver of private methods is also self. Now I think there is definitely a case for calling some methods on self, but having a single instance more than twice or three times on your call stack is probably a bad thing.