Chapter 3: What is Object-Oriented Programming?
Object-oriented programming (or OOP) is a paradigm or pattern of programming whereby the solution to a programming problem is modelled as a collection of collaborating objects. Objects collaborate by sending messages to each other. It is most suitable for managing large, complex problems.
An object is an entity that possesses both state (or properties or attributes) and behaviour. Put another way, an object encapsulates data and the functions that operate on that data. The data is usually hidden from other objects so that the only way to affect the data is through the object’s functions (or methods).
An example of an object is a car. A car has attributes (e.g., colour, size, weight, fuel capacity, number of passengers, etc.). A car has behaviour represented by its methods (e.g., start engine, turn left/right, accelerate, stop, turn on wipers, etc.).
A class is a special kind of object that’s used as a template for creating instances of itself. Think of it like a cookie cutter that produces cookies (or objects).
A class can inherit the attributes and behaviour of another class (its parent), and it can modify or customize that behaviour (i.e., its methods) for itself. This leads to the concept of polymorphism. Polymorphism means that when an object receives a message, the correct method is called, based on the object’s class. That method may belong to the parent, or it may be one that is customized for this class.
Here’s an example of polymorphism:
Smalltalk allows a class to inherit from only one class. Some OOP languages allow a class to inherit from several classes; this is known as multiple inheritance. Multiple inheritance causes a great deal of complexity, which is why it is generally avoided. We shall not speak of multiple inheritance again.
While inheritance is an important aspect of OOP, it is not the only way to build up programs. Instead of inheritance, composition or aggregation can be used. A class may include instances of other classes without inheriting anything. It’s a “has a” relationship as in: Class A has a Class B instance as a member. If you used inheritance, then Class B would be a kind of Class A object; this is an “is a kind of” relationship. Let’s illustrate this with examples…
A car is a kind of motorized vehicle (the parent class). So is a motorcycle. So is a motor boat. So is an aircraft. Each of these can inherit the attributes and behaviour of a motorized vehicle. But they can also customize the attributes and methods of the parent class for themselves.
A car has other objects or classes as part of itself, such as an engine, wheels, steering wheel, etc. It does not inherit anything from these classes.
Syntactically, the attributes of an object (the object’s data) are represented by instance variables. Typically, you will create “getter” methods (get the value of an instance variable) and “setter” methods (set or modify the value of an instance variable) for them, since instance variables are hidden from the outside world.
In Pharo, instance variables are created in the class definition, for example:
Magnitude subclass: #Time
instanceVariableNames: 'seconds nanos'
classVariableNames: ''
poolDictionaries: 'ChronologyConstants'
package: 'Kernel-Chronology'In the #Time class (the hash in #Time designates Time as a Smalltalk symbol), there are two instance variables: ‘seconds’ and ‘nanos’. The object’s methods will operate on these variables, which represent the hidden and internal state of the object.
By the way, the #Time class derives from, or inherits from, the #Magnitude class. Alternatively, you can say the Magnitude class “subclasses” the Time class. This is typical Smalltalk parlance.
An object resembles the conventional module concept that is used in simpler procedural programming languages like C and Pascal. A module contains a data structure and the functions that operate on the structure. The data, however, is not hidden; anybody can access the data. Most importantly, modules cannot inherit from other modules.
Objects are usually much finer-grained than modules. Thus, they are ideal for modelling complex systems.
So that’s it. That’s your introduction to Object-Oriented Programming. If you want to study this interesting subject in greater depth, there is a wealth of books and material dedicated to OOP and Smalltalk, for example:
