In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, toolsets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.
Frameworks have key distinguishing features that separate them from normal libraries:
inversion of control: In a framework, unlike in libraries or in standard user applications, the overall program's flow of control is not dictated by the caller, but by the framework. This is usually achieved with the Template Method Pattern.
default behaviour: This can be provided with the invariant methods of the Template Method Pattern in an abstract class which is provided by the framework.
extensibility: A user can extend the framework – usually by selective overriding – or programmers can add specialized user code to provide specific functionality. This is usually achieved by a hook method in a subclass that overrides a template method in the superclass.
non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting user-implemented extensions. In other words, users can extend the framework, but cannot modify its code.
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, 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." This means that the user-defined classes (for example, new subclasses) receive messages from the predefined framework classes. Developers usually handle this by implementing superclassabstract methods.
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. However, once a framework is learned, development team speed may increase for future work. Learning how to use a framework can be substantial. The intended efficiencies of using the framework may be outweighed by the cost of learning it, especially for a framework that is new to the development staff.[5] 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.
Recently, Microsoft Research launched an open-source project that covers software engineering, web navigation, and personal assistant tasks, with training data and evaluation methods available to researchers.
Examples
A framework generally focuses on a specific problem domain, including:
Artistic drawing, music composition, and mechanical CAD
↑Pree, W (1994), "Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design", Proceedings of the 8th European Conference on Object-Oriented Programming, Lecture Notes in Computer Science, vol.821, Springer-Verlag, pp.150–162, CiteSeerX10.1.1.74.7935, doi:10.1007/BFb0052181, ISBN978-3-540-58202-1{{citation}}: Cite uses deprecated parameter |citeseerx= (help)
↑Larman, C (2001), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nded.), Prentice Hall, ISBN978-0-13-092569-5
↑Vlissides, J M; Linton, M A (1990), "Unidraw: a framework for building domain-specific graphical editors", ACM Transactions on Information Systems, 8 (3): 237–268, doi:10.1145/98188.98197, S2CID11248368
↑Johnson, R E (1992), "Documenting frameworks using patterns", Conference proceedings on Object-oriented programming systems, languages, and applications - OOPSLA '92, ACM Press, pp.63–76, doi:10.1145/141936.141943, ISBN0201533723, S2CID604969
↑Birrer, A; Eggenschwiler, T (1993), "Proceedings of the European conference on object-oriented programming", Frameworks in the financial engineering domain: an experience report, Springer-Verlag, pp.21–35
↑Gachet, A (2003), "Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools", Journal of Decision Systems, 12 (3): 271–281, doi:10.3166/jds.12.271-280, S2CID29690836
