Framework mini-taxonomy and API's

Framework mini-taxonomy

Here’s my mini-taxonomy of object-oriented frameworks that I have not seen elsewhere. I define frameworks as code that uses the inversion of control pattern, where it “calls you back” (the so-called Hollywood Principle).

  1. Domain frameworks. These were the original frameworks, from Smalltalk. They gave you a bunch of objects that worked together, effectively showing you how a domain works. You have specific places where you can extend the framework.

  2. Quality attribute frameworks. These are newer. They grab a quality attribute and hoist it such that framework users don’t have to worry about that quality attribute. They are generally domain-neutral. Example: While Struts is just a domain framework (handles web requests), EJB is a quality attribute framework that hoists concurrency, distribution, and coupling pretty well, and security quite poorly.

Qualities of API’s

Bill Scherlis likes to point out that framework interfaces are wide and deep, while traditional API’s are narrow and shallow. I’ve been experimenting with refactoring a framework interface so that it is narrow and deep (and yes, I need to blog about that too…), which makes me wonder if other combinations in the {wide,narrow} x {deep,shallow} space are interesting. Perhaps it is interesting to have a wide interface where you only get back simple objects, with no chaining like you get in deep interfaces, for example in Eclipse: “grab the Workspace, then the window, then the menu manager, then the menu, then ask the menu to add an item”.