69 lines
4.8 KiB
Text
69 lines
4.8 KiB
Text
|
#lang scribble/manual
|
||
|
|
@(require (for-label racket))
|
||
|
|
|
||
|
|
@title{Introduction to Objects}
|
||
|
|
Introduction to objects and messages@section{categories}
|
||
|
|
Language>OOP
|
||
|
|
@section{related}
|
||
|
|
Reference/Classes, Classes/Class, Classes/Object, Reference/Messages, Guides/Polymorphism
|
||
|
|
|
||
|
|
@section{section}
|
||
|
|
Objects and Messages
|
||
|
|
|
||
|
|
The SuperCollider language is an object oriented language. All entities in the language are objects.
|
||
|
|
An object is something that has data, representing the object's state, and a set of operations that can be performed on the object. All objects are instances of some class which describes the structure of the object and its operations.
|
||
|
|
Objects in SuperCollider include numbers, character strings, object collections, unit generators, wave samples, points, rectangles, graphical windows, graphical buttons, sliders and much more.
|
||
|
|
|
||
|
|
Operations upon objects are invoked by messages. A message is a request for an object, called the receiver, to perform one of its operations. The means by which the operation is performed is determined by the object's class.
|
||
|
|
Objects of different classes may implement the same message in different ways, each appropriate to the class of the object. For example all objects understand the
|
||
|
|
@racketblock[value:: message.
|
||
|
|
Many objects simply return themselves in response to ]
|
||
|
|
|
||
|
|
@racketblock[value::, but other objects such as functions and streams first evaluate themselves and return the result of that evaluation.
|
||
|
|
The ability for different objects to react differently to the same message is known as emphasis::polymorphism:: and is perhaps the most important concept in object oriented programming since it allows the object's behaviour to be abstract from the point of view of the user of the object (the client).
|
||
|
|
|
||
|
|
The set of messages to which an object responds to is known as its interface. A set of messages that implement a specific kind behaviour is known as a protocol.
|
||
|
|
An object's interface may include several protocols which allow the object to interact in several different contexts.
|
||
|
|
For example all objects implement the 'dependancy' protocol which allow the object to notify other dependant objects that the object has changed and that the dependant should do any necessary action to update itself.
|
||
|
|
|
||
|
|
An object's internal state may only be changed by sending it messages. This allows the implementation of the object to be hidden from the client.
|
||
|
|
The advantage to this is that the client does not depend on the object's implementation and that that implementation can be changed without having to change the client.
|
||
|
|
|
||
|
|
See link::Reference/Messages:: for more information about messages.
|
||
|
|
|
||
|
|
]
|
||
|
|
@section{section}
|
||
|
|
Classes, Instance Variables, Methods
|
||
|
|
|
||
|
|
An object's class contains the description of the object's data and operations. A class also describes how to create an object which is an instance of that class.
|
||
|
|
|
||
|
|
An object's data is contained in its instance variables. These are named variables that describe the object's state.
|
||
|
|
The values of the instance variables are themselves objects. For example, instances of class link::Classes/Point:: have instance variables named 'x' and 'y' which contain the coordinate values of the Point.
|
||
|
|
|
||
|
|
An instance variable is only directly accessible from within the class itself. The author of a class may decide to expose instance variable access to clients by adding getter and/or setter messages to the class.
|
||
|
|
|
||
|
|
A method is a description of the operations necessary to implement a message for a particular class. The methods in a class tell how to implement messages sent to its instances.
|
||
|
|
A class contains a method definition for each message to which its instances respond. Methods generally fall into several categories. Some methods inquire about some property of the receiver.
|
||
|
|
Others ask the receiver to make some change to its internal state. Still others may ask the receiver to return some computed value.
|
||
|
|
|
||
|
|
See link::Reference/Classes:: for more details about instance and class variables and methods.
|
||
|
|
|
||
|
|
@section{section}
|
||
|
|
Summary of Terminology
|
||
|
|
@section{definitionlist}
|
||
|
|
|
||
|
|
## object || something that has data, representing the object's state, and a set of operations that can be performed on the object.
|
||
|
|
## message || a request for an object to perform an operation.
|
||
|
|
## receiver || the object to which a message is sent.
|
||
|
|
## class || a description of the state and behaviour of a set of objects.
|
||
|
|
## interface || the set of messages to which an object responds.
|
||
|
|
## protocol || a set of messages that implement a specific kind of behaviour.
|
||
|
|
## polymorphism || the ability for different kinds of objects to respond differently to the same message.
|
||
|
|
## method || a description of the operations necessary to implement a message for a particular class.
|
||
|
|
## instance || one of the objects described by a class.
|
||
|
|
## instance variable || a part of an object's internal state
|
||
|
|
::
|
||
|
|
|
||
|
|
|
||
|
|
|