This firstly means that the audio analogies do require that students be familiar with audio components. This is very common, mostly because listening to music is a popular cultural activity, and so audio components are commonplace. Moreover, the analogy works with audio components from the viewpoint of a user of the components, and not detailed knowledge of audio technology is required. However, there may be students who are not sufficiently familiar with audio components, and for these students the analogy will not be helpful.
The correspondence between the audio component domain and object-oriented programming is strong enough to be useful, but like any analogy it is not perfect. The analogy works well for classes, objects, interfaces, encapsulation, and composition. It also works, though not as smoothly, for inheritance and polymorphism. The analogy begins to break down with regard to parameters and customisation, although useful points can still be made. There are difficulties in making sensible correspondences regarding the system flow: the object-oriented domain is typically seen as control-flow oriented, and the audio-system domain seems more suited to a data-flow orientation.
Objects: Object identification concerns understanding the nature of an entity with an interface and behaviour. Entities in the audio component domain are easy to understand as they can usually be shown to physically separate, have an understood interface, and a known behaviour.
Classes: In discussing audio objects, different classes of objects can also be easily identified because of mass production of particular components, and interchangeability of kinds of components on the basis of behaviour. Moreover, this can then lead to a discuss of taxonomy, and what interchangeability really might mean.
Interfaces: The interfaces of audio components can either be human interfaces or inter-component interfaces. The human interface, switches, dials, and so on, can be used to explain the nature of an interface, where control of behaviour is facilitated in a limited way. More importantly, the inter-component interfaces can then be introduced in a similar way, describing plugs and matching sockets, tabs and tab-detectors, and so on, and explaining how these also facilitate control of behaviour in a limited way.
Encapsulation: The human interface of audio components allows an easy explanation of encapsulation, as audio components are usually physically encapsulated, except for the provided interface. It can be shown how this allows component integrity to be maintained, and implementation to be modified without modification of the interface or other components. This argument can then also be made for inter-component interfaces.
Composition: While audio components are typically encapsulated, they can physically be opened, voiding the assurances of encapsulation. However, this does allow the internal implementation to be understood, which typically consists of other components, such as transformers, processor chips and so on. The point can be made that such inner components can be used in various different audio components, and that a particular audio component is an encapsulated composition of a set of connected inner components.
Inheritance: The range of audio components can be detailed taxonomically, which might provide a first approach to explaining inheritance. But the real advantage of inheritance in practical programming concerns good understanding of the principles of component interfaces. Inter-component interfaces allow components to be connected in a useful but safe way, typically by the shape of plugs and sockets representing deeper internal dependencies. However, in some cases a new plug can conform to the shape of an existing plug, yet provide different behaviour, a stereo headphone plug conforming to the shape of a monaural headphone plug, for example. In this way, interface conformance leads to greater utility for the context component, such as a tuner, which can be listened to in stereo or monaural sound. Interface conformance is the essence of inheritance as subtyping, which is the real advantage of inheritance.
When introducing a design principle in the abstract, the audio component domain can provide a concrete example with understandable implications, at a time too early for the students to really appreciate examples relating to program design. In this way the analogy helps introduce general principles by means of a specific example, at a time that would otherwise make a specific example problematic.
When later discussing a specific design issue, the students might still have insufficient experience to understand the consequences of various design decisions. Such students, quite reasonably, can be unhappy or unwilling to simply trust authority to dictate that certain designs are good or bad, and unable to determine the correct conclusion by themselves. The audio analogy has the benefit of providing concrete examples with understandable implications backed by student experience, rather than relying on acceptance of authority or understanding of principle. For example, to help a student understand why a particular design is poor, a similar design can be sketched out in the audio component domain, where the student will better see how the poor design leads to undesirable results.
| Previous pattern | Search This Site | Next pattern |