On 12/17/2010 12:42 PM, Colin Putney wrote:
> Yeah, I've wrestled with this issue a bit. OmniBrowser uses a
> convention where there's a separate class for each menu command. In
> the current version of OmniBrowser, with all the RB stuff installed,
> there are 167 such classes. They're not dynamically generated, each
> one was hand-coded by a contributor.

Yup. I had to "make peace" myself with Announcements before I got to 
fully appreciate them. But once I realized that in return for throwing 
separate classes at the problem you get complete documentation for all 
the events your system might generate, this turned into a very welcome 
trade-off.

> When I first came up with that design, I thought it was pretty awful,
> but I implemented it anyway, as an exercise in reductio ad absurdum,
> hoping that I would learn something that would lead me to a better
> design. To my surprise it was a massive improvement over the previous
> design, and I haven't been able to come up with anything better.

I'm not surprised. For OB this seems entirely warranted. The reasons 
being two-fold: First, OB is a browser *framework* not a browser; and it 
being a browser framework requires third-party extensibility in a way 
that a simple browser wouldn't require. I.e., adding, modifying, 
extending, and restricting commands is something that is almost 
certainly needed by other users of the framework, and having commands 
represented by individual classes, makes this easy and painless.

Secondly, in OB commands encapsulate much more than just a single 
behavior (method invocation); they also encapsulate information about 
how information is presented in menus, buttons etc. whether these should 
be enabled, what icons to use etc. etc. etc. Lots of additional 
information that warrants encapsulating the information separately.

> So yeah, I agree that both everything-in-one-class and
> many-classes-with-few-methods are both warning signs. OTOH, sometimes
> there are good reasons to break this kind of rule of thumb.

Yes indeed. And the reasons can be rather varied. But Occam's razor 
should generally guide us to choose the solution with fewer entities :-)

Cheers,
   - Andreas