Login
Hello
(
Sign in
)
or
Register
Menu
Home
Products
Qor3
LanP3
Our Portfolio
Technologies
Testimonials
Industries
Case Studies
Our Services
Design
Development
Web
Blogs
ClearContent
About Lucid
Contact Us
Search
Syndication
Blogs
ClearContent
General
Software Patterns
A Framework is a Class
a "class is to object" as a "Framework is to Application"
With all the people using .NET Framework, you would think that the word Framework would be used more correctly than it is.
Ask anyone, and you will get such a mixture of opinions, which I believe is limiting the “Framework” from reaching its full potential in everyday development.
The current definition of a Framework is far too misunderstood. I also think that the idea of what a Framework is has changed from years gone by, and that a new way of thinking about it has to be looked at.
But why is it important?
Frameworks offer architecture and a means for reuse that can offer agility in our modern world. If you are developing a piece of code, thinking of it as a Framework, instils a way of thinking that promotes reuse, extensibility and agility. But first we have to understand what it is and then how useful it can be.
For example, Software Factories can and will only succeed if there are good Frameworks on which to base it.
The Confusion that is out there
Let us look at a culprit and a winner.
“Microsoft Enterprise Library Application Block”.
It is not a Library; it is not an Application, nor a block.
Alternatives: The “Enterprise Application Framework”, “Application Foundation Framework”, “Enterprise Architecture Framework”
It is a Framework, it should be rejoicing and propagating itself as one, but it doesn’t.
Then,
DirectX
(especially the first and original versions) were libraries, and now the XNA is a framework. Perfect.
So what is a Framework and when should you use it to describe your software?
The Framework Distinction
I am particularly interested in the Framework in relation to other sorts of terminology, for example: the terms Component, Library, Application and so on.
So when can you call it a Framework?
You build one class, no members (except default constructor) and compile it into your smallest compiled linkable asset. What is it?
Firstly is it a Framework? – No.
Is it a component? Could be, perhaps the name of the class is expected by another piece of code, even if it does nothing.
A Library refers to the objects as leaves. Everything is a leaf, and associations are not essential to it as a whole. It is class library, having lots of classes or an Object Library, having lots of objects, depending on whether you are speaking of it in a design-time or run-time way.
A component however refers to something that is necessary to form a whole. You cannot have a component “fit” into nothing; therefore a pluggable or compositional structure is being alluded to. Component based development is a large term, and is still being sculptured into its Patterns and definitions. See
here
A framework is a layer on which you build. It helps define and constrain a Domain.
For example, in Component Design, the term Component Framework, refers to the Framework on which components will interact, exist and grow. Without the Framework, a component cannot realize its first fundamental aim, which is to be reused.
As soon as the following is true, you can begin calling it a Framework.
- You have an abstract class which must be implemented by the caller, to facilitate a function and/or
- You make use of a Pattern that creates one or more Hooks to the calling implementation. For example: the Template Method, Factory Method, Abstract Factory (GOF) , Model View Controller (POSA) etc
If code does not contain white-box solutions and it is purely black-box, it is a component. If it is “grey-box”, you have to look a little deeper into the code. If the code subscribes to Hooks within a known Framework, then it is likely to be more of a component. Let’s go a little deeper.
Frameworks help provide and help to establish Architecture.
They are blue-prints
A Framework provides architecture, by how it is structured and by the nature of the Hooks it provides. It can provide and sometimes enforce object granularity, object structure, interfaces, contracts, use of queuing, messaging etc
Using a given Framework correctly (by abiding to the rules, and staying within the boundaries), you are beginning to "Establish" an architecture for your application.
Some believe it is hard to go against a well written the framework and some believe Frameworks should not try to impose too much.
But that in my opinion is where the definition of a Framework lies.
If a piece of software does not impose and/or provide any architectural significance it should likely be classified as a Library/component, and if it enforces an architectural approach, it is more likely to be considered a Framework.
Many applications built on the same Framework, will emit a common architectural feel.
The Applications as a whole may be different, but the structure within is common. It is built on teh foundation or blue-print of the Framework.
Therefore, one could say:
that a "class is to object" as a "Framework is to Application"
A framework provides the interface and contract to which all applications should be built and therefore behaves much like a class does to the object.