Object Oriented Programming
Back to Object Oriented Programming in Audio and Music Applications,
to Object Oriented Programming Glossary,
or side effect
What Is Object-Orientation? A Musicians View.
Here is a brief introduction to the principles of Object Oriented Programming (OOP), geared towards musicians. For more technical definitions of the topic see: Definitions of Object Oriented Programming.
Object-orientation is a new technology based on objects and classes. It presently represents the best methodological framework for software engineering and its pragmatics provides the foundation for a systematic engineering discipline. (from the Object-Orientation FAQ)
Objects: Programming based on every-day real-world concepts
One basic way in which Object-Orientation tries to improve the task of programming is by introducing a new way to describe the problems or tasks for which computer programs are written, based on everyday human experience in the real world. When humans act in the real world, they usually have to deal with objects in it. Thus, each problem or task may be described in terms of the objects involved in it, their properties, and the way the objects interact with each other. For example, if the task at hand is performing a 4 part piece, the objects involved might be the 4 musicians, their 4 instruments, and the musical score with its 4 separate parts. Each part contains a number of notes, which are also objects of a certain kind. The musicians can interact with their score parts by reading them and with the instruments by playing them. This can be expressed in a general way as "sending messages" to these objects. So a musician might send the score part the message aScore.readNext to read the next note or group of notes. He might then analyse the notes he just read in his head, determine which notes to play next, and playing them one-by-one on his instrument by sending it the message 'play' (aViolin.play(aNote)). Note that, other than in the real world, the musician does not need to know where he is at any moment in the score part - this task can be done for him, for example, by the score part itself. Like any other object, a playable score part can have a "state" which describes its parts or its characteristics at any moment. So the score can have as one part of its state a "pointer" that points at any moment to the next note that is to be sent to the performing musician for playing. Deciding which object in the system should handle the task of remembering the current position in the score and getting the next note (the performer? the score part? the score? some other object?) is a typical type of problem encountered over and over in the process of designing a system. Experienced developers notice the kinds of solutions that are helpful in the context of such problems as this one, and use them in any new situation that is appropriately similar to it. Such good solutions, or "genial tricks" are called Design Patterns. Design patterns arose out of the experience of advanced programmers and are a very useful way for learning how to program effectively as well as to solve problems by combining pieces of solutions developed for previous similar problems in new ways.
All this sounds partly common sense and maybe even trivial, but this "naturalness" is part of the power of this approach and the reason why Object Orientation has come to be so important. Other reasons are of technical nature, rising out of the structural potential that object oriented concepts contain. We will discuss some of the most important such features in the following sections.
[Figure: 4 Musicians with their instruments and score parts.
Explanatory texts inside the figure Musician 1, Musician 2, Musician 3 etc, Instrument names for each instrument, Part 1, Part 2 etc. for the parts, "Notes" with a number of arrows pointing to individual notes ...
]
Note: Historically the origins of Smalltalk lie in a biological model for computers by its inventor, Alan Kay: Smalltalk was designed to mimic Kay's biological model of individual entities, or "cells," communicating with each other via messages.see: http://ei.cs.vt.edu/~history/GASCH.KAY.HTML
Properties and Advantages of OO Systems
So what is the deal really? You may ask. Why is describing problems in terms of objects so much better than in terms of data and functions? One first advantage, which was mentioned above, is the inherently intuitive character of this approach, based on our everyday experience. But there are a number of other advantages as well. Behind the idea of describing the world using objects lie a few other concepts, which follow almost naturally from the ways we think about objects, such as the notions of behavior (related concepts: interface, protocol, messages, methods), state (related concepts: characteristics, attributes, properties, variables), class, ("kind of object"), and others. The "object oriented" way of describing things, entails almost naturally a few more concepts, which greatly help in the formulation of solutions, the construction of systems, and the management of programs. Three most often mentioned properties that are recognized as necessary ingredients of "real" object oriented systems are:
- Encapsulation: The data inside an object are protected from outside access. They can only be accessed by specific methods which the object explicitly provides as its interface to the outside world. This protects objects from unforeseen changes in their internal state by external interference. Most important, it enforces a highly valuable discipline, whereby an object deals with its own data only in a prescribed number of ways, known to itself through its protocol, i.e. the collection of methods known to it. Example: In an orchestra, a musician is responsible for his own instrument. If you start meddling with those objects which are under the direct responsibility of the individual musicians, you are in trouble. One of the reasons is that taking care of ones own instrument is already a complex task, so it is better left to the individual that uses the instrument all the time. Collectivist schemes are thinkable whereby the instruments are handed over to the musicians by a central authority, like in by the teacher in a school class. The comparison of the "encapsulated" versus the "collectivist" approach in this case is left to the reader.
- Polymorphism: Communication with objects takes place by sending them messages. What distinguishes a message from a simple function call, is that while the code of a function call is fixed, a message has no fixed code! So instead of having to decide each time what must be done with the data at hand, you can just pass the data to an object and it will deal with them "in its own way". This makes it possible to get rid of a great proportion of those cumbersome "decision" structures (if-statements, switch-statements), which look at a piece of data and decide which function to apply to it according to its kind. As said, just send the data (object) a message, and it will deal with it in its own way. Thus the messsage describes the kind of task to be done, while the method defines the particular way in which this task is done, which depends on the kind of object receiving the message. For example, a conductor may by his gestures send a message to his orchestra to play more loud, more light, staccato, or the like. Each musician will translate this message to a different method for playing on his/her own instrument (the violin player: more pressure on the bow, faster bowing; the flute player: more breath etc.) It would be unfeasible for the conductor to give each musician directly the instructions needed to get the desired effect on his particular instrument. Thus, the conductor uses a message as "generic instruction" instead. (See also message on how polymorphism improves the coding of choices)
- Inheritance: Classes are used to describe objects. A class is a description of a kind of object that is capable of creating instances of this kind, e.g. the class "Note" can create any number of different notes (C3 quarter, C#3 eighth etc.). Inheritance means that one can define children subclasses that inherit the properites and behavior of the parent class, while further refining - or even redefining ("overriding" - some of these characteristics to to create a richer, more specific, different kind of object. For example, One may create a kind of abstract class called "Instrument" that holds the basic properties and behavior necessary for playing notes. Then one defines all sorts of musical instruments (Guitar, Violin, Flute, Drums etc) as subclasses of Instrument. The point is that all these subclasses will share those parts of the behavior of their parent class which are not redefined, such as perhaps methods for getting notes from a score, translating parts of their symbolic content (e.g. "A-flat", "quarter", "dotted-half note") into parameters such as pitch, durations (depending on the prevailing tuning, tempo and other context), while changing only that behavior which is specific to each instrument (for example the different types of synthesis that characterize each instrument). In that way, basic shared behaviors are always defined in one part of the system, and are refined systematically by subtle means in subclasses, instead of having to be copied all over the place.
These properties may seem very abstract and their effects are subtle. There is only one way to understand their value - by experience. Practice has shown that these seemingly simple ideas have enormous beneficial effects on programming, which is one main reason why OOP has been so successful.
More detailed discussion of these characteristics and their relation to earlier software systems concepts are found amongst others in the Smalltalk Patterns book by Beck 1997 and in the GNA OOP Tutorial in: http://uu-gna.mit.edu:8001/uu-gna/text/cc/Tutorial/ (the latter is very technical!), or see any of the already active links in the Object Oriented Programming Glossary.
See also OOP Examples for collected examples (at this moment just a few reading notes).
Links to this Page