Smalltalk Object Model

Nyquist / XLISP 2.0 - Contents | Tutorials | Examples | Reference

# The Smalltalk Object Model

This page is based on a document written by Glenn Hollowell:

- http://www.objs.com/x3h7/smalltalk.htm

The original document has been adapted for use with the XLISP 2.0 object system.

## 1 Basic Concepts

Within the context of Smalltalk, objects are implemented in code through encapsulation and polymorphism.

Encapsulation is the approach used in Smalltalk to bundle everything needed into an object to preserve the integrity of the enclosed data. The code within an object performs operations on the objects internal data. Operations in Smalltalk are performed as the result of a messages being sent to an object to execute a specific portion of its code, usually called a 'method'.

Polymorphism is the way that the Smalltalk language allows methods of the same name to have predictable and meaningful results in related instances, yet perform the operations differently to achieve the results.

Polymorphism is typically implemented in Smalltalk through the abstraction of the common properties of a group of objects into classes and hierarchically subclassing shared properties using inheritance, along with specialization of the subclass to define the differences.

Classes serve as templates because they define the instance variables for all the class instance variables and methods. The instance of a class is created by sending a :new message to the class which uniquely identifies the object instance and allocates space for its variables.

Back to top

## 2 Objects

An object is an encapsulated software component made up of memory and operations that creates a coherent programming entity. All objects are an instance of a class. Objects have public and private properties. An object's implementation details are private and are hidden from other objects.

- An object's public properties are its messages that make up its interface.

- The object's private properties are its variables.

Interaction with an object only occurs via these messages to its interface. All object instances of a given class have a common message interface.

Back to top

## 2.1 Operations

An operation is the action taken by an object instance as result of a message being received through the object's interface. Messages requesting operations are addressed to specific recipient object instances, thus Smalltalk uses the 'classical' object model and the method to execute in response to a message is determined by searching the object's class hierarchy.

Back to top

## 2.2 Requests

A request is act of sending a message to an object's interface with the expectation that the object will perform a known operation that is associated with the message.

Back to top

## 2.3 Messages

A message is a request to an object instance to perform an operation. A message expression consists of a receiver, selector [message name], and potentially some arguments. The selector must be mapped to a method of the same name, encapsulated in the receiver object's class hierarchy. The arguments, if any, are used by the method to perform its operation.

    (send receiver :selector [arguments])

In Smalltalk there exist several message types, like unary, binary, and keyword messages. In XLISP there is only one message type, so the description of the Smalltalk message types has been omitted from this document.

Back to top

## 2.4 Specification of Behavioral Semantics

Behavior is defined by methods specified in classes which are implemented as class instances and execution is triggered in those instances by message requests.

Back to top

## 2.5 Methods

A method is the executable code rendered in the class and executed in the context of an object instance. It defines how to perform an operation in the object instance. It is made up of a message pattern that is used to match against incoming messages, temporary variables, and a sequence of instructions. A method execution is triggered when message is received that matches the methods' message pattern.

Back to top

## 2.6 State

The state of an instance is represented by the values of its instance variables.

Back to top

## 2.7 Object Lifetime

Object instances are created with the :new method. Each object instance is given a unique identifier called an object pointer or object reference.

New classes are created by using the "subclass" method. The "new" and "subclass" methods are inheritedby almost all classes. Every instance object pointer is also associated with an object pointer of a class. Unlike the "new" and "subclass" methods, there are no specific methods that remove an object that is no longer useful. Smalltalk objects are deleted when they are no longer reachable (garbage collected).

Back to top

## 2.8 Behavior/State Grouping

Smalltalk uses the 'classical' object model.

Back to top

## 2.9 Communication Model

All communications within Smalltalk occur through messages between objects and most Smalltalk implementations support a form of concurrency. For example, Smalltalk-80 provides for multiple independent processes, and semaphores provide the common mechanism for synchronizing the independent processes.

Back to top

## 2.10 Events

No specific mechanisms for handling events are built into the Smalltalk language, but "event handling" logic is commonly implemented in Smalltalk applications through its normal messaging techniques.

Back to top

## 4 Polymorphism

Polymorphism is the way that the Smalltalk language allows methods of same name to have predictable and meaningful results in related instances, yet perform the operations differently to achieve similar results.

Smalltalk supports polymorphism by allowing methods defined in classes to be overridden with methods of the same name, but different logic, in a subsequent subclass. In addition, methods of the same name can be defined in a total different subclass hierarchy.

In the class hierarchy below, all of the lowest level classes are defined to accept the message 'moveForward' (mFabstract), but several different versions are implemented as indicated by (MFn) in the diagram. The message sent to the instances of 'Bus' or 'Auto' uses the method defined in the 'Motorized' class. The same method is inherited by 'Train' and 'Motorcycle', but both have overridden the inherited method by defining a method with different logic using the same message pattern. All the others instances in the diagram have the 'moveForward' message pattern in their interface, but are not in the 'Motorized' inheritance chain. All of the 'moveForward' (mFabstract) methods function as you intuitively expect.

                         Transport Mechanism  (mFabstract)
           /---------------       |        -------------------\
    Animal Powered          Human Powered                  Motorized
      /  (mF1)  \         /               \               /  (mF5)  \
    Buggy      Wagon  Land-based      Water-based    Public       Private
                       /     \         / (mF4) \     /    \        /   \
                     Bike  Skates  Row Boat  Canoe  Bus  Train  Auto  Motorcycle
                    (mF2)   (mF3)                        (mF6)          (mF7)

Back to top

## 5 Encapsulation

The approach used in Smalltalk is to encapsulate all objects, whether a complex as a sorted list or as simple as a string, into a single programming entity that includes data and logic. Further, other objects can not invoke the encapsulated data or logic. In order to interact, other objects must send messages to an object's interface that will cause the object to perform a function that will have a known effect. See also entry under 2.3 Messages.

Back to top

## 6 Identity, Equality, Copy

Smalltalk provides unique identity for all objects. Objects can be tested for equivalence (Are the objects being compared the same object?) and equality (every object may implement its own definition of equality).

Copying of objects can be performed as a deep copy (object's structure and the objects pointed to by its variables are copied) or shallow copy (objects pointed to by variables, their variables are not copied, but are shared with the original object).

XLISP does not provide build-in functions or methods to compare or to copy objects.

Back to top

## 7 Types and Classes

Smalltalk does not have a separate notion of 'type' [message protocol shared by a group of objects] apart from 'class'.

A class is a group of objects that represent the same type of entity and share the same methods. A class describes the implementation of a set of similar objects. Classes are themselves objects. All objects belong to some class and an object is an instance of the class of which it belongs.

XLISP: If an object is a member of a class can be tested by sending an :isa message.

Back to top

## 8 Inheritance and Delegation

Smalltalk class relationships are defined in terms of inheritance. The properties of one class are be inherited from another class in a hierarchical structure beginning with the upper-most class object. In inheritance, the inheriting class is called the 'subclass' and the class being inherited from is call the 'superclass'. A subclass inherits all of its superclass' variables and methods.

Abstract classes are classes from which other classes are inherited (subclassed) only. Instances can be implemented any non-abstract class.

Subclasses are specialization of their superclasses. A subclass may add variables, but it cannot delete those inherited from the superclass. A subclass may accept an inherited method or it may override the method by providing an new method with the same name (or message selector).

Object instances are instances of a class. Smalltalk does not provide for delegation (defined as object instances being created from other object instances and not a class).

Back to top

Nyquist / XLISP 2.0 - Contents | Tutorials | Examples | Reference