imported>Asaf.s.lumen: /* Tradeoffs */

2025-09-02T06:15:50Z

Tradeoffs

New page

{{short description |Software that supports solution development via inversion of control}}
{{Redirect|Framework (computer science)||Framework (disambiguation)}}
{{Use dmy dates|date=December 2021}}

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 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.

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 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|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|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,<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.

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.

==Tradeoffs==
{{More citations needed|section|date=April 2011}}

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.{{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 rather than from green-field development; such as a generic one-size-fits-all framework developed by third parties for general purposes.

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

* 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>
* Financial modeling applications<ref>{{citation|last1 = Birrer|first1 = A|first2 = T|last2 = Eggenschwiler|year = 1993|work = Frameworks in the financial engineering domain: an experience report|publisher = [[Springer-Verlag]]|title = Proceedings of the European conference on object-oriented programming|pages = 21–35}}</ref>
* Earth system modeling applications<ref>{{citation|last1 = Hill|first1 = C|first2 = C|last2 = DeLuca|first3 = V|last3 = Balaji|first4 = M|last4 = Suarez|first5 = A|last5 = da Silva|title = Architecture of the Earth System Modeling Framework (ESMF)|journal = Computing in Science and Engineering|volume = 6|year = 2004|pages = 18–28|title-link = ESMF|doi = 10.1109/MCISE.2004.1255817|s2cid = 9311752}}</ref>
* Decision support systems<ref>{{citation|last = Gachet|first = A|year = 2003|title = Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools|journal = Journal of Decision Systems|volume = 12|issue = 3|pages = 271–281|doi = 10.3166/jds.12.271-280|s2cid = 29690836}}</ref>
* Media playback and authoring
* [[Web framework]]
* [[Middleware]]
* [[Application framework]] – General GUI applications
* [[Enterprise Architecture framework]]

Some notable frameworks:
* [[Cactus Framework]] – High performance scientific computing
* [[Oracle Application Development Framework]]
* [[Laravel]] (PHP Framework)
* [[Pipedream (toolkit)|Pipedream]]
* [[Php4delphi]]
* [[OpenSilver]] - enables legacy applications based on Microsoft [[Microsoft Silverlight|Silverlight]], [[Windows Presentation Foundation|WPF]], and [[LightSwitch]] to be ported into [[WebAssembly]] applications

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

== References ==
{{Reflist}}

== External links ==
* {{Wiktionary inline|software framework}}
* {{Commons category inline|Software frameworks}}

{{Authority control}}

{{Computer science}}

[[Category:Software frameworks| ]]
[[Category:Object-oriented programming]]
[[Category:Software architecture]]

Software framework - Revision history

imported>Asaf.s.lumen: /* Tradeoffs */