The Quest to Define A Framework

"a class is to object" as "framework is to application"

Why, I hear you ask?
Because, I believe that by defining the "Framework", we can create tools, that understand its formalized nature. This will provide higher levels of reuse.
We need to get to a point where our tools can understand much, much more about the code we write. A more dynamic, pluggable architecture can come about if Frameworks are defined. If you cast away your current notions of the term 'framework' and replace it with what I describe here (perhaps a framework-let), you will see that it is similar to component based architecture but with a cross boundary implementation.

All frameworks will eventually evolve and change.
The .NET Framework is becoming large, no documentation can help, or rather documentation is just a neccesary evil. It is too undefined and scattered and requires human labour, and the quality is based on those humans who create it. There are too little semantics, too little control and this too little insight into our code.

Let's face it, COM gave us ActiveX where before we just had API. COM, was instrumental in teaching us how to develop the .NET Framework, with a good component model. By use of IUnknown, and a small basket of interfaces we got a lot out of it. Just look at all our COM based tools. But now we need relationships, higher level of semantics and a higher level of interop.


HTML taught us about XML, which eventually gave us RDF and the Semantic Web, which is in the making.
We now need the Framework Abstraction Layer, or Framework Object Model. We need to define the IUnknown of Frameworks, and this will finally bring the next generation of components, pluggable models, extensible platforms, built-in, understood and powerful.

My definition of a Framework, therefore, may not be inline with others, but you will still find common things. My quest to define it has now started in earnest. In between day job, podcasting, blogging and other things.

"a class is to object" as "framework is to application". A class is a template, a blueprint for a class, and a framework is effectively the same for an Application. A Framework defines a structure for software extension through configuration, creating an architecture and concrete implementations of assets within the Framework. Effectively the ExtensionFactory pattern.

At the moment, frameworks are abstract, ambiguous, and not really thought of as a software idea for everyday development. Although we build and use "frameworks" all the time, its the actual borders of the term that are soo grey that it becomes impossible to enforce a common standard between framework implementations. In fact, a lot of people shy away from the thought of designing and implementing even the smallest of frameworks.

This, I believe is historic. Nearly all commentary on Frameworks create a complex view of the topic.

The Smallest Framework

Here is my simple rule for the smallest possible framework.
A Factory creates a Concrete Type, defined by Application, which is based on an Abstract Type||Interface and polymorphically invokes it.

Factory--reads--MetaData--Instantiates--ConcreteClass--DerivedFrom--TemplateClass--AndExecutes--TemplateMethod

So we get two types of Actors, the GrayBox and WhiteBox members. Please note The Factory can indeed also be a Proxy|Wrapper|Facade|FactoryMethod|AbstractFactory and more. The term Factory is used to demarcate the smallest unit of functionality, which is to create a substitute or concrete class from the MetaData.





Code the Framework

I leave out the peripheral Types "Environment and Configuration" Settings for brevity. 

namespace Framework
{
    
    public static class Factory
    {
        public static T Create()
        {
            //read configuration/MetaData
            //Load Type S which is configured which is 
            // a subset of T
            //(S <: T)
            return S;
        }
    }

    //T does not have to be abstract, it could be an interface
    public abstract class T 
    {
        public abstract void X();
    }

}

//Defined outside of the scope of Framework
namespace Application
{
    public class Application
    {
        public void DoSomething()
        {
            T t = Factory.Create();
            t.X(); //executes S.X()
        }
    }

    //S is written here for simplicity. 
    //It should be declared outside of the Framework
    //Separate Assembly (in .NET). 
    //It could be, but does not have to be contained within the Application
    public class S : T
    {
        public override void X()
        {
            //my implementation
        }
    }
}

That is the smallest framework. An Application, which offers this pattern within its code, can be said to contain a Framework. However, to truly exist as a Framework it must have the final ingredient which is implicit requirement for reuse. Therefore, it should be defined outside of the scope of the application to be a reusable framework. (Separate Dll, process, boundary, Assembly of the Application)

By having this small framework definition, and pattern, we can create larger frameworks by building onto this pattern and/or coalescing it with itself and other patterns.

Framework value

You would find it hard to put a name on the Framework example above, as it does not actually do anything. That is because currently it exposes no real domain value. In order for the value to be there, T must be a whitebox or blackbox implementation with some sort of domain specific function.

But there is still some value. The Framework defines points of extension, and interfaces to work on.

Perhaps to have value already at this micro level, a Framework should have its own Interface.
Perhaps like the Component Object Model(COM) and others like CORBA, we need a Framework Object Model (FOM). Doesn't sound good, FOM, but it makes sense.
If a FOM existed, and we created software using these extension points, using the Interfaces of FOM, we would be creating cross company, cross software frameworks, that would know and understand how to talk with each other. This is an important step for moving our software industry forward. See my entry on "Things that have to happen before Software Grows UP"

COM did a wonderful thing for software. It spat out many of things we take for granted. As a result of COM and ActiveX, we got DCOM, MTS, COM+, we got a wealth of ideas from Visual Basic, which filtered into .NET and we definitely take a lot of it for granted.

But now even though the .NET Framework is being used and developed and lightning speed, there is no infrastructure for it, itself to grow around. At the moment, .NET is growing so large, its going to eventually need reworking, repackaging, remodeling. The .NET Framework just like any other framework needs to be easier to use and develop on.

Factory
Environment
MetaData
Template
Concrete