Since returning to a more hands-on technical role, I’ve noticed a few habits that I didn’t realise I had, or have more recently acquired. One of these particular habits is (credit to Michael Feathers for the pattern name) is my tendency to sprout tiny classes.
Perhaps it’s my aversion to writing too much procedural code in an object-oriented language or it’s my preference to write small, well encapsulated objects. So far, my general approach seems to be:
I first notice a particular class’ responsibility has grown too much. An easy temptation is to move it to a function, and if I need to share it, might even be tempted to make it static. Instead, I sprout a static inner class who now owns that responsibility. I move any state needed for that responsibility to the class, keeping the tell, don’t ask principle in tact as much as possible. As I interact with the object more, I refine the class name, seeking to understand its responsibilities in different contexts. I might push more responsibilities into it, or move some responsibilities away from it.
I like to try to keep the class private until I’m happy that the class makes sense and all the responsibilities relate to each other in some logical manner. When I’m confident that the class is mature enough, I elevate it to a top level class.
What approaches do other people tend to favour? What can be improved? What doesn’t make sense?
I do quite a bit of this too. I am in the middle of such a class at the moment.
The current example I’m working on started to feel like it should live at the top level when I started to want to test it independently of the client (containing) class.
I usually keep the new top level class package protected if it is only used by its original client, unless there I can see some immediate general use. In the second case maybe I have discovered a concept that’s useful across the application so it might move to an infrastructure package later.
I also do this a lot. Modern IDEs really help because they can move (non-static) instance variables and methods from a class to the class of one of its instance variables. So one can pull out a new kind of object very fast.
I’m a strong sower of inner class seeds. I see it as an attempt to create greater cohension in situations where tight coupling isn’t nessasarily so critical. The standard way of doing this is to just add loads of private methods but sticking them in a private class increases the cohesion and improves readability. And as you say it gives you a simple progressive path to evolve the concept into something more mature.
My general rule is:
* Refactor private method to public method on private class
I do a similar thing in Ruby, although instead of an inner class, I tend to sprout Modules (Mixins) which I immediately, after their definition, include in the original class. The advantage of Mixins being that I do not have to pass on the original state (as I’d have to in case of an inner class).
On reflection, I realised that when I have done this, I have quite a low tolerance level when it comes to promoting an inner class, so they tend to “bud off” quite quickly into top level classes.
Often, I will jump straight to a package protected top level class, which does mean that more classes are visible at the package level. When browsing the code, this might lead to a more accurate feel about the complexity of the package. Conversely, it might make navigation at that level harder, as you have to deal with more concepts.
The principal of having small, well focused classes remains the same.