A Framework Is...

 

A Wrapper

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 subject to

An Architecture

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.

A Methodology

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 objects.

Design Patterns

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.