Dimensions of software frameworks

Feb 11, 2008 | George Fairbanks

This past weekend I was chatting with Ciera
Jaspan
about her work on frameworks.
We chatted about Bill Scherlis’s
observation that framework interfaces are wide, while traditional
library interfaces are narrow. As I mentioned briefly in a prior
blog posting
There is another
difference you see in frameworks — some interfaces are deep, others
are shallow.

In saying that frameworks have wider interfaces than libraries, Bill
is saying that a client program using a framework interacts with many
framework objects, unlike a library where you would typically interact
with just one object. The second dimension, deep vs. shallow,
addresses how deeply the client traverses into the data structures.
In Eclipse, for example, you often find code like this fictitious
example:
parent.getWorkbench().getMenuManager().getToolbar().add(myNewItem).
Let’s call that deep, since it allows the client to dig deeply into
the data structures exposed by the framework. Shallow interfaces
would expose a limited set of objects to the client, perhaps just one
level.

These dimensions become interesting when you ask “How can I design my
framework to be comprehensible by mortals?” The closer your framework
is to the top left (narrow + shallow), the easier it will be for
developers to understand and use correctly. You can think of two
competing forces: One pulling to the bottom right (wide + deep)
because it’s easier for framework writers to build and requires less
up-front planning, and one pulling to the top left (narrow + shallow)
which is easier to use.

There is lots of hype today about Service Oriented Architectures, and
there has been longstanding interest in making software services
available remotely using remote procedure calls, CORBA, RMI, etc., but
this is hard to do with deep + wide framework interfaces. Of the two,
deepness is harder to enable remotely. Consider the fictitious
example above, and realize that it would translate into four remote
calls. A shallow interface would require fewer remote calls, or even
just one.

The wrong way to interpret these insights would be to assume that all
frameworks should be narrow and shallow, and that it’s just ignorance
and laziness of framework writers that has given us wide and deep
frameworks. Instead, we should try to develop heuristics to guide the
choice for framework writers, because some domains will be amenable to
the narrow + shallow frameworks (like EJB), while other domains may
require either interfaces that are deep, wide, or both.

About

George Fairbanks is a software developer, designer, and architect living in New York city

Contact

gf-web@georgefairbanks.com
124 W 60th St #37L
New York, NY 10023
+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks