At work, we’ve been talking about how we need more specs. Spec all the things! I admit I was a little slow to get on this train, but a few months of subcontracting for some other companies has helped me see the light. (Most other companies seem to take a “spec none of the things” approach) But what really clarified this for me was a design decision I made this morning. The short explanation is that a helper class needs to be refactored for use in another helper class which is actually a multiton, with each instance using the helper slightly differently. Since this is Objective C, the obvious options for generalizing the soon-to-be helper-helper class are:
- Passing a block (or blocks) into the init method
The problem is, these are all legitimate alternatives… so which one should I use? 10 minutes later, I realized that the problem wasn’t just horizontal code reuse, it was horizontal code reuse in the face of unknown requirements. In other words, I have no idea exactly where and why we’re going to need to insert custom logic into this helper-helper, I just anticipate needing to. Oh, and I also suspect I’ll be subclassing the helper. Now that I’ve clarified my problem, the solution is obvious! In case you don’t see it:
- Class explosion, difficult to reuse parts of methods
- Constructor arguments explosion, no clean way to reuse init paramaters in helper subclasses
- Method explosion. But that’s flexible, extensible by the helper, and allows optional callbacks (bonus!)
Option 3 is the only one that gracefully scales in arbitrary ways for the delegate and the delegee. The next time I’m struggling to arrive at a solution, I’m going to try taking a moment to clarify the problem.
I’m not sure if multiton is actually a word, but it’s a singleton with k instances.