The following is a direct quote from the Design Patterns book by Gamma, Helm, Johnson, and Vlissides (the Gang of Four -GoF).
Frameworks thus emphasizes design reuse over code reuse...Reuse on this level leads to an inversion of control between the application and the software on which it's based. When you use a toolkit (or a conventional subroutine library software for that matter), you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls....
The linear recursive structure (IList) coupled with the visitors as shown in the above is one of the simplest, non-trivial, and practical examples of frameworks. It has the characteristic of "inversion of control" described in the quote. It illustrates the so-called Hollywood Programming Principle: Don't call me, I will call you. Imagine the IList union sitting in a library.
The above list framework dictates the design of all algorithms operating on the list structure:
- All algorithms must be some concrete implementation of IListAlgo.
- Algorithms that require the construction of empty and/or non-empty lists, must do so via some abstract list factory, IListFactory.
- In order to apply an algorithm to a list, one must ask a list to "execute" that algorithm, giving it the required input parameter.
When we write an algorithm on an IList in conformance with its visitor interface, we are writing code for the IList to call and not the other way around. By adhering to the IList framework's protocol, all algorithms on the IList can be developed much more quickly. And because they all have similar structures, they are much easier to "maintain". The IList framework puts polymorphism to use in a very effective (and elegant!) way to reduce flow control and code complexity.
We do not know anything about how the above list framework is implemented, yet we have been able to write quite a few algorithms and test them for correctness. In order to obtain concrete lists and test an algorithm, we call on a concrete IListFactory, called CompositeListFactory, to manufacture empty and non-empty lists. We do not know how this factory creates those list objects, but we trust that it does the right thing and produces the appropriate list objects for us to use. And so far, it seems like it's doing its job, giving us all the lists we need.
- 1018 reads
