Editing Software framework (section)

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