View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide

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' ( 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:

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:

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: (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