What is better? Smarter programmers or safer programming environments?
is the impetus for this article. After I stuck my
foot in it (again), saying that .NET and MFC are not frameworks,
Paul Watson asked one of the two obvious questions--"what
is a framework?" (the other obvious question being, "If
.NET and MFC are not frameworks, then what are they?")
Well, Paul's question is an excellent one (and the better of the
two, I think), and it led me down this road in an attempt to put
my money where my mouth is, as it were. So, here goes.
I'd like to hear your opinions as to whether you agree or disagree
with my analysis, what areas you'd like to have explored in further
detail, and whether you think this fits in your own experiences.
I've tried to keep this article brief (isn't that a welcome change?),
and I'll leave it to the reader responses to determine if there's
anything that needs elaboration.
From my perspective, a framework does several
- it makes it easier to work with complex
- it ties together a bunch of discrete
objects/components into something more useful
- it forces the team (or just me) to implement
code in a way that promotes consistent coding, fewer bugs, and
more flexible applications
- everyone can easily test and debug the
code, even code that they didn't write
If I look at this list of vague framework
requirements, I come up with a set of specific classifications
that define a framework:
- wrappers. A wrapper:
- simplifies an interface to a technology
- reduces/eliminates repetitive tasks
- increases application flexibility
- are often re-usable regardless of
high level design considerations
- architectures. An architecture:
- manages a collection of discrete
- implements a set of specific design
- methodologies: A methodology:
- enforces the adherence to a consistent
- decouples object dependencies
- are often re-usable regardless application
So, before talking about frameworks, we
need to talk about wrappers, architectures, and methodologies.
After that, I'm not sure what will be left to say about frameworks!
A Framework Is...
A wrapper is way of repackaging a function
or set of functions (related or not) to achieve one or more of
the following goals (probably incomplete):
- Simplification of use
- Consistency in interface
- Enhancement of core functionality
- Collecting discrete processes into a
logical association (an object)
It's easy to fall into the idea that everything
is a wrapper, just like saying "everything is relative"
(which is untrue, because that statement itself is an absolute),
but if you think about it, not everything is a wrapper.
Most of MFC and .NET are wrappers are the core API's. Some
are laughably so, providing classes that merely wrap messages
into inline methods. Other wrappers are more complex.
For example, I've written a wrapper for the Visio COM object that
takes all the grunt work out of using Visio's primitive functions
(primitive in the sense of "fundamental", as opposed
to "poorly implemented") to do basic things like drop
shapes, connect shapes, and read a shape collection.
But then, you get into implementation that
truly provides new functionality. Yes, it utilizes other
objects, other API's, even other wrappers, but it isn't a wrapper
in itself because it does something totally new, rather than just
adding to, subtracting from, or managing a collection of existing
work. A wrapper modifies existing behavior. There's
a lot of code out there that creates new behavior (thus becoming
An architecture is a style that incorporates
specific design elements. Obviously, a framework needs to
have a design. Its architecture is separate from the collection
of wrappers that it implements and from the enforcement of a specific
implementation methodology. MFC's document-view classes
are an architecture. Essentially, an architecture implements
associations between objects--inheritance, container, proxy, collection,
etc. Architectures have the interesting attribute that,
if you don't like them, you can usually ignore them or replace
them (at least at the beginning of a project). Architectures
can and are useful because they create a re-usable structure (a
collection of objects) that provide some enhanced functionality,
but once you start using them, you're pretty much stuck with them
unless you do some major refactoring.
Let's look at this word:
- Method - a way of doing something
- -ology - in a "scientific"
manner--designed, consistent, repeatable, testable, proven
or, if you want to look it up in the dictionary:
A body of practices, procedures, and rules used by those who
work in a discipline.
OK, we've all worked with design methodologies,
but not too many people have worked with a framework that implements
a particular methodology. I don't think arguing that MFC
is a methodology (with exceptions) is the right way to think about
classes. While a class specifies visibility, interface,
and inheritance usage, and these, along with language syntax,
can certainly be classified as "a body of practices, procedures,
and rules", saying that a class or a collection of classes
is a methodology is like saying that a bunch of leaves make a
tree. A methodology fills in the supporting structure.
Is MFC's message mapping implementation a methodology? Mostly,
yes. While I view it primarily as an architecture that wraps
the underlying API, and you don't have to use it if you don't
want to, in some cases you pretty much can't avoid using it, especially
when you want to define specialized message handlers. You
have to use the method that MFC implements in order to specify
and override the base class implementation. And since this
is an application wide issue, it fits better into the definition
of a methodology than a wrapper (which it is) or an architecture
(which it is). So, things can be fuzzy, and sometimes they
can feel like splitting hairs, but it doesn't detract from the
value of looking at methodology as a classification.
While architectures deal with the associations
between things, a methodology deals with the interaction between
things. The first is a passive relationship and the second
is an activity. Most of the methodology that I implement
is in the activity of communicating between objects, managing
data persistence, responding to user events, etc. Within
those activities are architectures that associate interrelated
Design patterns are both architectures
and methodologies. The structural patterns are more architecture,
when the creational and behavioral patterns are more methodologies
because their usage enforces a particular method of interaction.
However you implement, say, behavioral patterns, you're entire
application has to adhere to that implementation. However,
I will say this one thing--design patterns are in a category that
I would call "lightweight methodologies". They
are not necessarily heavy handed about how components and objects
interact with each other.
Application Automation Layer that I've written about (you
really didn't think I'd write about frameworks without mentioning
the AAL, did you?) is what I'd call a heavyweight framework.
It strictly enforces (to within the reasonable realm of the possible)
component management, data interaction, the usage of external
XML files for GUI definitions, scripting driven functional programming,
etc. Now, you may all say that this is excessive, but I
must disagree. We need frameworks like this to improve quality,
consistency, and usability. Furthermore, a heavyweight framework
can (and has been proven to) allow even junior programmers to
be productive in a large scale development effort with minimal
guidance. Why? Because the framework doesn't provide
a lot of room for, well, screwing up. Even as an experienced
programmer, it helps me from screwing up (for example, taking
shortcuts) as well!
Thoughts About Frameworks
Rather Black & White, Isn't It?
At some point, a framework becomes all
three simply out of necessity. You can't implement a methodology
without implementing wrappers and an architecture. Like
any other kind of programming, abstract concepts don't necessarily
translate directly into concrete implementation, and the same
is true for the wrapper-architecture-methodology view. But
it's still useful to look at these two topics separately so that,
come implementation time, we can make better decisions regarding
the goals of the framework we are implementing. For example,
the issue of re-use regarding wrapper vs. architecture vs. methodology
is different because the focus of the re-use is different.
For wrappers, the focus of the re-use is the process, whereas
for an architecture, it is the associations between objects, whereas
for a methodology, the focus of the re-use is in the interactions
Why Should A Framework Enforce A Methodology?
Well, I wanted to avoid analogies to architecture
and buildings, but this seems like such a good place for one,
but, I'm sure you can figure out the rest of what I can say!
So why say it? Well, sometimes it's important to pour a
thought down on paper so it becomes a bit more concrete (no pun
intended). If you only have wrappers, your team (or just
you) is left to build the application in whatever way their experiences
(or lack thereof) have taught them. In the end (if you even
get to the end), you've got a collection of different styles,
approaches, and solutions that have no consistency. This
is hard to debug, hard to maintain, and hard to extend.
And you when you're done, you almost certainly don't want to repeat
the experience. A framework that enforces a methodology,
on the other hand, tells each programmer how to do important things
like interface with other objects/components/technologies, how
to manage and persist data, and how to avoid crossing application
layers (as examples). The resulting application is easy
to debug, easy to maintain, and very flexible.
Code reviews are fine, but they're misapplied
if you use them to fix coding consistency issues. It's like
health--you want to be proactive in preventing disease (dis-ease,
ha ha ha), rather than taking a handful of pills after you get
sick. So, code reviews should be used to prevent sickness
rather than to cure a sick implementation. This means, a
code review should always look at whether the framework methodology
is being applied properly, is itself appropriate, and that the
code is, in other ways, handling its requirements correctly.
If your methodology includes unit testing
(and thus a framework to support this methodology), the issue
of meeting requirements becomes preventative--the unit tests prevent
the code from becoming sick in the first place. However,
unit tests can be a lot like the new age idea of using magnets
to cure arthritis--they can be quite useless. And I'm not
going to write about good unit tests here--you can read my articles
on unit testing if you're interested.
OK, touchy subject with very opinionated
people in all camps. So, I'm going to skirt around the issue
and say only that agile methods talk about how to manage a project
more than they talk about how to design the objects or implement
the actual code. This is why they're not much help, in my
opinion. What I've found is that just about every job, customer,
or article requires a unique approach. There is no cookie-cutter
method for working with a customer, figuring out what the application
needs to do, and managing the process of implementation.
There is, however, considerable re-use achievable in how each
application is designed, and the framework and wrappers that are
used to reduce implementation time. Agile methods on the
other hand are really good as ideas you can use to work with the
customer or other people in the company.
What About Creativity?
This argument (which, believe it or not,
I've heard many times) holds no water for me. A two year
old can be creative with paint and a canvas, but you won't get
the Mona Lisa. An trained artist uses a method which allows
him to channel his creative forces into creating his work within
the confines of the chosen method. Even Jackson Pollock
had a method to his paintings, although they do look a bit like
what a two year old would do. The point is, a good methodology
actually frees you from the mundane task of figuring out basic
things, so you can apply your creativity in better user interface
design, better performing functions, smoother user experience
by using threads, etc. The result is something aesthetically
pleasing to the user. As a programmer, I can immediately
tell you when a product did not have a good framework methodology
because it is clunky, clumsy, rough in performance, and most likely,
buggy (and the biggest indicator of all--it got delivered a year
later than promised). Are you listening, Microsoft?
An Example: The Document-View Architecture
What would it take for the document-view
architecture to be a true framework? In my opinion, this
would require an automatic coupling between GUI controls and the
document. The programmer need only specify issues such as
data lifetime, the control representing the data, and the document
(or documents!) containing the data. The framework would
then handle all persistence issues, data translation between the
representation of data in the document and the representation
of the data in the view, and would do so without requiring any
coding. A document-view implementation at this level wraps
data translation, provides an architecture for coupling data with
documents, and enforces a methodology by implementing and hiding
the coupling between the GUI control and the document.
What Does The Rest Of The World Say?
A framework is a set of common and prefabricated
software building blocks that programmers can use, extend or customize
for specific computing solutions. With frameworks developers do
not have to start from scratch each time they write an application.
Frameworks are built from collection of objects so both the design
and code of the framework may be reused. - JavaFramework.
That sounds like an architecture and a
collection of wrappers. OK, 2 out of 3.
A skeleton of an application into which
developers plug in their code and provides most of the common
functionality. -- E. Gamma, et al., "Design Patterns",
Well, now that's a radically different
definition, and in my thinking certainly incorporates the idea
of a methodology, if for no other reason than because the "skeleton"
has to define how developers plug in their code and how they interface
with the common functionality provided by the "skeleton".
Implied here (but not necessarily) may also be how the code intercommunicates.
A set of classes which defines a model
of interaction among objects… --
Moduleco (of course, they totally blow it in the additional
OK, this falls into the category of a methodology
because it clearly enforces the interaction style between objects,
but it leaves out the wrapper and architectural aspects.
Software Engineering Associates, Inc
- A comprehensive, integrated class
- An entire architecture is the unit
- Defines the control logic and class
interactions of the application's architecture
- Reduces "dog work" at the
cost of some flexibility
Hmm. OK, that encompasses the three
things I'm talking about--wrappers (integrated class library),
architecture (an entire architecture), and methodology (defines
the control logic and class interactions). Although, this
may not exactly be what the authors had in mind, especially when
reading what they think a
design pattern is, but you never know.
So far, we've seen:
- building blocks
- interaction model
- all of the above (sort of).
Frankly, I'm not sure that there really
is a good definition out there. But really, the one I like
best is from the authors of Design Patterns:
"When you use a toolkit, you write
the main body of the application and call the code you want to
reuse. When you use a framework, you reuse the main body
and write the code it calls."
"Not only can you build applications
faster as a result, but the applications have similar structures.
They are easier to maintain, and they seem more consistent o their
users. On the other hand, you lose some creative freedom,
since many design decisions have been made for you."
"If applications are hard to design,
and toolkits are harder, then frameworks are hardest of all.
...Any substantive change to the framework's design would reduce
its benefits considerably, since the framework's main contribution
to an application is the architecture it defines. Therefore
it's imperative to design the framework to be as flexible and
extensible as possible."
This doesn't formally spell out the idea
of a framework consisting of wrappers, architecture, and methodology,
but it's certainly all there, between the lines. And it
provides a different definition for what most of MFC and .NET
really are--toolkits, not frameworks. Which is the answer
to the other question--what are MFC and .NET if not frameworks?
By thinking about what a framework is,
I think I've come up with a fairly good analysis of the subject
as an introductory topic. Maybe what I'm talking about is
something different from a framework, but in my mind, this is
what a framework should be and do. There are a lot of different
ideas out there as to what a framework is, so now you have mine