This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: A Framework is coalescent patterns
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
It has been a well over a year since I reviewed my thoughts on what a framework is.
It has been a nice exercise, since my ideals for a Framework have definitely changed.
This time, I decided to define it as to accommodate the real value for which frameworks are intended to achieve.
Defining an abstract entity can be extremely subjective and as you are probably aware, there are many definitions out there.
By no means are all the definitions wrong, but I feel that some terminologies used can offer different interpretations.
Also, due to the pressure of declaring and exposing a frameworksâ value, I feel that many definitions are too flexible.
The definition I propose is not to take anything away from all the other definitions, but to add to it.
The more definitions that exist, will eventually force for a tangible singular version.
A singular version is what we need, but we have to have many definitions before that will occur.
"A Framework is coalescent design patterns providing extensibility through mainly abstract classes.
The aim is to form a structure for a problem domain, which can be extended.
A framework can offer as little as basic guidance of an algorithm or an entire foundation to a problem domain"
[Coalescent Design Patterns = one or more Design Patterns merged into one. Sometimes referred to as (c)omposite Design patterns.]
Architecturally speaking, the hierarchy from known OO constructs to the abstract idea of a âframeworkâ can be modelled as:
Framework -> Coalescent Design Pattern -> Design Pattern -> Class
On top of this structure sits the application
Application -> Concrete implementation of Framework
The value of the Framework is that it provides the components and Application layers,
the architectural guidance needed to achieve the requirements.
It does not necessarily accomplish the specific domain requirements.
This brings in the question of the different types of frameworks and what they offer.
A framework that provides a complete abstraction of relatively generic concepts such as logging would be considered as Structural Frameworks,
and those that abstract a problem domain such as a booking system framework, are more specific and can thus be called Application Frameworks.
An Application Framework can utilize one or more Structural Frameworks.
Previous Topic
