Software framework

A software framework, in computer programming, is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality. Frameworks are a special case of software libraries in that they are reusable abstractions of code wrapped in a well-defined Application programming interface (API), yet they contain some key distinguishing features that separate them from normal libraries.

Software frameworks have these distinguishing features that separate them from libraries or normal user applications:

1. inversion of control - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.
2. default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.
3. extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.
4. non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.

Rationale

The designers of software frameworks aim to facilitate software development by allowing designers and programmers to devote their time to meeting software requirements rather than dealing with the more standard low-level details of providing a working system, thereby reducing overall development time. For example, a team using a web application framework to develop a banking web site can focus on the operations of account withdrawals rather than the mechanics of request handling and state management.

By way of contrast, an in-house or purpose-built framework might be specified for the same project by a programming team as they begin working the overall job—specifying software needs based on first defining data types, structures and processing has long been taught as a successful strategy for top down design. Contrasting software data, its manipulation, and how a software system's various grades and kinds of users will need to either input, treat, or output the data are then used to specify the user interface(s) —some types of access being privileged and locked to other user types— all defining the overall user interfaces which to the users are the visible in-house Framework for the custom coded project. In such a case, each sort of operation, user interface code and so forth need written and separately integrated into the job at hand also more or less adding to necessary testing and validation.

Criticism

Pros and Cons — an unsettled controversy...

 • It can be argued that frameworks add to "code bloat", and that due to customer-demand driven applications needs both competing and complementary frameworks sometimes end up in a product. Further, some cognizetti argue, because of the complexity of their APIs, the intended reduction in overall development time may not be achieved due to the need to spend additional time learning to use the framework—which criticism is certainly valid when a special or new framework is first encountered by a development staff. If such a framework is not utilized in subsequent job taskings, the time invested ascending the framework's learning curve might be more expensive than purpose written code familiar to the project's staff—many programmer's keep aside useful boilerplate for common needs.

 • However, it could be argued that once the framework is learned, future projects might be quicker and easier to complete—the concept of a framework is to make a one-size-fits-all solution set, and with familiarity, code production should logically be increased. There are no such claims made about the size of the code eventually bundled with the output product, nor it's relative efficiency and conciseness. Using any library solution, necessarily pulls in extras and unused extraneous assets unless the software is a compiler-object linker making a tight (small, wholely controlled and specified) executable module.

 • The issue continues, but a decade-plus of industry experience has shown that the most effective frameworks turn out to be those that evolve from re-factoring the common code of the enterprise, as opposed to using a generic "one-size-fits-all" framework developed by third-parties for general purposes. An example of that would be how the user interface in such an application package as an Office suite, grows to have common look, see, feel and data sharing attributes and methods as the once disparate bundled applications become unified—hopefully a suite which is tighter and smaller as the newer evolved one can be a product sharing integral utility libraries and user interfaces.

This trend in the controversy brings up an important issue about frameworks. Creating a framework that is elegant, as opposed to one that merely solves a problem, is still an art rather than a science. "Software elegance" implies clarity, conciseness, and little waste (extra or extraneous functionality—much of which is user defined). For those frameworks that generate code, for example, "elegance" would imply the creation of code that is clean and comprehensible to a reasonably knowledgeable programmer (and which is therefore readily modifiable), as opposed to one that merely generates correct code. The elegance issue is why relatively few software frameworks have stood the test of time: the best frameworks have been able to evolve gracefully as the underlying technology on which they were built advanced. Even there, having evolved, many such packages will retain legacy capabilities bloating the final software as otherwise replaced methods have been retained in parallel with the newer methods.

Examples

Software frameworks typically contain considerable housekeeping and utility code in order to help bootstrap user applications, but generally focus on specific problem domains, such as:

• Artistic drawing, music composition, and mechanical CAD
• Compilers for different programming languages and target machines.
• Financial modeling applications
• Earth system modeling applications
• Decision support systems
• Media playback and authoring
• Web applications
• Middleware

Architecture

According to Pree, software frameworks consist of frozen spots and hot spots. Frozen spots define the overall architecture of a software system, that is to say its basic components and the relationships between them. These remain unchanged (frozen) in any instantiation of the application framework. Hot spots represent those parts where the programmers using the framework add their own code to add the functionality specific to their own project.

Software frameworks define the places in the architecture where application programmers may make adaptations for specific functionality—the hot spots.

In an object-oriented environment, a framework consists of abstract and concrete classes. Instantiation of such a framework consists of composing and subclassing the existing classes.

When developing a concrete software system with a software framework, developers utilize the hot spots according to the specific needs and requirements of the system. Software frameworks rely on the Hollywood Principle: "Don't call us, we'll call you." This means that the user-defined classes (for example, new subclasses), receive messages from the predefined framework classes. Developers usually handle this by implementing superclass abstract methods.

See also

• Application framework
• Class (computer science)
• Design pattern (computer science)
• Don't repeat yourself
• Enterprise Architecture framework
• Implicit invocation
• Programming paradigm
• Web application framework

External links

• Annual frameworks conference
• What is framework?
• A Quest to Define a Framework
• D4: A Pattern Language for Designing, Developing, Documenting and Deploying Object-Oriented Software Frameworks
• Ammerse, Principles for designing software frameworks
• A guide for Building Frameworks