Large initializers/ctors?by Rob Galanakis on 26/01/2012
With closures (and to some extent with runtime attribute assignments), I find the signatures of my UI types shrink and shrink. A lot of times we have code like this (python, but the same would apply to C#):
class FooControl(Control): def __init__(self, value): super(FooControl).__init__() self.value = value self._InitButtons() def _InitButtons(self): self.button = Button('Press Me!', parent=self) btn.clicked.addListener(self._OnButtonClick) def _OnButtonClick(self): print id(self.button), self.value
However we can easily rewrite this like so:
class FooControl(Control): def __init__(self, value): super(FooControl).__init__() btn = Button('Press Me!', parent=self) def onClick(): print value btn.clicked.addListener(onClick)
Now this is a trivial example. But I find that many types, UI types in particular, can have most or all of these callback methods (like self._OnButtonClick) removed by turning them into inner functions. And then as you turn them into inner functions in init, you can get rid of stored state (self.value and self.button).
But as we take this to the extreme, we end up with very simple classes (and in fact I could replace FooControl with a function, it doesn’t need to be a class at all), but very long init methods (imagine doing all your sub-control creation, layout, AND all callback functionality, inside of one method!).
I’ve decided I’d rather have a long init method, usually broken up into several inner functions, rather than a larger signature on the class with layout, callbacks, and stored state. In my mind, it is easier to pull something out into a type attribute, rather than remove it, as anything on the type is liable to be used externally. And breaking up your layout into instance methods that can really only be called once (_InitButtons), from the init, adds a cognitive burden for me.
So I can justify this decision to eliminate extra attributes rationally, but what seals the deal is, I’m not unit testing any of this code anyway. So whether it is in one long method, or broken up into several methods, it isn’t getting tested.
I started out as very much in the ‘break into small methods’ camp but have wholesale moved into the ‘one giant __init__ with inner functions’ camp. I’m curious what you all prefer and firstname.lastname@example.org