Software framework: Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
VisualWikitext
imported>7804j
Rewrite lead for conciseness + move details to a separate section + add distinction to regular software to disambiguate + clarify comparison to libraries
 
imported>Curlyquote
m Fix incorrect semicolons
 
Line 1: Line 1:
{{short description|Type of library that helps structure other software}}
{{short description |Software that supports solution development via inversion of control}}
{{Redirect|Framework (computer science)||Framework (disambiguation)}}
{{Redirect|Framework (computer science)||Framework (disambiguation)}}
{{Use dmy dates|date=December 2021}}
{{Use dmy dates|date=December 2021}}


In [[computer programming]], a '''software framework''' is a [[software]] [[abstraction (computer science)|abstraction]] that provides generic functionality which developers can extend with custom code to create applications. It establishes a standard foundation for building and deploying software, offering reusable components and design patterns that handle common programming tasks within a larger [[software platform]] or environment.  
A '''software framework''' is [[software]] that provides reusable, generic functionality which developers can extend or customize to create complete solutions. It offers an [[Abstraction (computer science)|abstraction layer]] over lower-level code and infrastructure, allowing developers to focus on implementing [[business logic]] rather than building common functionality from scratch. Generally, a framework is intended to enhance productivity by allowing developers to focus on satisfying business requirements rather than reimplementing generic functionality.<ref>{{cite web |title=Framework |url=http://docforge.com/wiki/Framework |url-status=dead |archive-url=https://web.archive.org/web/20181007003315/http://www.docforge.com/wiki/Framework |archive-date=7 October 2018 |accessdate=15 December 2008 |work=DocForge}}</ref> Frameworks often include support programs, [[Compiler|compilers]], [[Software development kit|software development kits]], [[Code library|code libraries]], toolsets, and [[Application programming interface|APIs]] that integrate various [[Software component|components]] within a larger [[software platform]] or environment.


Unlike [[Library (computing)|libraries]] where developers call functions as needed, frameworks implement inversion of control by dictating program structure and calling user code at specific points, while also providing default behaviors, structured extensibility mechanisms, and maintaining a fixed core that accepts extensions without direct modification. Frameworks also differ from regular applications that can be modified (like [[Web browser|web browsers]] through [[Browser extension|extensions]], video games through [[Video game modding|mods]]), in that frameworks are intentionally incomplete scaffolding meant to be extended through well-defined extension points and following specific architectural patterns.
Unlike a [[Library (computing)|library]], where user code controls the program's [[control flow]], a framework implements [[inversion of control]] by dictating the overall structure and calling user code at predefined extension points (e.g., through [[Template method pattern|template methods]] or [[Hook (computer programming)|hooks]]). Frameworks also provide default behaviours that work out-of-the-box, structured mechanisms for [[extensibility]], and a fixed core that accepts extensions (e.g., plugins or subclasses) without direct modification.


Software frameworks may include support programs, compilers, code libraries, toolsets, and [[application programming interface|APIs]] that bring together all the different [[Software component|components]] to enable development of a [[software project|project]] or [[software system|system]].
A framework differs from an application that can be extended—such as a [[web browser]] via an [[Browser extension|extension]] or a video game via a [[Video game modding|mod]]—in that it is intentionally incomplete scaffolding designed to be completed through its extension points while following specific architectural patterns. For example, a team using a [[web framework]] to develop a banking website can focus on writing banking business logic rather than handling low-level details like [[HTTP request|web request]] processing or [[state management]].


== Comparison to libraries ==
== Comparison with libraries ==
Software frameworks differ from standard [[Library (computing)|libraries]] in key ways:
Software frameworks differ from standard libraries in key ways:


* [[Inversion of control|''Inversion of control'']]: Unlike libraries, where user code controls the program’s [[Control flow|flow of execution]], frameworks dictate the program’s structure, calling user code at specific points (e.g., through predefined templates or [[Hook (computer programming)|hooks]]). This is usually achieved with the [[Template method pattern|Template Method Pattern]].
* [[Inversion of control]]: In a library, user code controls the program's flow and calls library functions as needed. In a framework, the framework controls the flow and calls user code at specific points, often via the [[Template method pattern|Template Method Pattern]].
* ''Default behaviour'': Frameworks provide pre-implemented functionality (e.g., standard features or workflows) that works out-of-the-box and can be used as-is or lightly customized, often within a predefined structure. Libraries, by contrast, require user code to build and configure functionality from scratch. A framework's default behavior can be provided with the invariant methods of the [[Template method pattern|Template Method Pattern]] in an abstract class.
* Default behaviour: Frameworks provide pre-implemented functionality (e.g., standard features or workflows) that can be used as-is or customized within a predefined structure. Libraries, by contrast, require user code to assemble and configure functionality.
* ''[[Extensibility]]'': Frameworks enable developers to add new functionality or significantly modify (or override) behavior through structured mechanisms like hooks or [[Application programming interface|APIs]]. Libraries allow extensibility, but it is unstructured, relying on user code to integrate functions without predefined integration points. A framework's extensibility is usually achieved by a hook method in a subclass that overrides a template method in the superclass
* Structured [[extensibility]]: Frameworks enable new features or altered behaviour through structured mechanisms such as hooks, callbacks, or APIs. Libraries allow extensibility but without predefined integration points, relying on user code for integration.
* ''[[Open/closed principle|Non-modifiable framework code]]:'' Framework core code is generally fixed, accepting user extensions (e.g., plugins or subclasses) without allowing modifications to the framework itself.
* [[Open/closed principle|Open-closed principle]]: The framework's core logic is generally fixed, allowing extensions (e.g., plugins or subclasses) but not modification of the framework itself.


== Rationale ==
==Pattern==
{{Multiple issues|section=yes|
According to Pree,<ref>{{citation|title = Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design |author = Pree, W |journal = Proceedings of the 8th European Conference on Object-Oriented Programming |volume = 821 |pages = 150–162 |year = 1994 |publisher = [[Springer-Verlag]]|doi = 10.1007/BFb0052181 |citeseerx = 10.1.1.74.7935 |series = Lecture Notes in Computer Science |isbn = 978-3-540-58202-1 }}</ref> 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 the parts where the programmers using the framework add their own code to add the functionality specific to their own project.
{{More citations needed|section|date=April 2011}}
{{Summarize section|date=April 2020}}
{{Weasel|section|date=April 2020}}
{{Essay-like|section|date=April 2020}}
}}


The designers of software frameworks aim to facilitate software developments 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.<ref>{{cite web |url=http://docforge.com/wiki/Framework |title=Framework |accessdate=15 December 2008 |work=DocForge |archive-date=7 October 2018 |archive-url=https://web.archive.org/web/20181007003315/http://www.docforge.com/wiki/Framework |url-status=dead }}</ref> For example, a team using a [[web framework]] to develop a banking website can focus on writing code particular to banking rather than the mechanics of request handling and [[state management]].
The necessary functionality can be implemented by using the [[Template method pattern|Template Method Pattern]] in which the ''frozen spots'' are known as invariant methods and the ''hot spots'' are known as variant or hook methods. The invariant methods in the superclass provide default behaviour while the hook methods in each subclass provide custom behaviour.


Frameworks often add to the size of programs, a phenomenon termed "[[code bloat]]". Due to customer-demand-driven applications needs, both competing and complementary frameworks sometimes end up in a product.  Further, due to 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; this criticism is clearly valid when a special or new framework is first encountered by development staff.{{citation needed|date=April 2011}} If such a framework is not used in subsequent job taskings, the time invested in learning the framework can cost more than purpose-written code familiar to the project's staff; many programmers keep copies of useful [[boilerplate code]] for common needs.
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."<ref>{{citation|last = Larman|first = C|year = 2001|title = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process|isbn = 978-0-13-092569-5|publisher = [[Prentice Hall]]|edition = 2nd}}</ref><ref>{{cite book|title=Design Patterns|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|publisher=Addison-Wesley|year=1994|isbn=0-201-63361-2|authorlink1=Erich Gamma|authorlink2=Richard Helm|authorlink3=Ralph Johnson (computer scientist)|authorlink4=John Vlissides|title-link=Design Patterns}}</ref> 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 (computer science)|superclass]] [[abstract method]]s.


However, once a framework is learned, future projects can be faster 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 rise. There are no such claims made about the size of the code eventually bundled with the output product, nor its 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, wholly controlled, and specified) executable module.
==Tradeoffs==
{{More citations needed|section|date=April 2011}}


The issue continues, but a decade-plus of industry experience{{citation needed|date=April 2011}} has shown that the most effective frameworks turn out to be those that evolve from [[Code refactoring|re-factoring]] the common code of the enterprise, instead of 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, feel, and data-sharing attributes and methods, as the once disparate bundled applications, grow unified into a suite that is tighter and smaller; the newer/evolved suite can be a product that shares integral utility libraries and user interfaces.
One potential downside of using a framework is that it adds to the size of a program, a phenomenon termed [[code bloat]]. This can be exacerbated by using multiple, sometimes competing, frameworks in the same codebase.  


This trend in the controversy brings up an important issue about frameworks. Creating a framework that is elegant, versus one that merely solves a problem, is still rather a craft 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), versus 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.
Learning how to use a framework can be substantial. The intended efficiencies of using the framework may be outweighed by the cost to learn it, especially for a framework that is new to the development staff.{{citation needed|date=April 2011}} However, once a framework is learned, development team speed may increase for future work.
 
Some claim that the most effective frameworks evolve from [[Code refactoring |re-factoring]] an existing solution, such as a generic one-size-fits-all framework developed by third parties for general purposes, rather than from green-field development.


== Examples ==
== Examples ==
 
A framework generally focuses on a specific problem domain, including:
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 [[Computer-aided design|CAD]]<ref>{{citation|doi = 10.1145/98188.98197|last1 = Vlissides|first1 = J M|last2 = Linton|first2 = M A|year = 1990|title = Unidraw: a framework for building domain-specific graphical editors|journal = ACM Transactions on Information Systems|volume = 8|issue = 3|pages =237–268|s2cid = 11248368|doi-access = free}}</ref><ref>{{citation|last = Johnson|first = R E| title=Conference proceedings on Object-oriented programming systems, languages, and applications - OOPSLA '92 | chapter=Documenting frameworks using patterns | date=1992 |publisher = ACM Press|pages = 63–76| doi=10.1145/141936.141943 | isbn=0201533723 | s2cid=604969 | doi-access=free }}</ref>
* Artistic drawing, music composition, and mechanical [[Computer-aided design|CAD]]<ref>{{citation|doi = 10.1145/98188.98197|last1 = Vlissides|first1 = J M|last2 = Linton|first2 = M A|year = 1990|title = Unidraw: a framework for building domain-specific graphical editors|journal = ACM Transactions on Information Systems|volume = 8|issue = 3|pages =237–268|s2cid = 11248368|doi-access = free}}</ref><ref>{{citation|last = Johnson|first = R E| title=Conference proceedings on Object-oriented programming systems, languages, and applications - OOPSLA '92 | chapter=Documenting frameworks using patterns | date=1992 |publisher = ACM Press|pages = 63–76| doi=10.1145/141936.141943 | isbn=0201533723 | s2cid=604969 | doi-access=free }}</ref>
Line 46: Line 43:
* [[Web framework]]
* [[Web framework]]
* [[Middleware]]
* [[Middleware]]
* [[Cactus Framework]] – High performance scientific computing.
* [[Application framework]] – General GUI applications
* [[Application framework]] – General GUI applications.
* [[Enterprise Architecture framework]]
* [[Enterprise Architecture framework]]
Some notable frameworks:
* [[Cactus Framework]] – High performance scientific computing
* [[Oracle Application Development Framework]]
* [[Oracle Application Development Framework]]
* [[Laravel]] (PHP Framework)
* [[Laravel]] (PHP Framework)
* [[Malware]], for example [[Pipedream (toolkit)|Pipedream]]
* [[Pipedream (toolkit)|Pipedream]]
* [[Php4delphi]]
* [[Php4delphi]]
* [[OpenSilver]] - enables legacy applications based on Microsoft [[Microsoft Silverlight|Silverlight]], [[Windows Presentation Foundation|WPF]], and [[LightSwitch]] to be ported into [[WebAssembly]] applications.
* [[OpenSilver]] - enables legacy applications based on Microsoft [[Microsoft Silverlight|Silverlight]], [[Windows Presentation Foundation|WPF]], and [[LightSwitch]] to be ported into [[WebAssembly]] applications
 
== Architecture ==
According to Pree,<ref>{{citation|title = Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design |author = Pree, W |journal = Proceedings of the 8th European Conference on Object-Oriented Programming |volume = 821 |pages = 150–162 |year = 1994 |publisher = [[Springer-Verlag]]|doi = 10.1007/BFb0052181 |citeseerx = 10.1.1.74.7935 |series = Lecture Notes in Computer Science |isbn = 978-3-540-58202-1 }}</ref> 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.
 
In an [[object-oriented programming|object-oriented]] environment, a framework consists of [[abstract class|abstract]] and [[class (computer science)#Concrete classes|concrete]] [[class (computer science)|classes]]. [[Instance (computer science)|Instantiation]] of such a framework consists of [[object composition|composing]] and [[subclass (computer science)|subclassing]] the existing classes.<ref>{{citation|last = Buschmann|first = F|year = 1996|title = Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester|publisher = [[John Wiley & Sons|Wiley]]|isbn = 978-0-471-95869-7}}</ref>
 
The necessary functionality can be implemented by using the [[Template method pattern|Template Method Pattern]] in which the ''frozen spots'' are known as invariant methods and the ''hot spots'' are known as variant or hook methods. The invariant methods in the superclass provide default behaviour while the hook methods in each subclass provide custom behaviour.
 
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."<ref>{{citation|last = Larman|first = C|year = 2001|title = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process|isbn = 978-0-13-092569-5|publisher = [[Prentice Hall]]|edition = 2nd}}</ref><ref>{{cite book|title=Design Patterns|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|publisher=Addison-Wesley|year=1994|isbn=0-201-63361-2|authorlink1=Erich Gamma|authorlink2=Richard Helm|authorlink3=Ralph Johnson (computer scientist)|authorlink4=John Vlissides|title-link=Design Patterns}}</ref> 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 (computer science)|superclass]] [[abstract method]]s.


== See also ==
== See also ==
* [[Class (computer programming)]]
* {{Annotated link |Class (computer programming)}}
* [[Software design pattern]]
* {{Annotated link |Don't repeat yourself}}
* [[Don't repeat yourself]]
* {{Annotated link |Implicit invocation}}
* [[Implicit invocation]]
* {{Annotated link |Software design pattern}}
* [[Software engine]]
* {{Annotated link |Software engine}}


== References ==
== References ==

Latest revision as of 01:04, 18 December 2025

Template:Short description Script error: No such module "redirect hatnote". Template:Use dmy dates

A software framework is software that provides reusable, generic functionality which developers can extend or customize to create complete solutions. It offers an abstraction layer over lower-level code and infrastructure, allowing developers to focus on implementing business logic rather than building common functionality from scratch. Generally, a framework is intended to enhance productivity by allowing developers to focus on satisfying business requirements rather than reimplementing generic functionality.[1] Frameworks often include support programs, compilers, software development kits, code libraries, toolsets, and APIs that integrate various components within a larger software platform or environment.

Unlike a library, where user code controls the program's control flow, a framework implements inversion of control by dictating the overall structure and calling user code at predefined extension points (e.g., through template methods or hooks). Frameworks also provide default behaviours that work out-of-the-box, structured mechanisms for extensibility, and a fixed core that accepts extensions (e.g., plugins or subclasses) without direct modification.

A framework differs from an application that can be extended—such as a web browser via an extension or a video game via a mod—in that it is intentionally incomplete scaffolding designed to be completed through its extension points while following specific architectural patterns. For example, a team using a web framework to develop a banking website can focus on writing banking business logic rather than handling low-level details like web request processing or state management.

Comparison with libraries

Software frameworks differ from standard libraries in key ways:

  • Inversion of control: In a library, user code controls the program's flow and calls library functions as needed. In a framework, the framework controls the flow and calls user code at specific points, often via the Template Method Pattern.
  • Default behaviour: Frameworks provide pre-implemented functionality (e.g., standard features or workflows) that can be used as-is or customized within a predefined structure. Libraries, by contrast, require user code to assemble and configure functionality.
  • Structured extensibility: Frameworks enable new features or altered behaviour through structured mechanisms such as hooks, callbacks, or APIs. Libraries allow extensibility but without predefined integration points, relying on user code for integration.
  • Open-closed principle: The framework's core logic is generally fixed, allowing extensions (e.g., plugins or subclasses) but not modification of the framework itself.

Pattern

According to Pree,[2] 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 the parts where the programmers using the framework add their own code to add the functionality specific to their own project.

The necessary functionality can be implemented by using the Template Method Pattern in which the frozen spots are known as invariant methods and the hot spots are known as variant or hook methods. The invariant methods in the superclass provide default behaviour while the hook methods in each subclass provide custom behaviour.

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."[3][4] 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.

Tradeoffs

Script error: No such module "Unsubst".

One potential downside of using a framework is that it adds to the size of a program, a phenomenon termed code bloat. This can be exacerbated by using multiple, sometimes competing, frameworks in the same codebase.

Learning how to use a framework can be substantial. The intended efficiencies of using the framework may be outweighed by the cost to learn it, especially for a framework that is new to the development staff.Script error: No such module "Unsubst". However, once a framework is learned, development team speed may increase for future work.

Some claim that the most effective frameworks evolve from re-factoring an existing solution, such as a generic one-size-fits-all framework developed by third parties for general purposes, rather than from green-field development.

Examples

A framework generally focuses on a specific problem domain, including:

Some notable frameworks:

See also

References

<templatestyles src="Reflist/styles.css" />

  1. ↑ Script error: No such module "citation/CS1".
  2. ↑ Script error: No such module "citation/CS1".
  3. ↑ Script error: No such module "citation/CS1".
  4. ↑ Script error: No such module "citation/CS1".
  5. ↑ Script error: No such module "citation/CS1".
  6. ↑ Script error: No such module "citation/CS1".
  7. ↑ Script error: No such module "citation/CS1".
  8. ↑ Script error: No such module "citation/CS1".
  9. ↑ Script error: No such module "citation/CS1".

Script error: No such module "Check for unknown parameters".

External links

Template:Authority control

Script error: No such module "Navbox".

Retrieved from "http://debianws.lexgopc.com/wiki143/index.php?title=Software_framework&oldid=5233421"