# Smalltalk and Object Orientation: An Introduction

John Hunt

► To cite this version:

John Hunt. Smalltalk and Object Orientation: An Introduction. 1997. hal-05188192

HAL Id: hal-05188192

https://inria.hal.science/hal-05188192v1

Submitted on 26 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_2.png" /></figure>

# Smalltalk and Object Orientation:

## An Introduction

John Hunt

JayDee Technology Ltd,
Hartham Park
Corsham,
Wiltshire, SN13 0RP
United Kingdom

Email: john.hunt@jaydeetechnology.co.uk
http://www.jaydeetechnology.co.uk
# Preface

This book was originally written to support an introductory course in Object Orientation through the medium of Smalltalk (and VisualWorks in particular). However, it can be used as a book to teach the reader Smalltalk, to introduce object orientation as well as present object oriented design and analysis.

It takes as its basic premise that most Computer Scientists / Software Engineers learn best by doing rather than from theoretical notes. The chapters therefore attempt to introduce concepts by getting you the reader to do things, rather than by extensive theoretical discussions. This means that these chapters take a hands-on approach to the subject and assume that the student/reader has a suitable Smalltalk environment available to them.

The chapters are listed below and are divided into six parts. The reader is advised to work through Parts 1 and 3 thoroughly in order to gain a detailed understanding of object orientation. Part 2 then provides an introduction to the Smalltalk environment and language. Other chapters may then be dipped into as required. For example, if the reader wishes to hone their Smalltalk skills then the chapters in Part 4 would be useful. However, if at that point they wish to get on and discover thedelights of graphical user interfaces in Smalltalk, then Part 5 could be read next. Part 6 presents some more advances subjects such as metaclasses and concurrency which are not required for straight forward Smalltalk development.

# Content Summary

## Part 1: Introduction to Object Orientation

### Chapter 1: Introduction to Object Orientation

The aim of this chapter is to provide an introduction to the range of concepts and ideas which make up object technology. It presents the background which led to the acceptance of object orientation as a mainstream technology and discusses the pedigree of the Smalltalk language.

### Chapter 2: Elements of Object Orientation

This chapter provides a more formal definition of the terminology introduced in Chapter 1. It also considers the advantages and disadvantages of an object oriented approach compared to more traditional procedural approaches.

### Chapter 3: Constructing an Object Oriented System

A typical problem for many people when being introduced to a new approach is that they understand the terminology and the concepts but not how to use them. This chapter aims to alleviate this problem by presenting a detailed worked example of the way in which an object oriented system may be designed and constructed. It does so without reference to any particular language so that language issues should not confuse the discussion.

## Part 2: The Smalltalk Language

### Chapter 4: An Introduction to Smalltalk

The aim of this chapter is to provide some background on the history of Smalltalk and the development environments which are available to support it (such as the VisualWorks system). It also considers some of the tools the reader will encounter.

### Chapter 5: A Little Smalltalk

This chapter presents a number of other tools such as the inspectors and debuggers available in VisualWorks. It then uses a worked example to help the user to use some of the development tools available.

### Chapter 6: Smalltalk Building Blocks

The chapter introduces the basic elements the Smalltalk language, it discusses the concept of classes in Smalltalk and how they are defined.
### Chapter 7: Smalltalk Constructs

This chapter presents further details of the Smalltalk language including the representation and use of numbers, strings and characters.

### Chapter 8: An Example Smalltalk Class

In Chapter 7, the reader is presented with a detailed worked example of software development in Smalltalk. This example presents a very simple class definition which uses only those concepts which have been introduced at this stage. The intention is to illustrate how the constructs and language elements can be combined in a real (if simple) program.

### Chapter 9: Control and Iteration

This chapter introduces how control and iteration are achieved in Smalltalk. To do this a number of concepts which are unique to Smalltalk are also discussed (such as the block object). To simplify this process for the reader, equivalent C constructs are illustrated beside Smalltalk constructs (where they exist).

### Chapter 10: The Collection Classes

This chapter discusses properly the most widely used class hierarchy in Smalltalk; the collection class hierarchy. It presents the hierarchy in general and some of the commonly used collection classes. It also illustrates how these classes can be used to construct other collection style classes such as queues and stacks.

### Chapter 11: Further Collection Classes

This chapter concludes the examination of the collection classes available in Smalltalk and presents an application constructed using these classes.

### Chapter 12: An Object Oriented Organizer

This chapter presents a detailed example application constructed using the collection classes. The Organizer is intended as an electronic personal Organizer. It therefore possesses an address book, a diary (or appointments section) and a section for notes. The remainder of this chapter describes one way of implementing such an Organizer.

### Chapter 13: Streams and Files

This chapter discusses the second most used class hierarchy in Smalltalk; the Stream classes. The Stream classes are used (amongst other things) for accessing files. The Binary Object Streaming Service for storing objects in files is also discussed.

### Chapter 14: The Magnitude Class Hierarchy

This chapter considers the magnitude class and those classes which inherit from it. This includes the Number hierarchy. The classes Character, Time and Date are also considered.

### Chapter 15: Some More Tools of the Trade

This chapter introduces the use of breakpoints in Smalltalk, the purpose of the change list file and how to file in and file out Smalltalk code.

## Part 3: Object Oriented Design

### Chapter 16: Object Oriented Analysis and Design

This chapter introduces the concepts of object oriented analysis and design. It reviews a number of the more popular techniques such as OOA, OMT, Objectory and Booch. It also briefly considers the unification of the OMT and Booch notations.

### Chapter 17: The Unified Modeling Language

The Unified Modeling Language (or UML for short) is a third generation object-oriented modeling language which adapts and extends the published notations used in the Booch, OMT and Objectory methods. It is intended that the UML will form a single, common, widely usable modeling language for
a range of object oriented design methods (including Booch, Objectory and OMT). It is also intended
that it should be applicable in a wide range of applications and domains. This chapter (and the next)
summarize the UML notation.

*Chapter 18: UML: Dynamic Modeling and Deployment*

This chapter continues the description of the Unified Modeling Lan guage (UML) started in the last chapter.

*Chapter 19: The Object Modeling Technique*

This chapter, and the next, discuss the influential design method referred to as the Object Modeling Technique (OMT). It summarizes the main phases of OMT using the UML not ation. One extension to OMT is the introduction of use case models from Objectory to improve the requirements analysis process. This is motivated by the inclusion of use case diagrams in the UML.

*Chapter 20: More Object Modeling Technique*

This chapter continues the description of the Object Modeling Technique (OMT).

*Chapter 21: Frameworks and Patterns for Object Oriented Design*

The aim of this chapter is to introduce the concept of frameworks and in particular patterns. This is still a relatively new idea within Object Orientation, but one which is growing in popularity at an incredible rate.

Part 4: Testing and Style

Chapter 22: Testing Object Oriented Systems

Object oriented systems may make code easier to reuse and may be supported by object oriented
analysis and design methods, but they do not guarantee that the code is correct. This chapter looks at
some of the issues behind testing object oriented systems.

Chapter 23: Method and Class Testing

The last chapter discussed the problems facing the test er of an object oriented system (and in particular
a Smalltalk system). This chapter considers current best practice in testing object oriented systems.

Chapter 24: Smalltalk Style Guidelines

The aim of this chapter is the promotion of readable, understan dable, concise and efficient Smalltalk
code. A point to note is that style guidelines for languages such as Pascal do not cover many of the
issues which are important in Smalltalk. As in any programming language there are a number of
acknowledged bad pract ices which are not specific to Smalltalk, for example the use of global
variables! Such guidelines are familiar to programmers of most languages. This section will therefore
try to concentrate on those style issues which are specific to Smalltalk.

**Part 5: Graphical Interfaces in Smalltalk**

*Chapter 25: The Perform and Dependency Mechanisms*

In this chapter the use of perform to provide an alternative method for sending messages is considered.
This is followed by a practical discussion of the dependency mecha nism. This includes what the
dependency mechanism is, why you might want to use, how you construct a dependency and the effect
that it has.

Chapter 26: The ModeView-Controller Architecture

The Mode-View-Controller (or MVC) architecture is the basis upowhich user interfaces are constructed in Smalltalk. The architecture separates out the application from the user interface. This chapter introduces the MVC architecture and explains the motivation behind it. A worked example is presented to illustrate the theoretical description.

Chapter 27: Graphic User Interface Construction Tools
The user interface construction facilities in Smalltalk are subject to the widest variation between dialects of any aspect of the language. This chapter concentrates on the facilities provided by the user interface building facilities in VisualWorks.

### Chapter 28: A Visual Organizer

This chapter describes a detailed worked example of how a user interface can be constructed for the Organizer application constructed earlier in the book.

### Chapter 29: Using a View Within a Window

This chapter explains how to use MVC applications within a VisualWorks window. It is useful to be able to do this as not all user interfaces can be accommodated directly by the user interface builder in VisualWorks.

## Part 6: Further Smalltalk

### Chapter 30: Memory Management and Garbage Collection

This chapter considers why automatic memory management is desirable. It also discusses how Smalltalk's memory is structured and the garbage collection strategies used. It concludes by considering how to force VisualWorks to place long term objects in the most appropriate region of memory.

### Chapter 31: Concurrency in Smalltalk

This chapter presents and explains a short example of how time slicing can be accomplished while Smalltalk.

### Chapter 32: The Metaclass Framework

The aim of this chapter is to discuss the concept of classes, what they actually are, what they are really used for and why they are important. To do this it introduces the concept of a metaclass and considers how they are used to provide inheritance and the creation of instances. It also discusses whether it is important for the Smalltalk programmer to be aware of the existence of the metaclass.

## Part 7: The Future

### Chapter 33: The Future for Object Technology

This chapter brings the many threads in this book together and considers the future of object oriented systems.

## Appendix

### Appendix A: The Smalltalk Language Syntax
# Obtaining Source Code Examples

The source code for the examples in this book is a
http://www.jaydeetechnology.co.uk/books.htm/

vailable on the web at URL:

# Typographical Conventions

In this book the standard typeface is Times, however *courier* is used to identify source code. For example, $a := 2 + 3$.

# Trademarks

ParcPlace, VisualWorks, Smalltalk -80, Smalltalk/V are registered trademarks, and BOSS is a trademark, of ParcPlace-Digitalk Systems, Inc. Sun and Java are trademarks of Sun Microsystems, Inc. MS-Windows and Windows 95 are registered trademarks of Microsoft Corporation. Apple is a registered trademark of Apple Computer, Inc. UNIX is a registered trademark of AT&T. The X Window System is a trademark of the Massachusetts Institute of Technology. All other brand names are trademarks of their respective holders.

# Acknowledgments

The content of this book has been refined by a large number of students in both academia and industry. Many of these people have provided useful feedback and constructive comments. A number of them have actively suggested topic areas which might be covered or which were poorly described; thank you all for your interest. In particular thanks to Peter Holland, Paul Jones, Dave James, John Counsell, Clive King, Andy Whittle and others who I am sure I have forgotten to mention. I would also like to thank Rebecca Moore, of Springer-Verlag, for her patience and thoroughness during the preparation of this book. Finally, thanks to my wife, Denise Cooke, for suffering my disappearances to the study most evenings to work on "the book" and for helping with my many "printing" problems.
# Preface

## 1. INTRODUCTION TO OBJECT ORIENTATION..................................................................................15

<table><tr><td>1.1</td><td>INTRODUCTION</td><td>15</td></tr><tr><td>1.2</td><td>PROGRAMMING PARADIGMS</td><td>15</td></tr><tr><td>1.3</td><td>REVOLUTION VERSUS EVOLUTION</td><td>16</td></tr><tr><td>1.4</td><td>HISTORY /PEDIGREE OF OBJECT ORIENTED LANGUAGES</td><td>17</td></tr><tr><td>1.5</td><td>FUNDAMENTALS OF OBJECT ORIENTATION</td><td>18</td></tr><tr><td>1.6</td><td>THE FOUR CATECHISM OF OBJECT ORIENTATION</td><td>18</td></tr><tr><td>1.7</td><td>ENCAPSULATION</td><td>19</td></tr><tr><td>1.8</td><td>INHERITANCE</td><td>20</td></tr><tr><td>1.9</td><td>ABSTRACTION</td><td>22</td></tr><tr><td>1.10</td><td>POLYMORPHISM</td><td>22</td></tr><tr><td>1.11</td><td>SUMMARY</td><td>23</td></tr><tr><td>1.12</td><td>FURTHER READING</td><td>24</td></tr></table>

## 2. ELEMENTS OF OBJECT ORIENTATION ................................................................................................25

<table><tr><td>2.1</td><td>INTRODUCTION</td><td>25</td></tr><tr><td>2.2</td><td>TERMINOLOGY</td><td>25</td></tr><tr><td>2.3</td><td>TYPES OF HIERARCHIES IN OBJECT ORIENTATION</td><td>26</td></tr><tr><td>2.4</td><td>WHY BOTHER?</td><td>28</td></tr><tr><td>2.5</td><td>THE MOVE TO OBJECT TECHNOLOGY</td><td>32</td></tr><tr><td>2.6</td><td>SUMMARY</td><td>32</td></tr><tr><td>2.7</td><td>EXERCISES</td><td>33</td></tr><tr><td>2.8</td><td>FURTHER READING</td><td>33</td></tr></table>

## 3. CONSTRUCTING AN OBJECT ORIENTED SYSTEM ........................................................................34

<table><tr><td>3.1</td><td>INTRODUCTION</td><td>34</td></tr><tr><td>3.2</td><td>THE APPLICATION: WINDSCREEN WIPE SIMULATION</td><td>34</td></tr><tr><td>3.3</td><td>WHERE DO WE START?</td><td>35</td></tr><tr><td>3.4</td><td>IDENTIFYING THE OBJECTS</td><td>35</td></tr><tr><td>3.5</td><td>IDENTIFYING THE SERVICES/METHODS</td><td>36</td></tr><tr><td>3.6</td><td>REFINING THE OBJECTS</td><td>37</td></tr><tr><td>3.7</td><td>BRINGING IT ALL TOGETHER</td><td>37</td></tr><tr><td>3.8</td><td>SUMMARY</td><td>41</td></tr><tr><td>3.9</td><td>EXERCISES</td><td>41</td></tr><tr><td>3.10</td><td>FURTHER READING</td><td>41</td></tr></table>

## 4. AN INTRODUCTION TO SMALLTALK................................................................................................44

<table><tr><td>4.1</td><td>INTRODUCTION</td><td>44</td></tr><tr><td>4.2</td><td>WHAT IS SMALLTALK</td><td>44</td></tr><tr><td>4.3</td><td>OBJECTS IN SMALLTALK</td><td>45</td></tr><tr><td>4.4</td><td>HISTORY</td><td>45</td></tr><tr><td>4.5</td><td>THE SMALLTALK ENVIRONMENT</td><td>47</td></tr><tr><td>4.6</td><td>FURTHER READING</td><td>52</td></tr></table>

## 5. A LITTLE SMALLTALK................................................................................................................53

<table><tr><td>5.1</td><td>INTRODUCTION</td><td>53</td></tr><tr><td>5.2</td><td>THE WORKSPACE</td><td>53</td></tr><tr><td>5.3</td><td>INSPECTORS</td><td>54</td></tr><tr><td>5.4</td><td>NOTIFIERS</td><td>54</td></tr><tr><td>5.5</td><td>ERROR PROCESSING</td><td>55</td></tr><tr><td>5.6</td><td>SOME SMALLTALK</td><td>56</td></tr><tr><td>5.7</td><td>WORKING WITH SMALLTALK</td><td>57</td></tr><tr><td>5.8</td><td>SUMMARY</td><td>60</td></tr><tr><td>5.9</td><td>FURTHER READING</td><td>60</td></tr></table>

## 6. SMALLTALK BUILDING BLOCKS..................................................................................................61
<table>
  <tbody>
    <tr>
      <td>6.1</td>
      <td>INTRODUCTION</td>
      <td>61</td>
    </tr>
    <tr>
      <td>6.2</td>
      <td>THE BASICS OF THE LANGUAGE</td>
      <td>61</td>
    </tr>
    <tr>
      <td>6.3</td>
      <td>CLASSES</td>
      <td>62</td>
    </tr>
    <tr>
      <td>6.4</td>
      <td>METHOD DEFINITIONS</td>
      <td>66</td>
    </tr>
    <tr>
      <td>7.</td>
      <td>SMALLTALK CONSTRUCTS</td>
      <td>69</td>
    </tr>
    <tr>
      <td>7.1</td>
      <td>INTRODUCTION</td>
      <td>69</td>
    </tr>
    <tr>
      <td>7.2</td>
      <td>NUMBERS AND OPERATORS</td>
      <td>69</td>
    </tr>
    <tr>
      <td>7.3</td>
      <td>CHARACTERS AND STRINGS</td>
      <td>70</td>
    </tr>
    <tr>
      <td>7.4</td>
      <td>ASSIGNMENTS</td>
      <td>71</td>
    </tr>
    <tr>
      <td>7.5</td>
      <td>VARIABLES</td>
      <td>71</td>
    </tr>
    <tr>
      <td>7.6</td>
      <td>MESSAGES AND MESSAGE SELECTORS</td>
      <td>73</td>
    </tr>
    <tr>
      <td>7.7</td>
      <td>SUMMARY</td>
      <td>75</td>
    </tr>
    <tr>
      <td>7.8</td>
      <td>FURTHER READING</td>
      <td>75</td>
    </tr>
    <tr>
      <td>8.</td>
      <td>AN EXAMPLE SMALLTALK CLASS</td>
      <td>76</td>
    </tr>
    <tr>
      <td>8.1</td>
      <td>INTRODUCTION</td>
      <td>76</td>
    </tr>
    <tr>
      <td>8.2</td>
      <td>THE CLASS PERSON</td>
      <td>76</td>
    </tr>
    <tr>
      <td>8.3</td>
      <td>DEFINING METHODS</td>
      <td>77</td>
    </tr>
    <tr>
      <td>8.4</td>
      <td>CREATING AN INSTANCE</td>
      <td>80</td>
    </tr>
    <tr>
      <td>9.</td>
      <td>CONTROL AND ITERATION</td>
      <td>81</td>
    </tr>
    <tr>
      <td>9.1</td>
      <td>INTRODUCTION</td>
      <td>81</td>
    </tr>
    <tr>
      <td>9.2</td>
      <td>CASCADING</td>
      <td>81</td>
    </tr>
    <tr>
      <td>9.3</td>
      <td>BLOCKS</td>
      <td>81</td>
    </tr>
    <tr>
      <td>9.4</td>
      <td>CONTROL STRUCTURES</td>
      <td>83</td>
    </tr>
    <tr>
      <td>9.5</td>
      <td>SUMMARY</td>
      <td>86</td>
    </tr>
    <tr>
      <td>9.6</td>
      <td>FURTHER READING</td>
      <td>86</td>
    </tr>
    <tr>
      <td>10.</td>
      <td>THE COLLECTION CLASSES</td>
      <td>86</td>
    </tr>
    <tr>
      <td>10.1</td>
      <td>INTRODUCTION</td>
      <td>86</td>
    </tr>
    <tr>
      <td>10.2</td>
      <td>THE COLLECTION CLASS HIERARCHY</td>
      <td>87</td>
    </tr>
    <tr>
      <td>10.3</td>
      <td>CHOOSING A COLLECTION CLASS</td>
      <td>88</td>
    </tr>
    <tr>
      <td>10.4</td>
      <td>THE COLLECTION CLASS</td>
      <td>88</td>
    </tr>
    <tr>
      <td>10.5</td>
      <td>BAG</td>
      <td>89</td>
    </tr>
    <tr>
      <td>10.6</td>
      <td>SET</td>
      <td>90</td>
    </tr>
    <tr>
      <td>10.7</td>
      <td>ORDEREDCOLLECTION</td>
      <td>91</td>
    </tr>
    <tr>
      <td>10.8</td>
      <td>STACK AND QUEUE CLASSES IN SMALLTALK</td>
      <td>92</td>
    </tr>
    <tr>
      <td>10.9</td>
      <td>SUMMARY</td>
      <td>94</td>
    </tr>
    <tr>
      <td>10.10</td>
      <td>FURTHER READING</td>
      <td>94</td>
    </tr>
    <tr>
      <td>11.</td>
      <td>FURTHER COLLECTION CLASSES</td>
      <td>95</td>
    </tr>
    <tr>
      <td>11.1</td>
      <td>INTRODUCTION</td>
      <td>95</td>
    </tr>
    <tr>
      <td>11.2</td>
      <td>SORTEDCOLLECTION</td>
      <td>95</td>
    </tr>
    <tr>
      <td>11.3</td>
      <td>LIST</td>
      <td>96</td>
    </tr>
    <tr>
      <td>11.4</td>
      <td>INTERVALS</td>
      <td>96</td>
    </tr>
    <tr>
      <td>11.5</td>
      <td>ARRAY</td>
      <td>97</td>
    </tr>
    <tr>
      <td>11.6</td>
      <td>MULTI DIMENSIONAL ARRAYS</td>
      <td>97</td>
    </tr>
    <tr>
      <td>11.7</td>
      <td>DICTIONARIES</td>
      <td>98</td>
    </tr>
    <tr>
      <td>11.8</td>
      <td>STRINGS</td>
      <td>99</td>
    </tr>
    <tr>
      <td>11.9</td>
      <td>ITERATING OVER COLLECTIONS</td>
      <td>100</td>
    </tr>
    <tr>
      <td>11.10</td>
      <td>INSERTING INTO A COLLECTION</td>
      <td>101</td>
    </tr>
    <tr>
      <td>11.11</td>
      <td>CONVERSION</td>
      <td>102</td>
    </tr>
    <tr>
      <td>12.</td>
      <td>AN OBJECT ORIENTED ORGANIZER</td>
      <td>104</td>
    </tr>
    <tr>
      <td>12.1</td>
      <td>INTRODUCTION</td>
      <td>104</td>
    </tr>
    <tr>
      <td>12.2</td>
      <td>THE ORGANIZER</td>
      <td>104</td>
    </tr>
    <tr>
      <td>12.3</td>
      <td>THE CLASS DEFINITION</td>
      <td>104</td>
    </tr>
    <tr>
      <td>12.4</td>
      <td>THE INITIALIZE-RELEASE PROTOCOL</td>
      <td>105</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>12.5</td>
      <td>A CLASS SIDE METHOD</td>
      <td>106</td>
    </tr>
    <tr>
      <td>12.6</td>
      <td>THE PRIVATE-UPDATING PROTOCOL</td>
      <td>107</td>
    </tr>
    <tr>
      <td>12.7</td>
      <td>THE ACCESSING PROTOCOL</td>
      <td>107</td>
    </tr>
    <tr>
      <td>12.8</td>
      <td>THE FINANCIAL MANAGER PROJECT</td>
      <td>109</td>
    </tr>
    <tr>
      <td>13.</td>
      <td>STREAMS AND FILES</td>
      <td>111</td>
    </tr>
    <tr>
      <td>13.1</td>
      <td>INTRODUCTION</td>
      <td>111</td>
    </tr>
    <tr>
      <td>13.2</td>
      <td>STREAMS</td>
      <td>111</td>
    </tr>
    <tr>
      <td>13.3</td>
      <td>ASCII FILES</td>
      <td>112</td>
    </tr>
    <tr>
      <td>13.4</td>
      <td>THE BINARY OBJECT STREAMING SERVICE</td>
      <td>114</td>
    </tr>
    <tr>
      <td>13.5</td>
      <td>USING FILES WITH THE FINANCIAL MANAGER</td>
      <td>116</td>
    </tr>
    <tr>
      <td>13.6</td>
      <td>SUMMARY</td>
      <td>117</td>
    </tr>
    <tr>
      <td>14.</td>
      <td>THE MAGNITUDE CLASS HIERARCHY</td>
      <td>118</td>
    </tr>
    <tr>
      <td>14.1</td>
      <td>INTRODUCTION</td>
      <td>118</td>
    </tr>
    <tr>
      <td>14.2</td>
      <td>THE CLASS MAGNITUDE</td>
      <td>118</td>
    </tr>
    <tr>
      <td>14.3</td>
      <td>THE CLASS DATE</td>
      <td>119</td>
    </tr>
    <tr>
      <td>14.4</td>
      <td>THE CLASS TIME</td>
      <td>119</td>
    </tr>
    <tr>
      <td>14.5</td>
      <td>THE CLASS CHARACTER</td>
      <td>120</td>
    </tr>
    <tr>
      <td>14.6</td>
      <td>FURTHER READING</td>
      <td>121</td>
    </tr>
    <tr>
      <td>15.</td>
      <td>SOME MORE TOOLS OF THE TRADE</td>
      <td>122</td>
    </tr>
    <tr>
      <td>15.1</td>
      <td>INTRODUCTION</td>
      <td>122</td>
    </tr>
    <tr>
      <td>15.2</td>
      <td>ERRORS AND BREAKPOINTS</td>
      <td>122</td>
    </tr>
    <tr>
      <td>15.3</td>
      <td>FILE IN/FILE OUTS</td>
      <td>123</td>
    </tr>
    <tr>
      <td>15.4</td>
      <td>CHANGE LIST</td>
      <td>125</td>
    </tr>
    <tr>
      <td>15.5</td>
      <td>WORKING WITH PROJECTS</td>
      <td>126</td>
    </tr>
    <tr>
      <td>15.6</td>
      <td>SUMMARY</td>
      <td>128</td>
    </tr>
    <tr>
      <td>16.</td>
      <td>OBJECT ORIENTED ANALYSIS AND DESIGN</td>
      <td>131</td>
    </tr>
    <tr>
      <td>16.1</td>
      <td>INTRODUCTION</td>
      <td>131</td>
    </tr>
    <tr>
      <td>16.2</td>
      <td>THE UNIFIED MODELING LANGUAGE</td>
      <td>131</td>
    </tr>
    <tr>
      <td>16.3</td>
      <td>OBJECT ORIENTED DESIGN METHODS</td>
      <td>131</td>
    </tr>
    <tr>
      <td>16.4</td>
      <td>OBJECT ORIENTED ANALYSIS</td>
      <td>132</td>
    </tr>
    <tr>
      <td>16.5</td>
      <td>THE BOOCH METHOD</td>
      <td>132</td>
    </tr>
    <tr>
      <td>16.6</td>
      <td>THE OBJECT MODELING TECHNIQUE</td>
      <td>133</td>
    </tr>
    <tr>
      <td>16.7</td>
      <td>THE OBJECTORY METHOD</td>
      <td>134</td>
    </tr>
    <tr>
      <td>16.8</td>
      <td>THE FUSION METHOD</td>
      <td>135</td>
    </tr>
    <tr>
      <td>16.9</td>
      <td>SUMMARY</td>
      <td>136</td>
    </tr>
    <tr>
      <td>17.</td>
      <td>THE UNIFIED MODELING LANGUAGE</td>
      <td>137</td>
    </tr>
    <tr>
      <td>17.1</td>
      <td>INTRODUCTION</td>
      <td>137</td>
    </tr>
    <tr>
      <td>17.2</td>
      <td>THE UML INFRASTRUCTURE</td>
      <td>138</td>
    </tr>
    <tr>
      <td>17.3</td>
      <td>USE CASE DIAGRAMS</td>
      <td>139</td>
    </tr>
    <tr>
      <td>17.4</td>
      <td>THE OBJECT MODEL</td>
      <td>139</td>
    </tr>
    <tr>
      <td>17.5</td>
      <td>PACKAGES</td>
      <td>145</td>
    </tr>
    <tr>
      <td>18.</td>
      <td>UML: DYNAMIC MODELING AND DEPLOYMENT</td>
      <td>147</td>
    </tr>
    <tr>
      <td>18.1</td>
      <td>INTRODUCTION</td>
      <td>147</td>
    </tr>
    <tr>
      <td>18.2</td>
      <td>DYNAMIC MODELING FACILITIES</td>
      <td>147</td>
    </tr>
    <tr>
      <td>18.3</td>
      <td>DEPLOYMENT DIAGRAMS</td>
      <td>152</td>
    </tr>
    <tr>
      <td>18.4</td>
      <td>SUMMARY</td>
      <td>153</td>
    </tr>
    <tr>
      <td>19.</td>
      <td>THE OBJECT MODELING TECHNIQUE</td>
      <td>154</td>
    </tr>
    <tr>
      <td>19.1</td>
      <td>INTRODUCTION</td>
      <td>154</td>
    </tr>
    <tr>
      <td>19.2</td>
      <td>THE OMT METHODOLOGY</td>
      <td>154</td>
    </tr>
    <tr>
      <td>19.3</td>
      <td>ANALYSIS PHASE</td>
      <td>154</td>
    </tr>
    <tr>
      <td>20.</td>
      <td>MORE OBJECT MODELING TECHNIQUE</td>
      <td>162</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>20.1 INTRODUCTION</td>
      <td>162</td>
    </tr>
    <tr>
      <td>20.2 DYNAMIC MODELS</td>
      <td>162</td>
    </tr>
    <tr>
      <td>20.3 DESIGN PHASE</td>
      <td>166</td>
    </tr>
    <tr>
      <td>20.4 IMPLEMENTATION PHASE</td>
      <td>169</td>
    </tr>
    <tr>
      <td>20.5 SUMMARY</td>
      <td>170</td>
    </tr>
    <tr>
      <td><b>21. FRAMEWORKS AND PATTERNS FOR OBJECT ORIENTED DESIGN</b></td>
      <td><b>171</b></td>
    </tr>
    <tr>
      <td>21.1 INTRODUCTION</td>
      <td>171</td>
    </tr>
    <tr>
      <td>21.2 PATTERNS AND FRAMEWORKS</td>
      <td>171</td>
    </tr>
    <tr>
      <td>21.3 AN INTRODUCTION TO HOTDRAW</td>
      <td>174</td>
    </tr>
    <tr>
      <td>21.4 WHERE DO YOU START?</td>
      <td>176</td>
    </tr>
    <tr>
      <td>21.5 BOXDRAWFIGURE</td>
      <td>177</td>
    </tr>
    <tr>
      <td>21.6 SUMMARY</td>
      <td>180</td>
    </tr>
    <tr>
      <td><b>22. TESTING OBJECT ORIENTED SYSTEMS</b></td>
      <td><b>182</b></td>
    </tr>
    <tr>
      <td>22.1 INTRODUCTION</td>
      <td>182</td>
    </tr>
    <tr>
      <td>22.2 WHY IS TESTING OBJECT ORIENTED SYSTEMS HARD?</td>
      <td>182</td>
    </tr>
    <tr>
      <td>22.3 INHERITANCE</td>
      <td>184</td>
    </tr>
    <tr>
      <td>22.4 ABSTRACT SUPERCLASSES</td>
      <td>185</td>
    </tr>
    <tr>
      <td>22.5 ENCAPSULATION</td>
      <td>185</td>
    </tr>
    <tr>
      <td>22.6 POLYMORPHISM</td>
      <td>187</td>
    </tr>
    <tr>
      <td>22.7 ADDITIONAL SMALLTALK SPECIFIC FEATURES</td>
      <td>188</td>
    </tr>
    <tr>
      <td>22.8 SUMMARY</td>
      <td>189</td>
    </tr>
    <tr>
      <td>22.9 FURTHER READING</td>
      <td>189</td>
    </tr>
    <tr>
      <td><b>23. METHOD AND CLASS TESTING</b></td>
      <td><b>190</b></td>
    </tr>
    <tr>
      <td>23.1 INTRODUCTION</td>
      <td>190</td>
    </tr>
    <tr>
      <td>23.2 OBJECT INTEGRATION TESTING</td>
      <td>192</td>
    </tr>
    <tr>
      <td>23.3 SYSTEM TESTING</td>
      <td>192</td>
    </tr>
    <tr>
      <td>23.4 SELF TESTING</td>
      <td>193</td>
    </tr>
    <tr>
      <td>23.5 SUMMARY</td>
      <td>193</td>
    </tr>
    <tr>
      <td>23.6 FURTHER READING</td>
      <td>193</td>
    </tr>
    <tr>
      <td><b>24. SMALLTALK STYLE GUIDELINES</b></td>
      <td><b>195</b></td>
    </tr>
    <tr>
      <td>24.1 INTRODUCTION</td>
      <td>195</td>
    </tr>
    <tr>
      <td>24.2 VARIABLES</td>
      <td>195</td>
    </tr>
    <tr>
      <td>24.3 CLASSES</td>
      <td>197</td>
    </tr>
    <tr>
      <td>24.4 METHODS</td>
      <td>200</td>
    </tr>
    <tr>
      <td>24.5 NAMING MESSAGE PROTOCOLS</td>
      <td>202</td>
    </tr>
    <tr>
      <td>24.6 FURTHER READING</td>
      <td>203</td>
    </tr>
    <tr>
      <td><b>25. THE PERFORM AND DEPENDENCY MECHANISMS</b></td>
      <td><b>205</b></td>
    </tr>
    <tr>
      <td>25.1 INTRODUCTION</td>
      <td>205</td>
    </tr>
    <tr>
      <td>25.2 THE PERFORM MECHANISM</td>
      <td>205</td>
    </tr>
    <tr>
      <td>25.3 THE DEPENDENCY MECHANISM</td>
      <td>206</td>
    </tr>
    <tr>
      <td>25.4 SUMMARY</td>
      <td>212</td>
    </tr>
    <tr>
      <td><b>26. THE MODEL-VIEW-CONTROLLER ARCHITECTURE</b></td>
      <td><b>213</b></td>
    </tr>
    <tr>
      <td>26.1 INTRODUCTION</td>
      <td>213</td>
    </tr>
    <tr>
      <td>26.2 THE MVC ARCHITECTURE PRINCIPLES</td>
      <td>213</td>
    </tr>
    <tr>
      <td>26.3 THE MVC WITH THE STATEMENT MODEL</td>
      <td>218</td>
    </tr>
    <tr>
      <td>26.4 VIEWS AND SUBVIEWS</td>
      <td>220</td>
    </tr>
    <tr>
      <td>26.5 THE CONTROLLER HIERARCHY</td>
      <td>221</td>
    </tr>
    <tr>
      <td>26.6 SUMMARY</td>
      <td>222</td>
    </tr>
    <tr>
      <td>26.7 FURTHER READING</td>
      <td>222</td>
    </tr>
    <tr>
      <td><b>27. GRAPHICAL USER INTERFACE CONSTRUCTION TOOLS</b></td>
      <td><b>223</b></td>
    </tr>
    <tr>
      <td>27.1 INTRODUCTION</td>
      <td>223</td>
    </tr>
    <tr>
      <td>27.2 WHAT IS A USER INTERFACE BUILDER?</td>
      <td>223</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>27.3 VISUALWORKS WINDOW PAINTING TOOLS</td>
      <td>224</td>
    </tr>
    <tr>
      <td>27.4 WINDOW SPECIFICATION AND CREATION</td>
      <td>226</td>
    </tr>
    <tr>
      <td>27.5 APPLICATION MODELS VERSUS DOMAIN MODELS</td>
      <td>227</td>
    </tr>
    <tr>
      <td>27.6 DEFINING A WINDOW'S FUNCTIONALITY</td>
      <td>228</td>
    </tr>
    <tr>
      <td>27.7 INITIALIZATION</td>
      <td>229</td>
    </tr>
    <tr>
      <td>27.8 RESOURCE FINDER</td>
      <td>230</td>
    </tr>
    <tr>
      <td>27.9 VALUEHOLDERS</td>
      <td>231</td>
    </tr>
    <tr>
      <td>27.10 THE ONCHANGESEND:TO: MESSAGE</td>
      <td>232</td>
    </tr>
    <tr>
      <td>27.11 VISUAL REUSE</td>
      <td>233</td>
    </tr>
    <tr>
      <td>27.12 METHOD OF WORKING WITH THE UI BUILDER</td>
      <td>234</td>
    </tr>
    <tr>
      <td>27.13 SUMMARY</td>
      <td>235</td>
    </tr>
    <tr>
      <td><b>28. A VISUAL ORGANIZER</b></td>
      <td><b>236</b></td>
    </tr>
    <tr>
      <td>28.1 INTRODUCTION</td>
      <td>236</td>
    </tr>
    <tr>
      <td>28.2 VISUALORGANIZER CLASS</td>
      <td>236</td>
    </tr>
    <tr>
      <td>28.3 THE ADDRESSBOOK CLASS</td>
      <td>239</td>
    </tr>
    <tr>
      <td>28.4 SUMMARY</td>
      <td>243</td>
    </tr>
    <tr>
      <td>28.5 THE VISUAL FINANCIAL MANAGER APPLICATION</td>
      <td>243</td>
    </tr>
    <tr>
      <td><b>29. USING A VIEW WITHIN A WINDOW</b></td>
      <td><b>244</b></td>
    </tr>
    <tr>
      <td>29.1 INTRODUCTION</td>
      <td>244</td>
    </tr>
    <tr>
      <td>29.2 THE CUSTOM VIEW WIDGET</td>
      <td>245</td>
    </tr>
    <tr>
      <td>29.3 THE STRUCTURE OF THE APPLICATION</td>
      <td>246</td>
    </tr>
    <tr>
      <td>29.4 THE INTERACTIONS BETWEEN OBJECTS</td>
      <td>247</td>
    </tr>
    <tr>
      <td>29.5 THE CLASSES INVOLVED</td>
      <td>250</td>
    </tr>
    <tr>
      <td>29.6 ADD A DELETE WIDGET OPTION</td>
      <td>255</td>
    </tr>
    <tr>
      <td>29.7 SUMMARY</td>
      <td>255</td>
    </tr>
    <tr>
      <td>29.8 FURTHER READING</td>
      <td>255</td>
    </tr>
    <tr>
      <td><b>30. MEMORY MANAGEMENT AND GARBAGE COLLECTION</b></td>
      <td><b>257</b></td>
    </tr>
    <tr>
      <td>30.1 INTRODUCTION</td>
      <td>257</td>
    </tr>
    <tr>
      <td>30.2 WHY HAVE AUTOMATIC MEMORY MANAGEMENT?</td>
      <td>257</td>
    </tr>
    <tr>
      <td>30.3 VISUALWORKS MEMORY MANAGEMENT</td>
      <td>258</td>
    </tr>
    <tr>
      <td>30.4 GARBAGE COLLECTION AND MEMORY COMPACTION</td>
      <td>259</td>
    </tr>
    <tr>
      <td>30.5 PLACING OBJECTS IN PERMSPACE</td>
      <td>259</td>
    </tr>
    <tr>
      <td><b>31. CONCURRENCY IN SMALLTALK</b></td>
      <td><b>261</b></td>
    </tr>
    <tr>
      <td>31.1 INTRODUCTION</td>
      <td>261</td>
    </tr>
    <tr>
      <td>31.2 CONCURRENT PROCESSES</td>
      <td>261</td>
    </tr>
    <tr>
      <td>31.3 PROCESSES IN SMALLTALK</td>
      <td>262</td>
    </tr>
    <tr>
      <td>31.4 A CONCURRENT SMALLTALK EXAMPLE</td>
      <td>264</td>
    </tr>
    <tr>
      <td>31.5 FURTHER READING</td>
      <td>267</td>
    </tr>
    <tr>
      <td><b>32. THE METACLASS FRAMEWORK</b></td>
      <td><b>268</b></td>
    </tr>
    <tr>
      <td>32.1 INTRODUCTION</td>
      <td>268</td>
    </tr>
    <tr>
      <td>32.2 WHAT ARE CLASSES?</td>
      <td>268</td>
    </tr>
    <tr>
      <td>32.3 CLASSES AND METACLASSES</td>
      <td>269</td>
    </tr>
    <tr>
      <td>32.4 CLASSDESCRIPTION AND BEHAVIOR</td>
      <td>271</td>
    </tr>
    <tr>
      <td>32.5 THE METACLASS CONCEPT GOES RECURSIVE!</td>
      <td>272</td>
    </tr>
    <tr>
      <td>32.6 FURTHER READING</td>
      <td>275</td>
    </tr>
    <tr>
      <td><b>33. THE FUTURE FOR OBJECT TECHNOLOGY</b></td>
      <td><b>278</b></td>
    </tr>
    <tr>
      <td>33.1 INTRODUCTION</td>
      <td>278</td>
    </tr>
    <tr>
      <td>33.2 THE SMALLTALK LANGUAGE</td>
      <td>278</td>
    </tr>
    <tr>
      <td>33.3 OBJECT ORIENTED DEVELOPMENT TOOLKITS</td>
      <td>280</td>
    </tr>
    <tr>
      <td>33.4 THE INTERNET AND OBJECTS</td>
      <td>281</td>
    </tr>
    <tr>
      <td>33.5 OBJECT ORIENTED DATABASES</td>
      <td>281</td>
    </tr>
    <tr>
      <td>33.6 SMALLTALK AS A TRAINING ENVIRONMENT</td>
      <td>282</td>
    </tr>
    <tr>
      <td>33.7 OBJECT TECHNOLOGY: THE NEXT FIVE YEARS</td>
      <td>282</td>
    </tr>
  </tbody>
</table>
34. APPENDIX: THE SMALLTALK LANGUAGE SYNTAX ................................................284

<table><tr><td>34.1 BASIC SYNTAX</td><td>284</td></tr><tr><td>34.2 LITERALS AND VARIABLES</td><td>285</td></tr><tr><td>34.3 CLASSES AND METHODS</td><td>287</td></tr><tr><td>34.4 BLOCKS</td><td>288</td></tr><tr><td>34.5 CLASS BOOLEAN</td><td>289</td></tr><tr><td>34.6 COLLECTIONS</td><td>289</td></tr></table>
Part One

# Introduction to Object Orientation
# 1. Introduction to Object Orientation

## 1.1 Introduction

This book is intended as an introduction to object orientation for computer science students or those actively involved in the software industry. It assumes familiarity with standard computing concepts such as stacks, memory allocation etc. and with a procedural language such as C. It uses this background to provide a practical introduction to object technology. To do this it uses Smalltalk, one of the earliest pure object oriented languages.

The approach taken in this book is to try to introduce a variety of concepts through practical experience with an object oriented language. It also tries to take the reader beyond the level of the language syntax to the philosophy and practice of object oriented development.

In the remainder of this chapter we will consider the various programming paradigms which have preceded object orientation. We will then examine what the primary concepts in object orientation are and consider how to enable object orientation to be achieved.

## 1.2 Programming paradigms

Software construction is still more of an art than a science. Despite the best efforts of many software engineers, software systems are still delivered late, over budget and not up to the requirements of the user. This situation has been with us for many years (indeed the first conference to raise awareness of this problem was the NATO Software Engineering Conference of 1968 which coined the term *software crisis*). Since then there have been a variety of programming paradigms which have either been developed explicitly to deal with this issue or which have been applied to it.

A programming paradigm is a particular programming style which embodies a particular philosophy. These philosophies usually represent some sort of insight which sets a new type of *best practice*. For a programming language to support a particular programming paradigm it must not just allow adoption of that paradigm (you can use object oriented programming techniques in assembler - but would you want to?) it must actively support implementations based on that paradigm. This usually means that the language must support constructs which make development using that paradigm straightforward.

The major programming paradigms which have appeared in computer science include:

**Functional** Lisp is the classic example of a functional language (although by no means the only one for example, ML is a very widely used functional language). These languages place far more emphasis on applying a function (often recursively) to a set of one or more data items. The function would then return a value - the result of evaluating the function. If the function changed any data items then this was a side effect of the function. There is (was) limited support for more algorithmic solutions which might rely on repetition via iteration. The functional approach turned out to be extremely useful as a way of implementing complex systems for early AI researchers.

**Procedural** as exemplified by languages such as Pascal and C. These were an attempt to move programming languages to a higher level (than the earlier assembler languages). The emphasis was now on algorithmic solutions and on procedures which operated on data items. They were extremely effective, but software developers still encountered difficulties. This was partly due to the increased complexity of the systems typically being developed. It was also because, although high level procedural languages removed the possibility of certain types of error occurring and increased productivity, developers could still cause problems for themselves. For example, the
interfaces between different parts of the system might be incompatible, but this might not become obvious until integration testing or system testing.

**Modular** Languages such as Modula-2 and Ada employ modularization. In these languages a module hides its data from module users. The users of the module can only access that data via defined interfaces. These interfaces are "published" so that users know what interfaces are available (and their definitions) and can check that they are using the correct versions.

**Object oriented** This is the most recent "commercial" programming paradigm. This approach can be seen as taking modularization a step further. Not only do you have explicit modules (in this case objects) but these objects can inherit features from one another. We can of course ask "why another programming paradigm?". The answer to this partly lies in the failure of many software development projects to keep to budget, remain within time scales and to give the user what they want. Of course, it should never be assumed that object orientation is the answer to all these problems, it is really just another tool available to software developers.

This book is about this last programming paradigm. It attempts to introduce this paradigm through the medium of an object oriented programming language. It assumes that the majority of readers will have a background in at least one procedural language (in particular with a C-like language). It therefore compares and contrasts the facilities provided with such a language at appropriate times.

It should be seen from the above list, that object orientation, even though it is quite different in many ways from the procedural approach, has developed from it. You should therefore not throw away all that you have learnt using other approaches. Many of the good practices in other languages are still good practices in an object oriented language. However, there will be new practices to learn as well as new syntax. It will be much more than a process of learning a new syntax - you have a new philosophy to learn.

## 1.3 Revolution versus evolution

In almost every area of scientific endeavor there are periods of evolution followed by periods of revolution and then evolution again. That is, some idea or theory is held to be "accepted" (not necessarily true but at least accepted). During this period the theory is refined by successive experiments / discoveries etc. Then at some point, the theory is challenged by a new theory. This new theory is typically held by a small set of extremely fervent believers. It is often derided by those who are staunch supporters of the existing theory. As time continues, either this new theory is proved wrong and disappears, or more and more are drawn to the new theory until the old theory has very few supports.

There are many examples of this phenomena in science. For example, the Copernican theory of the earth rotating around the sun, Einstein's theory of relativity and Darwin's theory of evolution. Men such as Darwin and those who led him to his discoveries were revolutionaries. They went against the current belief of the times and introduced a new set of theories. These theories were initially derided but have since become generally accepted. Indeed we are now in an evolutionary phase, with regard to the theory of evolution, where Darwin's theories are being refined. For example, Darwin believed that the mechanism of fertilization of an egg was derived from an old Greek theory referred to as Pangenesis. Every organ and tissue was assumed to produce granules, called gemmules. These were combined to make up the sex cells. Of course we now believe this to be wrong and it was Darwin's own cousin, Francis Galton, who helped to disprove the Pangenesis theory. Whether we will enter a new revolutionary phase where the theory of evolution will be over -turned is probably unlikely, however, Einstein's theory of relatively may well be (and is already being) challenged.

Programming is another example of this revolution / evolution cycle. The move from low level to high level programming was one such revolution (and you can still find people who will insist that low level machine code programming is best). Object orientation is another revolution, which in this case is still happening. Over the past ten years object orientation has become much more widely accepted and you will find many organizations, both suppliers and users of software, giving it lip service. However, you will also find many in the computer industry who are far from convinced. A senior colleague of mine recently told me that he believed that object orientation was severely over-hyped (which it may be) and that he really couldn't see the benefits it offered. Hopefully, this book will convince him (and others) that object orientation has a great deal to offer.
It is likely that something will come along to challenge object oriented programming, just as it has challenged procedural programming, as the current software development approach to use. It is also likely that a difficult and painful battle will ensue with software suppliers entering the market and leaving the market. Many existing suppliers will argue that their system always supported approach X anyway while others will attempt to graft the concepts of approach X onto theirs. When this will happen or what the new approach will be is difficult to predict, but it will happen. Until then, object orientation will be a significant force within the computer industry.

## 1.4 History /pedigree of object oriented languages

In the horse or dog breeding world, the pedigree of an animal can be determined by considering its ancestry. Whilst you can't determine how good a language is by looking at its predecessors, you can certainly get a feel for the influences which have led to features it possesses. The current set of commercial object oriented languages have all been influenced to a greater or lesser extent by existing languages. Figure 1.1 illustrates some of the relationships between the various languages.

<figure><img src="image_3.png" /><figcaption>Figure 1.1: Partial Smalltalk Family Tree</figcaption></figure>

Figure 1.1 only partially illustrates the family relationships, as for example, ADA95 should have a link to Smalltalk (or possibly C++). However, this figure attempts to illustrate the most direct influences evident in the various languages. The diagram is also ordered in roughly chronological order. That is, the further down the diagram a language is, the more recent it is. This illustrates for example, that Smalltalk predates C++ and that Java is the most recent object oriented language. Note that Lisp, ALGOL, C, Pascal and Ada are not object oriented and that Simula itself, is at most object based.

The extent to which a language can be considered to be a *pure* object oriented language (i.e. one in which object oriented concepts are consistently adhered) as opposed to a *hybrid* object oriented language (i.e. one in which object oriented concepts lie along-side traditional programming approaches) tends to depend on their background.

A pure object oriented language only supports the concept of an object. Any program is made up solely of interacting objects which exchange information with each other and request operations or data from each other. This approach tends to be followed by those languages which most directly inherit features from Simula (C++ is a notable exception). Simula was designed as a language for discrete event simulation. However, it was itself influenced by many of the features from ALGOL 60 and was effectively the first language to use concepts which we now refer to as object oriented. For example, it introduced the concepts of class, inheritance and polymorphism which we shall discuss below.

The primary language to inherit most directly from Simula is Smalltalk. This means that its ALGOL heritage is there for all to see in the form of structured programming constructs (although the syntax may at first seem a little bizarre). It is a pure object oriented language in that the only concepts supported by the language are object oriented. It also inherits from Lisp (if not any syntax, then certainly the philosophy). This means that not only does it not include strong typing, it also provides dynamic memory management and automatic garbage collection (just as most Lisp systems do). This has both benefits and drawbacks which we will discuss at a later stage. In contrast Eiffel, another pure object oriented language, attempts to introduce "best software engineering practice" rather than the far less formal approach of Lisp. Self is a recent, pure object oriented language, which is still at the research stage.

Many language designers have taken the *hybrid* approach. That is, object oriented constructs have either been grafted on to, or intermixed with, the language. In some cases the idea has been to enable a developer to take advantage of object orientation when it appears appropriate. In other situations it has
been to ease the transition from one approach to another. The result has often been a less than satisfactory state of affairs. Not only does it mean that many software developers have moved to their new object oriented language believing that it is just a matter of learning the new syntax, (it isn't), they have proceeded to write procedural programs in which the use of objects is limited to holding data, believing that this will be sufficient (it won't). It is really only safe to move to a hybrid language once you have learnt about object technology using a pure object oriented language.

## 1.5 Fundamentals of object orientation

The object oriented programmer's view of traditional procedural programming is of procedures wildly attacking data which is defenseless and has no control over what the procedures do to it. This has been called the rape and pillage style of programming. The object oriented programmers view of object oriented programming is of polite and well behaved data objects passing messages to one another, each data object deciding for itself whether to accept the message and how to interpret what it means.

The basic idea is that a system is seen as a set of interacting objects which are organized into classes (of objects). For example, Figure 1.2 illustrates a (simplified) cruise control system from a car. The figure illustrates the objects in the system, the links between the objects and the direction that information flows along these links. The object oriented implementation of this system would mirror this diagram exactly. That is, there would be an object representing each box. Between the boxes would be links allowing one object to request a service from another, or provide information to another. For example, the cruise control electronic control unit (ECU) might request the current speed from the speed sensor. It would then use this information when asking the throttle to adjust its position. Notice we do not talk about functions or procedures which access information from data structures and then call other functions and procedures. There is no concept such as the ECU data structure and the ECU main program. This can be a difficult change of emphasis for some people and we shall try to illustrate it further below.

<figure><img src="image_4.png" /><figcaption>Figure 1.2: A cruise control system as a set of objects</figcaption></figure>

The aim in object oriented programming is to shift the focus of attention from procedures that do things to data round to data which is asked to do things. The task is not to define the procedures which will manipulate data but to define data objects, their attributes and the way in which they may be examined or changed. Data objects (and procedures) can communicate with data objects only through narrow, well defined channels.

## 1.6 The four catechism of object orientation

The four catechism of object oriented programming are:

**Encapsulation or data hiding.** Encapsulation is the process of hiding all the details of an object that do not contribute to its essential characteristics. Essentially, it means that what is inside the class is hidden; only the external interfaces are known (by other objects). That is, as the user of an object you should never need to look inside the box!

**Inheritance.** In many cases objects may have similar (but not identical) properties. One way of managing (classifying) such properties is to have a hierarchy of classes. In this hierarchy of
classes a class inherits both from its immediate parent class, above it in the hierarchy, and from classes above the parent. (See the hierarchy in Figure 1.4). This inheritance mechanism permits common characteristics of objects to be defined once, but used in many different places. Any change is thus localized.

**Abstraction.** An abstraction denotes the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provides crisply defined conceptual boundaries, relative to the perspective of the viewer. That is, it states how a particular object differs from all others.

**Polymorphism.** This is the ability to send the same message to different instances which may appear to perform the same function. However, the way in which the message is handled will depend on the class of which the instance is an example.

An interesting question to ask yourself is how do the following languages relate to the four concepts related above? ADA, C and LISP. An obvious issue to consider is related to inheritance. That is, if we define a concept animal and we then define a concept dog, we don't have to redefine all the things which a dog has in common with other animals. Instead we inherit these features by saying that a dog is a subclass of animal. This is a feature unique to object oriented languages. It is also the concept which promotes (and achieves) huge amounts of reuse.

# 1.7 Encapsulation

## 1.7.1 The concept

Encapsulation or data hiding has been a major feature of a number of programming languages. For example, Modula-2 and Ada both provide extensive encapsulation features. But what exactly is encapsulation? Essentially, it is the concept of hiding the data behind a software "wall". Those outside the wall cannot get direct access to that data. Instead they must ask intermediaries (usually the owner of the data) to provide them with the data.

The advantage of encapsulation is that the user of the data does not need to know how, where or in what form the owner of the data stores that data. This means that if any changes are necessary in the way in which the data is stored, the user of the data need not be affected. That is, they will still ask the data owner for the data in the same way and it is only the data owner who must change the way in which they proceed in fulfilling that request.

Different programming languages have implemented encapsulation in different ways. For example, in Ada the prevalent concept which enables encapsulation is the package. A package possess both data and procedures. It also specifies a set of interfaces which publish those operations the package wishes to make available to users of the package. These interfaces may for example implement some operations or may provide access to data held within the package.

## 1.7.2 How OO languages provide encapsulation

Object oriented languages provide encapsulation facilities which present the user of an object with a set of external interfaces. These interfaces say what requests the object will respond to (or in the terminology of object orientation, which the object will understand). These interfaces not only avoid the need for the caller to understand how the internal details of the implementation work, they actually prevent the user from obtaining that information. That is, the user of an object cannot directly access the data held by an object as it is not visible to them. In other words, a program that calls this facility can treat the facility as a black box; the program knows what the facility's external interfaces guarantee to do, and that is all it needs to know.

It is worth pointing out a difference between the object oriented approach and the package approach used in Ada. In general a package will be a large unit of code providing a wide range of facilities with a large number of data structures. For example the Text IO package in Ada. In an object oriented language, the encapsulation is provided at the object level. While objects may well be as large and as complex as the typical Ada package, they are often much smaller. In languages such as Smalltalk where everything is an object, this means that the smallest data and code units also naturally benefit from
encapsulation. Attempting to introduce the same level of encapsulation in Ada can be done, but it is not
*natural* to the language.

<figure><img src="image_5.png" /><figcaption>Figure 1.3: Object structure and interaction</figcaption></figure>

Figure 1.3 illustrates the way in which encapsulation works within object oriented languages. It shows that anything outside the object can only gain access to the data the object holds via a specific interface (the black squares). In turn these interfaces trigger procedures which are internal to the object. These procedures may then access the data directly, use a second procedure as an intermediary or call an interface on another object.

1.8 Inheritance

1.8.1 What is inheritance?

A class is an example of a particular type of thing (for example mammals are a class of animal). In the object oriented world a class is a definition of the characteristics of that thing. Thus in the case of mammals, we might define that they have fur, are warm blooded and produce live young. Animals such as dogs and cats are then instances of the class mammal. This is all quite obvious and should not present a concept problem for anyone. However, in most object oriented languages (the language Self being an exception) the concept of the class is tightly linked to the concept of inheritance.

Inheritance allows us to state that one class is similar to another class but with a specified set of
differences. Another way of putting it, is that we can define all the things which are common about a
class of things, and then define what is special about each sub grouping within a subclass.

For example, if we have a class defining all the common traits of mammals we can define how
particular categories of mammals differ. Take for example the Duck -billed platypus. This is a quite
extraordinary mammal which differs from other mammals in a number of important ways. However,
we do not want to have to define all the things which it has in common with mammals twice. Not only
is this extra work, but we then have two places in which we have to maintain t his information. We can
therefore state that a Duck -billed platypus is a class of mammal that differs in that it does not produce
live young (we might also want to mention its beak etc. but for now we will ignore these issues).

1.8.2 An example of inheritance

An example which is rather closer to home for most computer scientists is illustrated in Figure 1.4. For this example we will assume that we have been tasked with the job of designing and implementing an administration system for our local University. This system needs to record both employees of, and students attending, the university. For students we need to record what department they are in, what subjects/classes they are taking (referred to as modules) or what their t hesis is about. For employees we need to record the department they work in, what their salary is, what subjects they lecture or research. If they are a professor we need to record that fact. In the case of professors we might also want to record the government bodies they work for.

Figure 1.4 illustrates a class hierarchy diagram for this application. That is, it illustrates each of the
classes we have defined and from where they inherit their information. There are a number of points
you should note about this diagram:
**Inheritance versus instantiation.** Stating that one class is a specialized version of a more generic class is different from saying that something is an example of a class of things. In the first case we might say that a lecturer is a category of university employee and that a professor is another category of university employee. Neither of these categories can be used to identify an individual. They are, in effect, templates for examples of those categories. In the second case we say that "John" is an example of a lecturer (just as "Chris", "Myra" and "Denise" may also be examples of lecturers). "John" is therefore an instance of a particular class (or category) of things known as Lecturers. It is important to get the concept of specializing a class with a subclass clear in your mind. It is all too easy to get instances of a class and a subclass of a class confused.

<figure><img src="image_6.png" /><figcaption>Figure 1.4: An example of inheritance</figcaption></figure>

**Inheritance of common information.** We have placed common concepts together in a single class. For example, all people have a name, all University -Members have a nominated department (whether they are students or employees). All students have a year in which they started their studies, whether they are undergraduates or postgraduates. In turn all classes below University -Member inherit the concept of a department. This means that not only will all Professors and Lectures have a department, but "John" has a department which in this case is "Computer Science".

**Abstract classes.** It is also worth noting that we have defined a number of classes of which we have no intention of making an example. These include University-Member, University-Employee and Student. These are termed abstract classes (we will come back to this terminology later). They are intended as place holders for common features rather than as templates for a particular category of things. This is quite acceptable and is common practice in most object oriented programs.

**Inheritance of defaults.** Just because we have stated that all University -Employees earn a default salary of £14,000 a year does not mean that all university employees have to have that default. In the figure, Professors have a default of £30,000 illustrating that one class can over write the defaults defined in one of its parents.

**Single versus multiple inheritance.** In Figure 1.4 we have only illustrated single inheritance. That is, one class can inherit from only one other class. This is the case in many object oriented programming languages such as Smalltalk. However, other languages such as C++ and Eiffel allow multiple inheritance. The idea behind multiple inheritance is that you can bring together the characteristics of two classes in order to define a new class. For example, you might have a class Toy and a class Car which could be used to create a class Toy-Car. Multiple inheritance
is a controversial subject which is still being debated. Those who think it is useful fail to see why other languages don't include it and vice versa. Java the most recent object oriented language does not include multiple inheritance.

## 1.9 Abstraction

We have already touched on the subject of abstraction in the previous section. However, abstraction is much more than just the ability to define categories of things which can hold common features of other categories of things (e.g. `Student` is an abstract class of `Undergraduate-Student` and `Postgraduate-Student`). It is in fact a way of specifying what is particular about a class of things. Often this means defining the interface for an object, the data that such an object will hold and part of the functionality of that object.

For example, we might define a class `DataBuffer`. This class may be used to define an abstract class for things that hold data and return them on request. This class may define how the data is to be held and that operators such as `put()` and `get()` will be provided to add data to the `DataBuffer` and remove it from the `DataBuffer` respectively. In turn the implementation of these operators may be left to those implementing another class which is a subclass of `DataBuffer`.

The class `DataBuffer` might, for example, be used to implement a `Stack` or a `Queue`. `Stack` could implement `get()` as *return the most recent data item added* while `Queue` could implement it as *return the oldest data item held*. In either case, a user of either class will know that `put()` and `get()` are available and will work in an appropriate manner.

In some languages it can also be related to protection. For example, both C++ and Java have the ability to state whether subclasses are allowed to overwrite data or procedures (and indeed whether they have to overwrite them or not). Smalltalk does not provide the ability to state that a procedure cannot be overwritten, but it does allow the developer to state that a procedure (or method) is a `superclass` responsibility. That is, a subclass is expected to implement the procedure in order to provide a functioning class.

Abstraction is also associated with the ability to define Abstract Data Types (or ADTs). In object oriented terms these are classes (or groups of classes) which provide some sort of behavior (e.g. `DataBuffer` above) which acts as the infrastructure for a particular class of data types (e.g. things like stacks and queues). However, it is worth pointing out that ADTs are more commonly associated with procedural languages such as Ada. This is because the concepts in object orientation essentially supersede ADTs. That is, not only do they encompass all the elements of ADTs, they extend them by introducing inheritance.

## 1.10 Polymorphism

Polymorphism is a strange sounding (Greek derived) word for a relatively simple concept. It is essentially the ability to request that the same operation be performed by a wide range of different types of things. How that request is processed will depend on what it is that received the request. However, you as a programmer, need not worry about how the request is handled, only that it is. For example, you might ask a range of objects to provide a printable string describing themselves. This would mean that if you wished to ask an instance of the `Lecturer` class (presented above or the system) or a compiler object or a database object to return such a string, you would apparently use the same interface call (such as `printString` in Smalltalk).

The name *Polymorphism* is unfortunate and often leads to confusion. Of course, it also makes the whole process sound rather grander than it actually is. There are two types of polymorphism used in programming languages: *overloading* and *overriding*. The difference in name relates to how the mechanism used to resolve what code to execute is determined. The difference between the two is significant and is important to understand. To understand what polymorphism actually is, it helps to understand how these two different mechanisms work.
### 1.10.1 Overloading operators

This occurs when procedures have the same name but are applied to different data types. The compiler can therefore determine which operator will be used at compile time and can use the correct version of the operator. Ada uses exactly this type of overloading. For example, you can define a new version of the `+` operator for a new data type. Other programmers would use a `+` for addition and the compiler would use the types associated with the `+` operator to determine which version of `+` to use. In C, although the same function is used to print a value (namely `printf`), this is not a polymorphic function. Instead, the user must explicitly make sure that they are using the correct options in the format specifier to ensure that a value is printed correctly.

### 1.10.2 Overriding operators

This occurs when a procedure is defined in one class (for example, `Student`) and also in one of its subclasses (for example, `Undergraduate-Student`). This is referred to as overriding. This means that all instances of `Student` or `Undergraduate-Student` will respond to requests for this procedure (assuming it has not been made private to the class). For example, let us assume that we had defined the procedure `printString` in these classes. The pseudo code definition of this in `Student` might be:

```Ada
printString
    return 'I am a student'
```

Where as in the `Undergraduate-Student` it might be defined as:

```Ada
printString
    return 'I am an Undergraduate student'
```

The procedure in `Undergraduate-Student` replaces the version in `Student` for all instances of `Undergraduate-Student`. That is, if we made an instance of `Undergraduate-Student` and asked for the result of `printString`, we would get the string 'I am an Undergraduate student'. If you are confused, think of it this way:

> "If you have asked an object to perform some operation, then to determine which version of the procedure will be run, look in the class used to create your instance, if the procedure is not defined there, look in the class's parent class. Keep doing this until you find a procedure which implements the operation requested. This is the version which will be used."

In languages such as Smalltalk and Java the choice of which version of `printString` to execute is not determined at compile time. Instead it is chosen at run time. This is because the compiler would have to be able to determine what type of object will be operated on and then find which version of the procedure will therefore be run. In Smalltalk's case it cannot determine the type of object in most cases.

The technical term for this process of identifying which procedure to run at run time rather than compile time is called "late binding" and we shall look at this issue in more detail later in the book.

### 1.11 Summary

In this chapter you have been introduced to the background/history which led to object orientation. You have explored the main concepts which are the underpinnings of object orientation and have encountered some of the (sometimes arcane) terminology used. There is a great deal of new information in this chapter which can at times appear to make obsolete all that you already know.

The object oriented view of the world can be daunting for a programmer who is used to a more procedural view of the world. To have to adjust to this new view of the world is hard (and some never do). Others fail to see the difference between an object oriented programming language and a language such as ADA (ADA here refers to the pre-Ada 95 version of the language). However, object orientation
will become second nature to many once they have worked with object oriented systems for a while.
The key thing is to try things out as you go along and if possible have someone around who understands
a bit about object orientation - they can often illuminate and simplify an otherwise gloomy network of
tunnels.

1.12 Further reading

There are of course a great many books available on object orientation some of the best known include
[Booch 1994; Budd 1991; Wirfs-Brock et al 1990; Cox and Novobilski 1991]. An excellent book aimed
at managers and senior programmers who want to learn how to apply object oriented technology
successfully to their projects is [Booch 1996]. Another good book in a similar style is [Yourdon 1994].

Other books which may be of interest to those attempting to convince themselves or others that
object technology can actually work are [Harmon and Taylor 1993], [Love 1993] and [Meyer and
Nerson 1993]. Other places to find useful references are the Journal of Object Oriented Programming,
Pub. SIGS Publications, ISSN 0896-8438 and the OOPSLA conferences. These are a set of world wide
conferences on Object Oriented Programming: Systems, Languages and Applications (hence
OOPSLA). They are held every year, references for some recent ones are listed at the back of this book.
There is also a European Conference on Object Oriented Programming called ECOOP. Some of these
conference proceedings are also listed at the back of this book.

For further reading on the software crisis and approaches aimed at solving it see [Brooks 1987] and
[Cox 1990]. For a discussion of the nature of scientific discovery, refinement and revolution see [Kuhn
1962].
# 2. Elements of Object Orientation

## 2.1 Introduction

This chapter is intended to reinforce what you have already learnt in Chapter 1. It concisely defines the terminology introduced in the last chapter and attempts to clarify issues associated with hierarchies. It also discusses some of the perceived strengths and weaknesses of the object oriented approach. Some guidance on the approach to take in learning about objects is also offered.

## 2.2 Terminology

In Chapter 1 a number of terms were introduced during the discussion of object orientation. Here we recap on those terms and introduce a number of new ones.

**Class.** A class is a definition for a combination of data and procedures which operate on those procedures. Instances of other classes can only access that data or those procedures via specified interfaces. A class acts as a template when creating new instances. That is, a class does not hold any data, the data is held in the instance. However, the class specifies what data will be held. This will be considered in more detail in Part 2 of this book. The relationship between a class, its superclass and any subclasses is illustrated in Figure 2.1.

<figure><img src="image_7.png" /><figcaption>Figure 2.1: The relationship between Class, Superclass and Subclass</figcaption></figure>

**Subclass.** A subclass is a class which inherits from another class. For example, in the last chapter, `Undergraduate-Student` was a subclass of `Student`. Subclasses are of course classes in their own right. The term subclass merely indicates what is inherited by what. Any class can have any number of subclasses.

**Superclass.** A superclass is the parent of a class. It is the class from which the current class inherits. For example, in the last chapter, `Student` class was the superclass of `Undergraduate-Student`. In Smalltalk a class can only have one superclass.

**Instance/Object.** An instance is an example of a class. All instances of a class possess the same data variables but have their own data in these data variables. Each instance of a class will also respond to the same set of requests.

**Instance variable.** This is the special name given to the data which is held by an object. The "state" of an object at any particular moment relates to the current values held by its instance variables. (In Smalltalk there are also class variables but a discussion of these will be left until later). Figure 2.2 illustrates a definition for a class in pseudo code. This definition includes some instance variable definitions fuel, mileage and name.

**Method.** Method is the name given to a procedure defined within an object. The name stems from its use in early versions of Smalltalk where it was a method used to get an object to do something
or return something. It has since become more widely used with languages such as CLOS and Java also using the term. Two methods are defined in Figure 2.2, one calculates the miles per gallon while the other sets the name of the car object.

<figure><img src="image_8.png" /><figcaption>Figure 2.2: A pseudo code definition of a class</figcaption></figure>

**Message.** This is a request from one object to another object requesting some operation or data. It is traditional to say that one object sends a message to another object requesting it to do something. The idea is that objects are polite well behaved entities which carry out functions by sending messages to each other. In other languages it might be consider akin to a procedure call (again this issue will be discussed later in part 2).

**Self.** This is a reference to the object within which the method is executing (see Figure 2.2). This means that it is possible to send messages to this object (i.e. ones' self).

**Single/Multiple inheritance.** Single and multiple inheritance refer to the number of superclasses that a class can inherit from. Smalltalk is a single inheritance system. This means that a class can only inherit from one superclass. C++ is a multiple inheritance system. This means that C++ classes can inherit from one or more classes.

## 2.3 Types of hierarchies in object orientation

This can be an area of confusion. In most object oriented systems there are two types of hierarchy, one refers to inheritance (whether single or multiple) while the other refers to instantiation. The inheritance hierarchy (or is -a hierarchy) has already been described. It is the way in which an object “inherits” features from a superclass.

The instantiation hierarchy relates to instances rather than classes and is important during the execution of the object. There are in fact two types of instance hierarchy, one indicates a part -of relationship while the other relates to a using relationship. Figure 2.3 illustrates the differences between the two.

<figure><img src="image_9.png" /><figcaption>Figure 2.3: Instance relationships</figcaption></figure>

The difference between an *is-a* relation and a *part-of* relationship is often confused using for new programmers (and sometimes for those who are experienced in one language but are new to an object oriented programming language such as Smalltalk). Figure 2.4 should make it clear. This figure illustrates that a student *is-a* type of person where as an engine is *part-of* a car. That is, it does not makes sense to say that a student is *part-of* a person nor that an engine *is-a* type of car!
<figure><img src="image_10.png" /><figcaption>Figure 2.4: is-a does not equal part-of</figcaption></figure>

In Smalltalk, the *is-a* relationship is generally implemented via the subclassing mechanism. It is thus possible to build up large and complex class hierarchies which express these *is-a* relationships. These classes express the concept of inheritance, allowing one class to inherit features from another. The total set of features are then used to create an instance of a class. In contrast, the *part-of* relationships tend to be implemented using instance variables in Smalltalk.

However, *is-a* relationships and classes are not exactly the same thing. For example, if you wished to construct a semantic network consisting of explicit *is-a* relationships between instances you might have to construct such a hierarchy manually. The aim of such a structure is to represent some sort of knowledge and the relationships between elements of that knowledge and not for the construction of instances. This is outside the scope of the subclassing mechanism and would therefore be inappropriate.

Another confusion between *is-a* relationships and classes is that John might be an instance of a class Person. It would be perfectly (semantically) correct to say that John *is-a* Person. However, here we are obviously talking about the relationship between an instance and a class rather than a subclass and its parent class.

A further confusion can occur for those encountering Smalltalk who have first encountered a strongly typed language. These people might at first assume that a subclass and a sub type are essentially the same. However, they are not the same, although they are very similar. The problem with classes, types and *is-a* relationships is that on the surface they appear to capture the same sorts of concepts. For example, see Figure 2.5. In this figure, the four diagrams all capture some aspect of the use of the phrase is-a. However, they are all intended to capture a different relationship.

<figure><img src="image_11.png" /><figcaption>Figure 2.5: Satisfying four relationships</figcaption></figure>

All of the confusion highlighted above is due to the fact that in modern English we tend to over use the term *is-a*. We can distinguish between the four different types of relationship by being more precise about our definitions in terms of a programming language such as Smalltalk. For example, in Table 2.1 we define the meaning of the four different relationships identified above.

<table><caption>Table 2.1: Types of *is-a* relationships</caption><tr><td><strong>type</strong></td><td>substitutability relationship. That is an example of one type that can be used interchangeably with another (sub)type.</td></tr><tr><td><strong>subclassing / inheritance</strong></td><td>an implementation mechanism for sharing code and representation</td></tr><tr><td><strong>specialization</strong></td><td>specifying that one thing is a special case of another</td></tr><tr><td><strong>instantiation</strong></td><td>one thing is an example of a particular category (class) of things</td></tr></table>

To illustrate this point consider Figure 2.6. This figure illustrates the differences between the first three categories. The first diagram illustrates the potential relationships between a set of classes
defining the behavior of different categories of vehicle. The second diagram presents the sub type relationships between the categories while the third diagram illustrates a straight specialization set of relationships. Note that although the *estate car* is a specialization of a *car with hatch*, its implementation (the subclassing hierarchy) in dicates that it does not share any of its implementation with the *car with hatch* class.

<figure><img src="image_12.png" /><figcaption>Figure 2.6: Distinguishing between the relationships</figcaption></figure>

It is worth noting that another difference between type and subclassing is that type relationships are specifications, while classes (and subclasses) are implementations of behavior.

## 2.4 Why bother?

We have already stated that the transition from a procedural view point to an object oriented view point is not always an easy one. This begs the question “why bother?”. As you are reading this book you must at least be partly convinced that it is a good idea. Of course this could be because you have noticed the number of job advertisements offering employment for those with object oriented skills. However, that aside, why should you bother learning a new programming paradigm?

Hopefully, some of the reasons why you should bother will become clear during your reading of this book. However, it is worth considering at least some of the issues at this point.

### 2.4.1 Software industry blues

There is still no silver bullet for the problems in the software industry. Object oriented technology does not take away the problems which exist in constructing complex software systems, it just makes some of the pitfalls harder to fall into and provides ways of simplifying traditionally difficult problems. However, difficulties in software development are almost inevitable, many of them arise due to the inescapable intangibility of software and not necessarily all by accident or poor development methods.

We should not however just throw up our hands and say “well if that’s the case, it is not our fault”. Many of the problems which have beset our industry relate to some deficiency in how programmers build software today. For example, if a software development is running late then just adding more people to that late project is likely to make matters worse rather than get the project back on time.

Of course object technology is not the first attempt at addressing these issues. However, past attempts have met with mixed success. This is for a number of reasons, only some of which we will consider below. However, as these issues are particularly pertinent to object technology, we will therefore consider each in turn.
### 2.4.1.1 Modularity of code

Traditional, procedural systems, typically relied on the fact that not only would the data they were using not change (e.g. its type) but the way in which they got that data would not alter. Invariably, it was the function (or functions) using the data, that actually went and got that data. This meant that if the way in which the data was accessed had to change, all the functions which used that data had to be rewritten. Those among you who have attended any sort of software engineering course will of course say that what was required was a function to obtain the data. This function could then be used in many different places. However, such application specific functions tend not to be used in "real world" systems. This occurs for several reasons including:

* Small subroutines are too much effort. Although many people talk about reusable code, they often mean relatively large code units. Small functions of one, two or three lines tend only to be defined by a single programmer and are rarely shared amongst a development team, let alone development teams.

* Too many subroutines leads to too little reuse. The larger the number of subroutines available, the less likely that they will get reused. It is very difficult to search through a code library of small subroutines trying to find one which does what you want. It is often much quicker to write it yourself!

* Identifying that a function may be reusable may not be obvious. If you are a programme r working on one part of a system, it may not be obvious that the function you are writing would be of generic use. If these functions are small then they will not have been identified by the designer as being useful reusable components.

### 2.4.1.2 Ability to package software

Another issue is the way in which programming languages package up software for reuse. Many systems assume that the software should be partitioned into modules, which are then integrated at compile time. Such fixed compile time integration can be good for some types of problem, but in many cases it is too inflexible. For example, while this approach can ensure that the modules being reused are compatible, the developer may not know until run time which modules they wish to use. They would therefore require some form of run time binding.

The UNIX pipes and filters are examples of software systems which can be bound at run time. They act as glue allowing the developer to link two or more programs in sequence together. However, in this case there is absolutely no error protection. It is quite possible to link two incompatible systems together.

What would be really useful would be a combination of these features. That is, the ability to specify either compile time or run time binding. In either case there should be some form of error checking to ensure that you are integrating compatible modules. An important criteria is to avoid the need for extensive recompilation, for example just because one line has been altered. Finally, such a system should by definition enforce encapsulation and make packaging of the software effortless.

### 2.4.1.3 Flexibility of code

In early procedural languages there was little or no flexibility, for example, C or Pascal. However, more recent procedural languages have introduced some flexibility but need extensive specification to achieve this. The result is internal flexibility at the cost of interface overheads, for example Ada. Object technology allows code flexibility (and data flexibility) with little overhead.

## 2.4.2 The claimed advantages of object orientation

There are a range of benefits which can be identified for object oriented programming languages. Not all of these are unique to object oriented technology, but that's okay, we are talking about the good things about object orientation here. The main benefits can be summarized as:

**Increased code reuse.** Languages such as Smalltalk encourage reuse. Every time you specify that one class inherits from another (and you do it all the time in Smalltalk) you are involved in reuse.
In time most developers start to actively look to see where they can restructure classes to improve the potential for reuse. As long as this is not taken too far, this is an extremely healthy thing to do.

**Data protection for little effort.** Due to the encapsulation facilities provided as part of the language you get your data protected from unscrupulous users. Unlike languages such as Ada, you don't have to write reams of specification in order to achieve this protection.

**Encapsulation eases integration.** As users of an object cannot access the internals of the object they must go via specified interfaces. As these interfaces can be published in advance of the object being implemented, others can develop to those interfaces knowing that they will be available when the object is implemented.

**Encapsulation eases maintenance.** This point is really a variation on the last point. As users of an object have been forced to access the object via the specified interfaces, as long as the external behavior of these objects appears to remain the same, the internals of the object can be completely changed. For example, an object could store an item of data in a flat file, read it from a sensor or obtain it from a database. However, external uses of the object need never know.

**Simplified code - polymorphism.** With polymorphism you don't need to worry about exactly what type of object you will get at run time, only that it must respond to the message (request for a method to be executed) you send it. This means that it is a great deal easier to write reusable, compact code, than in many other languages.

**More intuitive programming paradigm.** It has been argued that object orientation is a more intuitive programming paradigm than approaches such as procedural. This is because we humans tend to perceive the world in terms of objects. We see dials, windows, switches, fuel pumps, automated teller machines (ATMs). These objects respond to our use in specific ways when we interact with them. For example, an ATM will require a card, a PIN number etc. in a particular sequence. Of course those of us who have programmed before bring with us a lot of baggage including preconceptions of what a program should be like and how you develop one. Hopefully, this book is about to turn all that on its head for a while, before putting everything back together again.

### 2.4.3 What are the problems/pitfalls?

Of course no programming language / paradigm is without its own set of problems and pitfalls. Indeed part of the skill in becoming fluent in a new programming language is learning what the problems are and how to avoid them. In this section we will concentrate on the damning statements usually leveled at object orientation. We will deal with common software problems in a later chapter.

#### 2.4.3.1 Lots of confusing terminology

This is actually a fair comment. As you have already seen, object orientation is littered with new terms and definitions for what appears to have already been defined quite acceptably in other languages. It is difficult to argue against this and one may ask the question why this is the case? Certainly, back in the early 70s when Smalltalk was being researched, many of the terms we now take for granted were already quite well established. It would be unreasonable to assume that even if the inventors of the language like their own terminology early users would have tried to get the terminology changed.

One possible answer to this is that in the past (that is, during the early and mid eighties) object oriented languages, such as Smalltalk, tended to be the preserve of academics and research institutions. (Indeed I myself was introduced to it while working on a research project at a British university during 1986/87 having worked with Lisp Flavors for a few years). It is often the case that these people enjoy the mystique that a language with terminology all of its own can create. By now it is so well established in the object oriented culture that you as a new comer will just have to adapt. The important point to remember is that the concepts are actually very simple, although the practice can be harder. To illustrate this, consider the following table, this attempts to illustrate the parallels between object oriented terminology and procedural terminology:

These approximations should not be taken too literally as they are intended only to help you visualize what each of the terms means. Hopefully, by the end of the book you will have gained your own understanding of their meaning.
<table><caption>Table 2.2: Approximate equivalents</caption><thead><tr><td>Procedural term</td><td>OO term</td></tr></thead><tbody><tr><td>procedure</td><td>method</td></tr><tr><td>procedure call</td><td>message</td></tr><tr><td>non-temporary data</td><td>instance variables</td></tr><tr><td>record + procedures</td><td>object</td></tr></tbody></table>

### 2.4.3.2 Yet another programming paradigm to master

In general people tend to like the things they are used to. This is why many people will buy the same make of car again and again (even when it gives them trouble). It is also why computer scientists will refuse to move to a new word processor / editor / operating system or hardware. Over the years I have had many “discussion” with people over the use of Latex versus Word versus WordPerfect, the merits of Emacs and Vi or of UNIX versus Mac or Windows/DOS. In most cases the issues raised and points made indicate that those involved in the discussions (including myself) are biased, have their own “hobby horse” to promote and don’t understand fully what the other approach is about.

Object orientation both benefits and suffers from this phenomena. There are those who hold it up almost like a religion and those who cast it aside because it is so different from what they are used to. Many justify this latter approach by pointing out that procedural programming has been around for quite a while now and many systems are successfully developed using it. This is of course a reasonable statement and one which promotes the status quo. However, the fact that object orientation is a new software paradigm, which is quite different from the procedural paradigm, should not be a reason for rejecting it.

The important points to note about it are that it explicitly encourages encapsulation (information hiding), promotes code reuse and enables polymorphism. Most procedural languages have of course attempted to present these advantages as well, however they have failed to do so in such a coherent and concise manner. Take Ada for example, not only is it a large cumbersome language, it requires an extensive specification to be written to enable two packages to work together. Any error in these specifications and the system will not compile (even if there are no errors or incompatibilities in the code). It is also interesting to note that Ada 95 has introduced the concept of objects and classes into the language. Although for most object technology practitioners, the way in which it has done this, is both counter intuitive and unwieldy.

### 2.4.3.3 Many OO environments are inefficient

Historically, object oriented development environments have been inefficient, processor intensive and memory hungry. Such environments tended to be designed for use on powerful workstations or mini-computers. Examples of such environments have included Lisp Flavors (which even required specialist hardware e.g. the Symbolics Lisp machine), Self and Smalltalk -80 (the fore runner of VisualWorks). These machines were expensive, sometimes non-standard and aimed at the research community.

With the advent of the PC, attempts were made to rectify this situation. For example, Smalltalk/V was designed specifically to run on the PC and the first version of Smalltalk used by the author was on a 286 PC. The current versions of products such as VisualWorks are now extremely efficient and optimized for use on PC platforms. Although in the case of VisualWorks the use of 16 megabytes of RAM is advisable, any 486 machine or above provides ample performance. The issue of 16 MEG rather than the current 8 MEG is not large, as an additional 8 MEG can be purchased at reasonable rates and many industry pundits predict that 64 MEG (and more) will soon become industry standards. Indeed systems are now emerging which assume that a user will have access to larger memory (such as J++ which requires a minimum of 24 MEG to run the debugger).

Of the course the whole of this section is not really relevant to C++ and object oriented versions of Pascal (such as Delphi) as they are no more memory or processor intensive than any non-object oriented language. However, it is worth noting that these languages do not offer the same level of support for the programmer as for example Smalltalk. In particular they do not provide automatic memory management and garbage collection. However, we will discuss this issue in more detail later in the book.
#### 2.4.3.4 Smalltalk environments are not geared up for project development

Smalltalk environments such as VisualWorks, are derived from the early Smalltalk development systems (see chapter 4). These early development environments were originally designed for a single programmer to develop their own personal programs. This means that the environment provides a great deal of support for developing a single system within a single process, however it provides little or no support for group working. This means that when Smalltalk is used as the basis of a group project (such as is the norm in today's software industry), the project team members must use the facilities provided by the host operating system to share data and code.

In most development environments the above issue is not a problem. However, in VisualWorks the situation is rather different. This is because of the way in which source code and executable code are held by the "environment". It actually takes a conscientious act on the part of the programmer to "extract" their code from the environment and save it onto the host operating system's file system. It is therefore all to easy to get out of "sync" with other members of the team, to forget to obtain the latest version of source code or to have problems when attempting to merge code written by different developers for the same class.

This obviously means that Smalltalk is unsuited to this type of development! Doesn't it? In fact, it is not difficult to provide suitable protocols to ensure that the above situation does not happen. These can in some cases be used to program extensions to the basic environment to make group working easier. It is also possible to purchase support software which does provide extremely good support for group project working. It is therefore incorrect to say that Smalltalk does not support team based software development.

## 2.5 The move to object technology

At present you are still acclimatizing yourself to object orientation. It is extremely important that from now on you do your utmost to immerse yourself in object orientation, object technology and (in the case of this book) Smalltalk. This is because, when you first encounter a new language/paradigm, it is all to easy to say that it is not good because you can't do what you could do in language/paradigm X. We are all subject to the "better the devil you then the devil you don't" style syndrome. If you embrace object orientation, warts and all, at least for the present, you will gain most.

In addition, it is often a fact of life that most of us tend to fit in learning something new around our existing schedules. This may mean for example, that you are trying to read this book and do the practicals presented while working in C, VisualBasic, Ada etc. either for various assignments or for your employer. From personal experience, and from teaching others about Smalltalk, you will gain most by putting aside a significant amount of time and concentrating on the subject matter involved. This is not only because object orientation is so different, but also because you need to get familiar not only with the concepts but also with Smalltalk and its development environment.

So have a go, take a "leap of faith" and stick with it until the end. If at the end you still can't see the point then fair enough, but until then accept it.

## 2.6 Summary

In this chapter we have reviewed some of the terminology introduced in the previous chapter. We have also considered the types of hierarchy which occur in object oriented systems and which can at first be confusing. We have then considered the pros and cons of object oriented programming. You should now be ready to start to think in terms of objects. As has already been stated, this will at first seem a strange way to develop a software system, but in time it will become second nature. In the next chapter we examine how an object oriented system might be developed and structured. This will be done without reference to any source code as the intention is to familiarize you, the reader, with objects rather than Smalltalk. This is because it is all to easy to get through a book on Smalltalk, C++, Java etc. and understand the text but still have no idea how to start developing an object oriented system.
## 2.7 Exercises

Research what other authors have said about single and multiple inheritance. Why should languages such as Smalltalk and Java not include multiple inheritance?

Look for terms such as class, method member, member function, instance variable and constructor in the books listed in the further reading section. When you have found them, read their explanation of these terms and write down your own understanding of their meaning.

## 2.8 Further reading

Suggested further reading for this chapter include [Coad and Yourdon 1991], [LaLonde and Pugh 1991] and [Meyer 1988]. In additional all the books mentioned in the previous chapter are still relevant.
# 3. Constructing an Object Oriented System

## 3.1 Introduction

This chapter takes you through the design of a simple object oriented system. It does not concern itself with implementation issues nor with the details of any particular language. Instead, the aim of this chapter is to illustrate how the concepts described in the last two chapters can be used to construct a software system. In the remainder of the chapter we describe the application to be constructed. We then consider where to start looking for objects and from there, what the objects should do and how they should do it. We conclude by discussing issues such as class inheritance and answer questions such as "where is the structure of the program?".

## 3.2 The application: windscreen wipe simulation

<figure><img src="image_13.png" /><figcaption>Figure 3.1: The windscreen wash wipe system structure</figcaption></figure>

The aim of this system is to provide a system diagnosis tutor for the equipment illustrated in Figure 3.1. That is, rather than use the wash wipe system from a real car, students on a car mechanics diagnosis course will use this software simulation. The software system will provide a simulation whose behavior will mimic that of the actual system, thus the behavior of the pump will depend on information provided by the relay and the water bottle.

The operation of the wash wipe system is controlled by the wash wipe switch which can be in one of 5 different positions. These are: *off*, *intermittent*, *slow*, *fast* and *wash*. Each of these settings places the system into a different state:

**OFF.** The system is inactive.

**INTERMITTENT.** The wiper motor wipes the wiper blades across the windscreen (or windshield if you are American) every few second.

**SLOW.** The wiper motor continuously wipes the wiper blades across the windscreen.

**FAST.** The wiper motor continuously wipes the wiper blades quickly across the windscreen.

**WASH.** The wash setting is a power wash in which the water pump sprays water onto the windscreen. This water is drawn from the water bottle.

For the pump or the wiper motor to work correctly, the relay must function correctly. In turn the relay must be supplied with an electrical circuit. This electrical circuit is negatively fused and thus the fuse must be intact for the circuit to be made. Note cars (automobiles) are negatively switched as this reduces the chances of short circuits which lead to unintentional switching of circuits.
## 3.3 Where do we start?

This is often a very difficult point for those new to object oriented systems. That is, they have read the basics, understand the simple diagrams they have been presented with, but “where do they start?”. It is the old chestnut, “I understand the example but don’t know how to apply the concepts myself”. This is not unusual and in the case of object orientation is probably normal.

The actual answer to the question “where do I start?” may at first seem somewhat obscure, you should start “with the data”. Remember that objects are based around the idea of having things which exchange messages with each other. These things possess the data which is held by the system and the messages which request actions to be performed that relate to this data. Thus an object oriented system is fundamentally concerned with these data items.

Before we go on to consider the object oriented view of the system, let us stop and think for a while. Ask yourself “where would I start if I was going to develop such a system in C or Pascal or even Ada? In most cases the answer will be with some form of “functional” decomposition. That is, you might think about the main functions of the system and then break them down into sub functions and so on. As a natural part of this exercise the data required to support the desired functionality would be identified. Note that the emphasis would be on the system functionality.

Let us take this further and consider the example presented above and the functions we might identify:

<table><tr><td>Wash</td><td>pump water from the water bottle to the windscreen.</td></tr><tr><td>Wipe</td><td>move the windscreen wipers across the windscreen</td></tr></table>

We would then identify important system variables as well as sub functions used to support the above.

Now let us go back to the object oriented view of the world. In this view we place a great deal more emphasis on the data items involved and consider the operations associated with that data (which is effectively the reverse of the functional decomposition view). This means that we start off by attempting to identify the primary data items in the system, next we look to see what operations are applied to / performed on these data items. Finally, we group these data items and operations together to form objects. Note that in identifying the operations to perform we may well have had to consider additional data items. These additional data items might be separate objects or attributes of the current object. Identifying which is which is mostly a matter of skill and experience.

Note that the OO approach makes the operations a far less important aspect of the design than the data and their relationships. In the next section we will examine what objects might exist in our simulation system.

## 3.4 Identifying the objects

As was indicated in the last section we start off by identifying the primary data objects. In this case we might look at the system as a whole and ask ourselves what indicates the state of the system. We might then say that the position of the windscreen wash switch is important or that the status of the pump is significant. This might result in the following table of data items:

<table><caption>Table 3.1: Data items and their associated state information</caption><tr><td>switch setting</td><td>is it off, intermittent, wipe, fast wipe or wash</td></tr><tr><td>wiper motor</td><td>is it working or not</td></tr><tr><td>pump state</td><td>is the pump working or not</td></tr><tr><td>fuse condition</td><td>has the fuse blown or not</td></tr><tr><td>water bottle level</td><td>the current water level</td></tr><tr><td>relay status</td><td>whether current is flowing or not</td></tr></table>

How these are identified in general will be considered in greater detail in Part 6 of this book. At this point, merely note that we have not yet mentioned the functionality of the system nor how it might fit together, only what are the significant items.

As this is such a simple system we could now assume that each of these elements will be an object and illustrate this in a simple object diagram.
<figure><img src="image_14.png" /><figcaption>Figure 3.2: Objects in simulation system<fnref n="1" /></figcaption></figure>

Notice that I have named the objects after the element associated with the data item (e.g. the element associated with the fuse condition is naturally the fuse itself) and that the actual data items involved (e.g. the condition of the fuse or the level of the water in the bottle) is an instance variable of the object. This is a very common way of naming objects and their instance variables. We now have the basic objects required for our application.

## 3.5 Identifying the services/methods

At the moment all we have are a set of objects each of which can hold some data. For example, the water bottle can hold an integer indicating the current water level. However, although object oriented systems are structured around the data, we still need some procedural content to change the state of an object or to make the system achieve some goal. Therefore, we also need to consider what operations a user of each object might require. Note that the emphasis here is on the *user of the object* and what they will *require of the object* rather than what operations will be performed on the data.

Let us start with the switch object. The switch state can take a number of values such as ‘off’, ‘wash’ and ‘wipe’. As we don’t want other objects to have direct access to this variable we must identify the services which the switch should offer. As a user of a switch we want to be able to move it between its various settings. As these settings are essentially an enumerated type, we can have the concept of incrementing or decrementing the switch position. A switch must therefore provide a `moveUp` and a `moveDown` interface. Exactly how this is done will depend on the programming language used. For now we will just concentrate on specifying the required facilities.

If we continue examining each object and identifying the required services we could end up with the following list:

<table><tr><td rowspan="3">switch</td><td>moveUp</td><td>increment switch value as above</td></tr><tr><td>moveDown</td><td>decrement switch value as above</td></tr><tr><td>state?</td><td>return a value indicating the current switch state</td></tr><tr><td>fuse</td><td>working?</td><td>indicate if the fuse has blown or not</td></tr><tr><td>wiper motor</td><td>working?</td><td>indicates whether the wipers are working or not</td></tr><tr><td>pump</td><td>working?</td><td>indicates whether the pump is active or not</td></tr><tr><td rowspan="3">water bottle</td><td>fill</td><td>fill the water bottle with water</td></tr><tr><td>extract</td><td>remove some water from the water bottle</td></tr><tr><td>empty</td><td>empty the water bottle</td></tr></table>

Note that we have generated the list by examining each of the objects in isolation. The aim was to identify the services which might reasonably be required. We may well identify further services when we attempt to “put it all together” but for the moment we will stick to these.

Each of these services should relate to a method within the object. For example, the `moveUp` and `moveDown` services should relate to methods which change the `state` instance variable within the object. Using a generic pseudo code, the `moveUp` method, within the `switch` object, might resemble:

```python
define method moveUp()
    if state = 'off' then
        state := 'wash'
    else if state = 'wash' then
```

<footnote n="1">¹ The hexagonal shape used in this figure for instances is based on the structured cloud used in version 0.8 of the Unified Modeling Language described in Part 6 of this book.</footnote>
```pascal
state := 'wipe'
endif
end define method
```

This method will change the value of the state variable in switch. The new value of the instance variable will depend on its previous value. `moveDown` could be defined in a similar manner. Note that the reference to the instance variable illustrates that it is global to the object. Also notice that the method `moveUp` requires no parameters. This is common in object oriented systems. That is, few parameters need to be passed between methods (particularly of the same object) as it is the object which holds the data anyway.

## 3.6 Refining the objects

If we look back to Table 3.1, we can see that `relay`, `fuse`, `wiper motor` and `pump` possess an interface `'working?'`. This is a first hint that these three objects may have something in common. Each of them presents the same interface to the outside world. If we then consider their attributes, they all possess a common instance variable. At this point it is too early to be able to say whether relay, pump and fuse are all instances of the same class of object (e.g. a Component class) or whether they are all instances of their own classes which may inherit from some common super class (see Figure 3.3). However this is something we will need to bear in mind later.

<figure><img src="image_15.png" /><figcaption>Figure 3.3: Possible classes for components in the simulation</figcaption></figure>

## 3.7 Bringing it all together

So far we have identified the primary objects in our system and the basic set of services they should present. These services were based solely on what data the objects held. We must now consider how to make our system function. To do this we need to consider how it might be used. In the introduction it was suggested that this system would be part of a very simple diagnosis tutor. The idea being that a student would use the system to learn about the effects of various faults on the operation of a real wiper system, without the need for expensive electronics. We therefore wish to allow a user of the system to operate in the following manner:

1. change the state of a component device,

2. ask the motor what is its new state.

Point 1 is already supported by the `moveUp` and `moveDown` operations on the switch. Similar operations could be provided for the fuse, the water bottle and the relay. In the case of the fuse and the relay we might provide a `changeState` interface. This interface might be implemented by a method which used the following pseudo code algorithm:

```pascal
define method changeState()
  if state = 'working' then
    state := 'notWorking'
  else
    state := 'working'
end if
end define method
```
Point 2 above is more complicated. For the first time we have encountered a situation where we want one object's state (the value of its instance variable) to be dependent on information provided by other objects. If we were to write down procedurally how the value of other objects affected the status of the pump, we might get:

```pascal
if fuse is working then
  if switch is not off then
    if relay is working then
      pump status := 'working'
    else if
    else if
endif
endif
```

This algorithm says that the pump status depends on the relay status, the switch setting and the fuse status. This is the sort of algorithm you might expect to find in a `main()` program. It links all the sub functions together and processes the data.

Of course in an object oriented language (such as Smalltalk) we don't have a main program. In an object oriented system we have well mannered objects passing messages between one another. How then do we achieve the same effect as the above algorithm? The answer is that we must get the objects to pass messages requesting the appropriate information. One way to do that would be to define a method in the pump object which would get all the required information from the other objects and determine the motors state. However, this would require that the pump had links to all the other objects so that it could send them messages. This is a little contrived and loses the structure of the underlying system. It also loses any modularity in the system. That is, if we want to add new components then we would have to change the pump object, even if the new components only affect the switch. This approach also indicates that the developer is thinking too procedurally and not really in terms of objects.

Now let us consider the object oriented view of this system. The pump object only really needs to know what state the relay is in. It should therefore request this information from the relay. In turn the relay must request information from the switches and the fuse. This is illustrated in Figure 3.4.

This figure illustrates the chain of messages initiated by the pump object. That is, the pump object sends a message working to the relay, then:

1. relay sends a message *state* to the switch

the switch replies to the switch

2. relay sends a second message *working?* to the fuse

the fuse replies to the relay

3. the relay replies to the motor

If at this point the pump is working, then the pump object sends on the final message to the water bottle.

4. pump sends a message *extract* to the water bottle.

<figure><img src="image_16.png" /><figcaption>Figure 3.4: Collaborations between the objects for wash operation</figcaption></figure>

In this last case a parameter has been passed with the message, this is because, unlike all the previous messages which were merely requesting state information, this message is requesting a change in state. The parameter indicates the rate at which the pump is drawing water from the water bottle.

Note that the water bottle should not record the value of the pump's status as it does not own this value. That is, if it should ever need the motor's status in the future it should request it from the pump rather than using the (potentially obsolete) value passed to it.
For completeness let us consider the algorithm used in the pump to initiate this process. In Figure 3.4 we assumed that the pump provided the interface `working?` which allowed this process to start. Thus the pseudo code of `working?` for the pump object is:

```python
define method working?()
    self status := relay working.
    if self status = 'working' then
        water bottle extract (self status)
    elif
        end define method
```

You should note a number of points about this method. Firstly it is a lot simpler than the procedural program presented earlier. Secondly, this algorithm only shows us part of the story. It only shows us what is directly relevant to the pump. This means that it can be much more difficult to deduce the operation of an object oriented system merely by reading the source code. Smalltalk alleviates this problem, to some extent, through the use of sophisticated browsers. Finally, at no point do we change the value of any variables which are not part of the pump, although they may have been changed as a result of the messages being sent.

### 3.7.1 Where is the structure?

One of the points made at the end of the last section can be very confusing and off putting to someone new to object orientation. This is because they have lost one of the key elements that they use for helping them understand and structure a software system - the main program body. This is because we are dealing with objects and thus it is the objects and the interactions between them which act as the corner stone of the system comprehension. In many ways Figure 3.4 is the object oriented equivalent of a main program. This also highlights an important feature of most object oriented approaches - graphical illustrations. Many aspects of object technology are most easily explained graphically, e.g. object structure, class inheritance and message chains. This has led to many object oriented design methods being heavily graphical.

Let us now consider the structure of our object oriented system. The structure in this case is dictated by the messages which will be sent between objects. That is, an object must possess a reference to another object in order to send it a message. The resulting system structure is illustrated in Figure 3.5.

<figure><img src="image_17.png" /><figcaption>Figure 3.5: Wash wipe system structure</figcaption></figure>

In Smalltalk this structure would be achieved by making instance variables reference the appropriate objects. How this is done will be considered at a later date. The point to note is that this is the structure which exists between the instances in the system and does not relate to the classes which act as the templates for the instances.

Earlier we discussed the relationship between the fuse, the relay and the pump. We will now come back to this issue to consider the classes used to create the instances. We could just assume that each object is an instance of an equivalent class. This is illustrated in Figure 3.6.a. However, as has already been noted, some of the classes bear a very strong resemblance. In particular, fuse, relay and motor all share a number of common features. Table 3.2 compares the features (instance variables and methods) of these three objects.

<table><caption>Table 3.2: Comparison of Components</caption><thead><tr><th></th><th>fuse</th><th>relay</th><th>motor</th><th>pump</th></tr></thead><tbody><tr><th>instance variable</th><td>state</td><td>state</td><td>state</td><td>state</td></tr></tbody></table>
<table><tr><td>services</td><td>working?</td><td>working?</td><td>working?</td><td>working?</td></tr></table>

<figure><img src="image_18.png" /><figcaption>Figure 3.6: Possible class inheritance relationships</figcaption></figure>

From this table it appears that the only way in which they differ is that they have different names. This would suggest that they are all instances of a common class such as Component (see Figure 3.6.b). This class would possess an additional instance variable name to simplify object identification. However, the problem with making them all instances of a common class is that they must all behave in exactly the same way. This is not the case. We want the pump to start the analysis process off when it receives the message working?. Thus the definition of working? that it possesses must be different from fuse and relay. However, in other ways it is very similar to fuse and relay. Therefore, what we want is for fuse and relay to be instances of a class (say Component) and for pump to be an instance of a class which inherits from Component (but which redefines working?). This is illustrated in Figure 3.6.c.

<figure><img src="image_19.png" /><figcaption>Figure 3.7: The final class hierarchy and instance diagram</figcaption></figure>
## 3.8 Summary

In this chapter you have seen how one, very simple system, can be broken down into objects. These objects combine to provide the overall functionality of the system. You should have seen how the data to be represented determines the objects used and that the inter object interactions determine the structure of the system. You should also have noted that the identification of the objects, their classes, the methods and instance variables is more of an evolutionary process than that used in non object oriented languages.

## 3.9 Exercises

Take a system with which you are familiar and try to break it down into objects. Carry out a similar set of steps to those described above. Do not worry about how you would implement the objects you identify or the classes required to generate these objects. Finally, use whatever representation best fits your way of working for describing what the methods do. If you wish, use a pseudo code, or use a programming language such as C or Pascal if you prefer. You could even use a flow chart if that is what you are most comfortable with. It is very important that you try and do this as it is a useful exercise in learning to think in terms of objects.

## 3.10 Further reading

A good place to start further reading on building object oriented systems is with the first few chapters of
[Rumbaugh *et al* 1991]. In addition [Wirfs-Brock *et al* 1990] is an excellent, non-language specific
introduction to structuring object oriented systems. It uses a rather simplistic approach which is ideal for
learning about object oriented system design, but not really generally applicable. This is not a problem
here as what you want to do at the moment is get the background rather than specific techniques.
Another good references for further reading is [Yourdon 1994].
Part Two

# The Smalltalk Language
# 4. An Introduction to Smalltalk

## 4.1 Introduction

During the nineties the Smalltalk tools market has grown hugely, for example in 1994 in the US the market was worth about $56 million which was a 60% increase on the previous year [Shan 1995]. This is not just an American phenomena, Smalltalk is now taught in universities in China and Russia and the number of American universities teaching Smalltalk doubled in 1994. The growing interest in Smalltalk is fueled by two factors: alleged failures of C++ based projects and stories of successful Smalltalk developments. For example, EDS (Electronic Data Systems) re-implemented a PL/I based application in Smalltalk in order to compare the development costs of the two languages. The results showed a 3:1 or 4:1 productivity increase in design and programming with little or no performance degradation [Taylor 1992]. This has resulted in Smalltalk becoming the natural successor to COBOL (as opposed to C++) in many organizations. For example, of 137 MIS sites using COBOL in the US, that have approved the migration to object oriented techniques, the majority have opted for Smalltalk and of the remainder, 26% of the C++ developers would recommend Smalltalk [Shan 1995].

In this chapter we encounter Smalltalk, its development environment (and in particular VisualWorks) and some of the tools available in that environment. We also learn a little bit about the history of Smalltalk and consider what Smalltalk comprises (in the way of a programming language, a programming system and a development environment).

## 4.2 What is Smalltalk

Smalltalk can be viewed from a number of different perspectives. This differs from most other programming languages in that they can be viewed as a programming language and nothing else. However, Smalltalk (at least as embodied by systems such as VisualWorks) is far more than just a programming language. Below we consider some of the ways of classifying Smalltalk:

* An object oriented programming language. It certainly provides an OO language, that is the syntax and semantics of the language. The language is supported by a number of compilers which take programs written in Smalltalk and produce an executable. As you will see later, they actual tend to produce a byte code form which is then run on a virtual machine. But more on that later. As for the Smalltalk language itself, it is actually very small and rather compact, unlike languages such as Ada, which are very large.

* A programming environment. We refer here to the presence of the 'system' provided objects rather than any particular development environment. Unlike many languages (including C++) Smalltalk has associated with it a large (and fairly standard) set of classes. These classes (which run to over a thousand in some versions of Smalltalk) make Smalltalk very powerful. You will spend most of your time extending the "system" rather than programming from scratch.

In a number of cases these classes provide facilities which would normally be considered to be part of the language in Ada, C and Pascal. The result is that Smalltalk is anything but a small programming system. In many ways Smalltalk takes to the extreme the approach that some other languages take, in that, the basic language is very small and is really little more than a set of building blocks, but these building blocks can be used to provide more complex constructs. However, unlike many other languages Smalltalk does so by providing a common set of facilities.

* An application development environment (ADE). Because of Smalltalk's history, it has an extremely well developed ADE which provides far greater integration and openness than many
other systems. As the browsers, inspectors and debuggers are all derived from the same source, there is also consistency between (some of) the various implementations. In addition, the source code for these tools is also available with the ADE.

Other languages now have similar environments (most notably Visual C++) however, most of them are modeled on those found in Smalltalk implementations and few of them illustrate any pretence of consistency between vendors.

Thus it is quite possible to say that Smalltalk is a programming language, a set of extensible classes, a development environment or even a user interface development tool. It is, in fact, all of these.

## 4.3 Objects in Smalltalk

In Smalltalk everything is an object (or should be treated as an object). For example, the following expression:

$$2 + 3.$$

should be read as the object 2 is sent the message +, with the argument the object 3. In fact in this case for efficiency sake the + message is hard coded into the virtual machine (you will learn about this later). However, if you search for the method + it is there, it is just that its implementation is hidden from you.

This pure object view has some interesting side effects on the language constructs such as conditional statements. They are really messages to the objects *true* or *false* rather than being part of the language syntax. Another example are the iterative control statements (the Smalltalk equivalent of *for* or *while* loops in procedural languages) which are messages to numeric intervals or blocks. You will learn more about these from Chapter 6 onwards.

## 4.4 History

The original goals for Smalltalk were described by Alan Kay in the early 1970s. The initial sketches that formed the basis for Smalltalk were heavily influenced by the idea of classes as an organizing principle (taken from Simula-67), of turtle graphics (taken from the LOGO project at MIT) and of what is now called “direct manipulation” interfaces (inspired by the sketchpad drawing system, developed by Ivan Sutherland at MIT Lincoln Laboratories in the early 1960s, and by Kay’s Ph.D. thesis on the FLEX machine).<fnref n="2" />

Between 1971 and 1975, Kay’s group at Xerox PARC designed and implemented the first real Smalltalk language, environment and applications. This system included a number of technical innovations:

* *The language was based entirely on the Simula concepts of class and message.*

* *The language had no fixed syntax.* Each class was responsible not only for its own behavior and state definition, but even for parsing the token stream that followed a mention of an instance.

The innovations in the development environment were equally radical. At that time bit mapped displays were considered expensive and arcane. Nevertheless, Kay persuaded PARC to allow him to use bit mapped displays, which enabled Kay and his team to implement bit-mapped text in multiple sizes and styles, using multi-windowing environments, plus high level support for bit operations and graphics operations.

The Smalltalk-72 system further took the view that there was no reason for a separate operating system, since the object paradigm could manage all hardware resources at least as easily as any other approach.

By 1975-76, it had become clear that the lack of attention to issues of performance and scale were hampering further investigations. Kay’s group proceeded with a major redesign of all aspects of the Smalltalk system. In the language area:

<footnote n="2">² Note this section is based on information described in a paper by L. Peter Deutsch, called *The Past, Present and Future of Smalltalk*, which was presented at ECOOP’89 [Deutsch 1989].</footnote>
* The idea of inheritance and subclass hierarchy was incorporated into Smalltalk.

* The syntax of the language was fixed. This enabled compilation into an efficient, interpretable, compact (byte encoded), instruction set.

* Introduction of the Browser by Larry Tesler. The Browser vastly increased the productivity of a Smalltalk programmer.

All previous versions of Smalltalk had been implemented on specialist hardware, until in 1977 -78, Bruce Horn and Ted Kaehler ported Smalltalk -76 to a system which incorporated dual Intel 8086 processors with a custom display (called the NoteTaker). Only 10 such systems were produced, however it was a positive demonstration that it would be possible to implement Smalltalk on conventional processors.

### 4.4.1 Smalltalk-80

In 1979-80, partly due to the NoteTaker project, the attention of the Smalltalk team was drawn to the possibility of marketing Smalltalk beyond Xerox PARC. The team designed and implemented yet another generation of Smalltalk systems, this time with some changes specifically aimed at portability and exploitation of standard hardware. These included:

* The adoption of the ASCII character set rather than the special character set used in Smalltalk-72 and -76.

* Smalltalk-80 removed the ability of primitive methods to directly access any memory location. Instead Smalltalk -80 introduced a dozen primitive methods which provided the required functionality. This significantly helped portability.

* The Smalltalk -80 language introduced the concept of metaclass, to provide a way of talking about behavior (messages) that were specific to an individual class. More about this towards the end of this book.

* The Model-View-Controller (MVC) system was introduced for interactive applications. More about this later in the book.

Finally, by 1981 a significant number of the Smalltalk team felt that it was important to take direct action to propagate Smalltalk beyond Xerox PARC. Adele Goldberg, who had by now replaced Alan Kay as head of the group, and Dave Robson, a long time group member, decided to write a series of books about Smalltalk. These books include descriptions of both the language and its implementation. One of the first external implementors of the system was Digitalk. A company set up by Digital to develop and market Smalltalk systems.

### 4.4.2 VisualWorks and commercial versions of Smalltalk

VisualWorks is the commercial product developed and supplied by ParcPlace -Digitalk and is probably the most widely used commercial Smalltalk system. This is at least one of the reasons why this book has a VisualWorks emphasis.

The language itself is now well established in the market place and in 1995 had about 17% of the market in client-server systems development in the USA. Smalltalk systems are now available for Macs, PCs and UNIX boxes and in some cases the same system is available on them all (e.g. VisualWorks).

In the case of VisualWorks, it provides not only the basic set of classes but also screen painting facilities, database connectivity, business graphics as well as interfaces to C and other compiled languages. It also provides generic window support for the programmer, which is translated to whatever windowing system is being used. This means that it is possible to develop a system on a Mac but deliver it on a PC or UNIX box. It is interesting to note that the market in Smalltalk systems (and VisualWorks in particular) is growing rapidly while the market for C++ systems appears to have begun to shrink.

Currently there are a number of implementations of Smalltalk available. These include Smalltalk/V and Visual Smalltalk also from ParcPlace -Digitalk, Smalltalk Express, versions of Smalltalk produced by Fuji Xerox, Sony and NEC in Japan and the GNU project's public domain gSmalltalk. IBM is a relatively new player in this field with its IBM Smalltalk (a standard interface based Smalltalk) and
VisualAge (a version of Smalltalk with a VisualWorks style interface). Hewlett Packard also market a distributed version of Smalltalk called Distributed Smalltalk.

During 1995 there was a big shake-up in the Smalltalk vendor world when ParcPlace systems (the Xerox spin off) and Digitalk merged to form ParcPlace -Digitalk. At the time these two vendors had the lion's share of the Smalltalk market. Their merger produced the largest single Smalltalk vendo r. Quite what the future holds for the products produced by ParcPlace -Digitalk is still unclear. Current reports mention a product called JigSaw which appears to provide the best features of VisualWorks combined with the best features of Vis ual Smalltalk. It is likely that this will mean that the VisualWorks development tools will remain, while Visual Smalltalk's integration with the PC platform will be exploited. This is one of the reasons that this book uses VisualWorks as the basis of the development environment described - future products from ParcPlace-Digitalk are likely to look very similar.

It should be noted, however, that unlike many other programming languages there is currently no
international standard for Smalltalk (although one is in the pipe line - see the ANSI X3J20 draft
standard). This means that, although very similar, each of the commercial versions of Smalltalk is
slightly different. The major differences are associated with their graphical interfaces an d database
connectivity (if any). However, there can be subtle differences between the versions such as the scoping
of variables within blocks of code. The examples described in this chapter and those that follow (as well
as the tools described) are all taken from the VisualWorks system and should be usable with version 1.0
upwards of VisualWorks. They have been tested on versions 1.0, 2.0 and 2.5.

4.5 The Smalltalk environment

One of the major differences between environments such as VisualWorks, and those you may have been
used to, is how development proceeds. You are going to be in for a shock if you have been used to
having a completely un-integrated environment in which you write the program with your favorite
editor (for example, Vi or EMACS), then run that through a compiler (for example, gcc), possibly
needing to use a linker before you are able to create an executable, which you can then run to test if it
works.

Even if you have been used to a rather more integrated environment, as is often found on personal
computers or from commercial software suppliers (e.g. ALSYS Ada), you will be surprised just how
integrated Smalltalk is. For example, as soon as you have written some code, you can accept it (which
not only checks the syntax and attempts to correct spelling mistakes; it also compiles it) and then run it.

To run a piece of code, you don't even have to leave the window you are in, you can just select a
statement which will execute the whole "lump" of code in the same editor window and ask the system
to execute it, which, of course, it will. This means that you can "try out pieces of code" without having
to write large amounts of code which act as a program harness<fnref n="3" />.

As can be seen from this example, the edit / compile / link / execute cycle does not really exist in
Smalltalk. You should therefore try to forget it and attempt to work in a much more exploratory and
interactive manner.

4.5.1 The implementation of Smalltalk

Smalltalk is different to other development environments you may have used in another way; when you
write Smalltalk code it does not execute on your host machine, even when it is "compiled". Instead it
executes in a Virtual Machine, which in turn executes on your host computer <fnref n="4" />. In fact this is part of the
secret behind VisualWorks' portability - you can write code on one hardware platform and, without re -
compilation, run it on another hardware platform with a completely different windowing system. In
effect, your Smalltalk code is always running on the same machine; the Smalltalk Virtual Machine.
There is therefore no concept of an "executable" in Smalltalk terms.

Instead of an executable file, what you build up in Smalltalk is called an “Image”. This however,
holds not only your executab le code, but also the compiler, the editors, debugging tools, class
definitions, instance definitions etc. available within Smalltalk. The image is literally an image of the

<footnote n="3">³ This is not necessarily a new feature for those used to a number of A.I. systems such as POPLOG or LISP, but for those used to Ada or UNIX and gcc, it may be a revelation.</footnote>

<footnote n="4">⁴ When you compile your Smalltalk it is compiled into a byte code format rather tha n a machine executable format. These byte codes are then executed by the virtual machine which has been heavily optimized to give very fast run times.</footnote>
state of your development environment when you saved it. Figure 4.1 illustrates the structure of the
VisualWorks system.

<figure><img src="image_20.png" /><figcaption>Figure 4.1: VisualWorks system structure</figcaption></figure>

When you deliver systems to clients it is possible to cut down to a minimum what you deliver (e.g. you probably won't need to give a client the compiler classes). To do this a number of tools are available including the stripper tool (which strips out those parts of the image you don't need) provided as a utility with VisualWorks.

When you work with a Smalltalk system you should be aware of at least two files (besides your own source files). One is referred to as the *Virtual Machine* (this is also known as the Object Engine ) and one is referred to as an *Image file* (see Figure 4.2). The image file is an “image” of the state of your development at a particular point in time as described above. To actually use VisualWorks you need to run the image on the virtual machine. This means that you can have different images on your file system possessing different sets of classes, in different states, all of which can be run by the same virtual machine. It should be noted, however, that it is only possible to run one at a time on a single invocation of the virtual machine.

<figure><img src="image_21.png" /><figcaption>Figure 4.2: Primary files in VisualWorks</figcaption></figure>

Finally, another file that you should be aware of is the changes file `. This file lists all the modifications you make to any class, as well as the instructions you issue to the system (e.g. to accept some code). In fact it is the changes file which holds the uncompiled version of your source code. The relationship between the files in VisualWorks is thus that illustrated in Figure 4.2. Note that there are in fact other files used by the system (e.g. such as the VisualWorks sources file - called Visual.sou). However, at present you do not need to worry about them.
### 4.5.2 The VisualWorks Launcher and Transcript

<figure><img src="image_22.png" /><figcaption>Figure 4.3: The VisualWorks Launcher and Transcript, a System Browser and a Workspace</figcaption></figure>

When VisualWorks is first started up, the user will see the Launcher and the system Transcript as illustrated at the top of Figure 4.3. This illustrates VisualWorks on a Windows -95 system, however, it looks identical on a Macintosh or a UNIX box.

We shall consider the Launcher and Transcript separately as they will be used by the developer in different ways.

#### 4.5.2.1 VisualWorks Launcher

The VisualWorks Launcher is the primary way in which you will access the tools within the VisualWorks environment. You should think of it as the top menu bar across most PC and Macintosh applications, like the start button on Windows -95 or like the pop-up menu used with many X windows desktops. It is your interface to VisualWorks. From the Launcher you can access all the system browsers (for browsers also read editors), the screen painting tools, the database tools, help, file access tools etc. As you use VisualWorks more and more you will come to know where these tools are and how to use them.

For speed of access a number of the most used tools have button icons below the menu bar. These are (from left to right):

* The file tool (for browsing directories, editing files on the host file system and filing in (a bit like compiling) files).

* The System Browser, which is described below.

* Open a Workspace (see below for an explanation of Workspaces).

* The Screen Painter which is used to easily and quickly construct graphical interfaces.

* The Resource Finder which is used to find window and icon definitions.

* Database tools for working with relational database systems

* The on-line help system.

The most important operations other than those covered above are **Exit VisualWorks ...** and **SAVE AS**. Both of these operations are found under the **File** menu. The **Exit VisualWorks ...** operation allows the user to quit from VisualWorks at any time. This operation brings up a pop-up window with three options, **Exit**, **Save + Exit** and **Cancel**. The **Exit** options quits VisualWorks and the current state of the system is not saved and thus anything that you have done (including coding) since you last saved will be lost. Remember that when you define new classes and methods you are only doing so within the VisualWorks environment, you are not saving anything to file. There is a way to recover anything you have done, if you quit and have forgotten to save your image, which involves the **changes list** which we won't look at yet. The **Save + Exit** option first saves the image and then exits VisualWorks while the **Cancel** option, returns the user to the VisualWorks environment.

The **SAVE AS** operation saves the current state of your VisualWorks environment as an **image**. Look back in this chapter if you are not sure what an image is. This image can be re-started again at a later date.
### 4.5.2.2 System Transcript

The System Transcript is a text window which has the additional property of supporting display operations from expressions as they are executed. It can be referred to using the name **Transcript**. In effect, it is the output window of the VisualWorks system. It is where the system itself reports important information such as when the image was last saved etc.

It is also very useful as a quick way of outputting information, for example by placin g trace statements within code to see exactly what is happening or for displaying the results of computations which do not require sophisticated presentation. For example:

Transcript show: 'John'.

You can do this anywhere within any part of your code because Transcript is actually a global variable and an instance of a class called `TextCollector`. The Transcript (and other `TextCollectors`) respond to the message:

show aString

Other useful messages understood <sup>5</sup> by the Transcript include: `cr` (starts a new line in the Transcript.), `space` (puts a single space in the Transcript) and `tab` (puts a 'tab' in the Transcript).

The Transcript only knows how to print strings. Therefore, to make it easy to print anything in the Transcript, you can use a message called `printString`. All objects understand this message (as it is implemented in the class `Object`). When sent to an object, the result is a printable string which represents the object. The result will be different depending on the class of the object, but you are guaranteed something you can print. The way to use `printString` is:

Transcript show: someObject printString

Type the following into the Workspace (this is the window at the bottom right of Figure 4.3, more information on this window is provided in the next chapter). Once you have typed it in, select it with the left mouse button. Now use the right mouse button to bring up the window menu <sup>6</sup>. This menu has a number of options on it, half way down you will see an option called **do it**. Select this option. The code will then be executed and the results will be printed in the Transcript.

Transcript show: 'Hello World'.

Transcript show: (3 + 4) printString.

Transcript cr.

You have now written your first piece of Smalltalk. This illustrates an important point, that with Smalltalk you will get the most out of any book or course by trying things out. So try things out; explore, be adventurous; it is the quickest way that you will learn.

### 4.5.3 The System Browser

The System Browser allows the user to inspect the definition of any object in the system, and to modify it if required. More than one browser can be displayed simultaneously (indeed it is oft en useful to have a number of browsers open at the same time so that different classes can be considered at the same time).

The **System Browser** is made up of five subviews (or windows) and two complementary items marked **instance** and **class**. By default, the **instance** item is selected; this means that the messages displayed are the ones sent to *instances* of a class rather than to the class itself. Note that each of the subviews has an independent scroll bar. The System Browser is illustrated in the middle of Figure 4.3. In the figure, the object class has been selected (this is indicated in the second window across the top).

From left to right, the top four panes in the System Browser are:

<footnote n="5">⁵ This is an example of Smalltalk terminology. Rather than say that some procedure has been defined for a n object, Smalltalkers say that it understands it.</footnote>

<footnote n="6">⁶ This assumes that you are using a two button mouse, for example on a PC. If your mouse has only one button please refer to the VisualWorks system manuals to find out what the appropriate key sequence is to mimic the second and / or third mouse button. If you have a three button mouse then the middle button is the equivalent of the right button on a two button mouse.</footnote>
**Class categories.** These are groups of classes which are categorized for convenience. One of these categories may be selected (as in the figure); the classes in this category are then presented in the next subview.

**Class Names.** Classes in the selected category are presented. One of these classes may be selected (for example, the class object is selected); various categories of messages are then presented in the next subview.

**Message categories.** These are the categories of messages which can be sent to either instances of the selected class (instance selected) or to the class itself (class selected). One of these categories may be selected; all message selectors in this category are presented in the right-most subview.

These message categories are also known as **protocols**. In the remainder of the chapters we shall refer to this window (pane) as containing protocols and thus it is the protocol window.

**Message Selectors.** All of the message selectors (essentially method names) in the protocol are presented. One of these messages may be selected, its *method* (the code executed when this message is received) will be shown in the lower (code view) area. For example, in Figure 4.3 the `isNil` message is selected.

**The code view window.** This window is used to browse and define classes, write methods etc.

You will find that off the right mouse button (if you have a three mouse button then it is the middle button) each window will produce a different menu. These are the window specific menus. You will make extensive use of them, so get familiar with what is on each menu. Figure 4.4 illustrates each of the menus for each of the five different windows.

<figure><img src="image_23.png" /><figcaption>Figure 4.4: The System Browser Menus</figcaption></figure>

There are a number of other browsers and inspectors in the Smalltalk system, for example the **Protocol Browser** and the **Method Browser**. They are condensed versions of the System Browser which possess specific views onto the class hierarchy or onto a particular class. If you have obtained the advanced programmer's tools with VisualWorks you will also be able to use the **Full Browser**. This is an excellent browser which possesses a few more features than the basic system browser.
4.6 Further reading

A good paper giving some of the (historical) background on Smalltalk is [Deutsch 1989]. As an
introduction to the language of Smalltalk and the VisualWorks environment you would be hard pushed
to find a better book than [Lewis 1995]. If you are only going to buy one other book on Smalltalk, buy
this one. Of course there are also the four Smalltalk -80 books produced by the Xerox people [Goldberg
and Robson 1983], [Goldberg and Robson 1989], [Goldberg 1984] and [Krasner 1983].
# 5. A Little Smalltalk

## 5.1 Introduction

In the last chapter we looked at browsers and the System Transcript, in this chapter we examine Workspaces and inspectors. Workspaces and inspectors are the next most important tools in the Smalltalk system. We then consider the debugger , one of the most useful tools available to the developer. Having looked at all the major development tools you will use (at least for the time being) you are introduced briefly to the Smalltalk language. You will then use the tools available to write some Smalltalk.

## 5.2 The Workspace

Workspaces are a kind of direct interface to the system c ompile. They act a bit like an editor in that you can type Smalltalk code into them, and execute that code immediately. You can define temporary and global variables, create instances of classes, perform arithmetic calculations etc. The only thing you cannot do is define classes and methods (that must be done in one of the browsers). In the following figure, the Workspace is being used to calculate the average of a set of numbers.

To compile code within a Workspace you first select the code using the left mouse button. You then bring up the Workspace operations menu using the right mouse button (if you have a three mouse button you will use the middle button). This menu is also illustrated in Figure 5.1. The fourth grouping on the menu contains **do it**, **print it** and **inspect**. The **do it** and **print it** operations will compile and execute the code. **do it** will merely run the code, while the **print it** operation will also print the result of executing the last expression selected. The result is left highlighted so that you can delete it with the delete key if you no longer require it. Try them out and see for yourself. The **inspect** operation will first compile the code (if required) and then open an inspector (see below) on whatever you currently have selected. It the system was consistent, this option would be called "inspect it".

You can have as many Workspaces as you require open, you are not limited to a single Workspace. Of course on a standard PC or Macintosh screen, you may be limited by space. This highlights another issue, for developing Smalltalk systems, it is often useful to have as much screen "real estate" as you can get. Bigger really is better in this case.

<figure><img src="image_24.png" /><figcaption>Figure 5.1: Using the Workspace</figcaption></figure>
## 5.3 Inspectors

Another type of tool available in the Smalltalk environment are *Inspectors*. Inspectors permit the internal state of an individual object to be viewed. In particular they allow the user to view *and change* instance variables directly. In effect inspectors are to instances as browsers are to class definitions. Unlike other programming language development tools, you can use an *inspector* to change the state of an instance (for example, to set up an object ready for testing a piece of code) as well as examine its contents.

The inspector window is divided into two as shown in Figure 5.2. The left hand side shows the instance variables of the object, while the right hand side shows the contents of those variables. For example, in the figure, the `refs` instance variable has been selected (in the left hand side) while the dictionary contained by that instance variable is displayed (in the right hand side). If the contents is a composite object (that is an object which contains other objects e.g. such as the dictionary shown), then you can open another inspector which will present the contents of that object. To do this you select the *inspect* option off the right (middle on the three button mouse) button menu in the left hand side.

The right hand view of the window not only allows you to examine and change the contents of instance variable, it also allows you to evaluate expressions (just as you can in a Workspace) except that the evaluation happens within the context of the instance. This means that instance and class variables can be referenced in the same way as they can within any method definition.

Note that two inspectors are built into the bottom of the debugger window and can be extremely useful when attempting to decide why something unexpected has happened.

The use of inspectors provides a powerful debugging and testing tool. All objects respond to the message `inspect`; the basic inspector method is implemented in the class `Object`'s instance protocol. Most objects respond by opening an inspector window, labeled with the class of the receiver.

<figure><img src="image_25.png" /><figcaption>Figure 5.2: An example inspector</figcaption></figure>

## 5.4 Notifiers

You should also get familiar with the system notifier, such as those you will encounter when you type in an incorrect Smalltalk expression. These notifiers are there to help you. For example, in Figure 5.3, I have mis-typed show, the system recognizes this and informs me of the fact. If I select the **correct it** option, it will try to find what it thinks I was trying to type. In this case it will give a select list containing the show: message, which I can select. This will replace my misspelling and the code will successfully execute.

<figure><img src="image_26.png" /><figcaption>Figure 5.3: A system notifier</figcaption></figure>
Notifiers can be displayed under a number of circumstances. They can be caused:

* **Accidentally**, by sending a message to an object which has no corresponding method. This is the usual response to a program error.

* **Deliberately**, by typing 'CTRL-C' or equivalent to break into the current execution.

* **Deliberately**, by inserting a breakpoint. We will discuss these later.

* **Accidentally**, by the system running out of memory.

* **Accidentally**, by recursion occurring in the system error handling.

## 5.5 Error processing

Handling run time errors in Smalltalk is slightly different to the way in which run time errors are handled in some other languages. Unlike, for example, C++ on a UNIX box, you do not need to take your core dump and analyze it using another piece of software. Instead, the system indicates the fault and gives you a chance to decide what to do next. One possibility is to interactively fix the problem. This was what was done during the exercise at the end of the last chapter.

<figure><img src="image_27.png" /><figcaption>Figure 5.4: An inspector, notifier and debugger</figcaption></figure>

Figure 5.4 illustrates an exception notifier warning that a message (`newaAddress:for:`) has been sent to an object which does not understand that message. It also illustrates the debugger which would be displayed if the debug option was selected. Finally, it illustrates an inspector examining an instance of class `Object`.

### 5.5.1 Exception notifiers

When a message is sent to an object with no corresponding method, then an exception notifier window (as illustrated in the bottom left hand corner of Figure 5.4) is displayed. This notifier is also displayed if a halt message (a breakpoint) is encountered. The exception notifier has a number of options which allow the programmer to determine what should happen next. The options are:

* **Debug** This closes the notifier view and opens a debugger view on the error condition.

* **Proceed** Continue as if the error had not occurred.

* **Terminate** This terminates the current evaluation.

* **Copy Stack** This copies the current state of the execution stack.
* Correct it This allows the user to correct the fault.

### 5.5.2 Types of run time error

When encountering a new language for the first time, it is quite common to get extremely frustrated while you attempt to determine why a piece of code is causing a run time error. This often turns out to be caused by a trivial fault which would have been dealt with immediately if you had been working in a language with which you were familiar. This sort of problem afflicts us all and is the source of a great deal of resistance to change. However, the problems can be eased somewhat if you are aware of the types of root causes for different failures. The following list attempts to ease this sort of problem. It presents the types of run time error (other than incorrect message sends) which can occur:

* Sending a message to an object which does not respond to that message.

* Trying to create an instance of Character or Boolean.

* Trying to create instances with inappropriate instance creation messages.

* Evaluating a block (instance of BlockContext) with the wrong number of arguments.

* Numeric errors, such as divide by zero, or square root of a negative number.

* Lots of collection errors, such as trying to remove an element not in a collection, or trying to use the `add:` message on a collection class which does not support `add:` for example `Array` etc.

* Sending a message to an object where the corresponding method should have been defined in a subclass. This can be identified by finding the following statement in a method:

```python
self subclassResponsibility
```

* Control messages to objects which are not `Booleans` (if True) or `Blocks` such as `[]` (while True:).

## 5.6 Some Smalltalk

Let's look at a little Smalltalk, just to get you going. You have already seen (and possibly written) some Smalltalk when you typed in the Smalltalk version of the "Hello World" program in the last chapter. Now let's add two numbers together. First we shall do it in a non-object oriented language such as Pascal. For example, we might write:

```python
int a, b, c;
a := 1;
b := 2;
c := a + b;
```

This says something like, "create three variables to hold integer values (call them a, b and c). Store the value 1 into the variable a and 2 into variable b. Add the two numbers

together and save them into the third variable c".

Now let's look at how we could write the same thing in Smalltalk.

```text
| a b c |
a := 1.
b := 2.
c := a + b.
```

As you can see this looks basically the same (apart from the use of a full stop (also known as a period) instead of a semi-colon). We also apparently forget to declare the types of the

variables a, b and c (and put some bars around them).

However, although the effect is the same, and the look similar, the meaning is dramatically different. In Smalltalk, this actually says:

> "Define three temporary variables a, b and c (we don't care what they will hold). Assign the object 1 to variable a. Assign the object 2 to the variable b. Take the object in a, which has the value 1, and send it the message "+", which includes the argument b, which in turn has the value 2. Object a, receives the message and performs the action requested. This action is to add the value of the argument to itself. Create a new object and return this result as the result of evaluating the message. Then save this object into the variable c."
These concepts of messages, receivers, objects etc. will be explained in a later chapter. Hopefully, by the end of this book you will read the above definition and say “of course”.

# 5.7 Working with Smalltalk

## 5.7.1 Open a VisualWorks image

First of all start up your current VisualWorks image, for example, on a UNIX system you might enter:

```
visualworks Visual.im
```

If this is not local you may need to specify a path name for the object engine or the image. For example, if you are on a UNIX system:

```
/usr/local/ visual/bin/visualworks /usr/jjh/visual.im
```

If you are using a Macintosh or a Windows -95 PC then you just double click on the image file and the VisualWorks virtual machine will be used to open it.

Once you have started VisualWorks, save the image to your own file store and exit. To do this, first select the **save as** option off the file menu on the VisualLauncher. You will be requested to provide a name for your image. Note that if you do not give a path name as well as the image name, the image file will be saved in the current directory.

Once you have created the image file, you can exit from VisualWorks. To do this you select the Exit option (again from the File menu on the VisualLauncher).

## 5.7.2 Selecting, compiling and executing Smalltalk

If you have not already done so, type the following into the Workspace:

```
Transcript show: 'Hello World'.
Transcript cr.
Transcript show: (3 + 4) printString.
Transcript cr.
```

Select the text and **do it**. That is, select the text with the left mouse button, then bring up the right (or middle on a three button mouse) mouse menu and select the **do it** option. You should then see the phrase "Hello World" and the number 7 appear in the Transcript window.

## 5.7.3 Using some VisualWorks tools

In many books you are presented with some source code to type in and execute, but are given very little guidance on how to deal with errors etc. Therefore in this section, you get to type in some (intentionally buggy) Smalltalk code and to compile it. This forces you to use tools such as the debugger to identify and correct the errors. After all, at this stage, it is likely that you will write buggy Smalltalk rather than perfect Smalltalk.

Type in the following exactly as it is (there are errors included so that you get some practice using the tools available in Smalltalk).

```
| temp |
temp := Set New.
temp add: 'John'.
temp add: 'Paul'.
temp add: Peter.
temp do: [[:item | Transcript show item]].
temp inspect.
```

Now select all the code and “do it” as before. You should now get a dialog box such as that illustrated below:
<figure><img src="image_28.png" /></figure>

This dialog box indicates that New is not understood by the class Set (note the terminology). This is an example of how Smalltalk (and VisualWorks in particular) attempts to help you if it finds a message it does not understand. In this case it did not understand "New". It identified this as a problem and is now allowing you (the user) to

* **Abort** and correct the error yourself,

* **Proceed** as though nothing had gone wrong (however it would probably fail in another way immediately) or to

* **Correct it**, the error, with the system's help.

The correction option is illustrated below. Click on the "correct it" option. You will then see the following selection box:

<figure><img src="image_29.png" /></figure>

Select "OK".

This is an example of how Smalltalk attempts to help you if it finds a message it does not understand. In this case it did not understand "New", but it found that Sets do understand "new". As "new" is very similar to "New", Smalltalk presented it as a possible alternative.

Once you have selected "OK" on the selection dialog, you should then see the following dialog.

<figure><img src="image_30.png" /></figure>

For the moment select "proceed". The problem here is not actually with item, but is a feature of another problem which we will come back to later. Once you have selected "proceed" you will then see:

<figure><img src="image_31.png" /></figure>

This dialog was generated because, *Peter*, does not have single quotes around it (single quotes are used to indicate a string). The system therefore assumes that it is a variable which has yet to be defined.

At this point press "cancel". You should find that *Peter* is higlighted in the Workspace. This illustrates how VisualWorks attempts to point out where the problem is. Now place single quotes around *Peter*, e.g.

`temp add: 'Peter'.`

Next re-select the whole lot and "do it" again. You will again see a dialog warning you that item isn't defined. For the moment select proceed.

You will now get an Exception raised. This is because the Transcript object does not understand the message "show". The dialog you see should look like this:
<figure><img src="image_32.png" /></figure>

Select the "Debug" option. This will open a debugger on the error code. Now select the second line down in the top window. This should start with `optimized []`. The debugger with this line selected is illustrated below:

<figure><img src="image_33.png" /></figure>

In the top scrollable window of the debugger you see each method which has been executed, in the window below this, you see the source code relating to the method. In this case you see a "decompiled" version of the code you wrote in the Workspace displayed. It is decompiled because you typed the original code into the Workspace rather than into a class. It therefore had no class to refer back to. You will know decompiled code from original source code for two reasons. Firstly, there will be a comment telling you that it has been decompiled and secondly the variables will have names such as `t1` and `t2` rather than the variable names you chose.

In the debugger you can identify the point at which the error was caused because it will be highlighted. That is, the message "show" will be in bold. You can correct the error by changing "show" to "show:".

You could now fix the problem here (and when you are debugging methods on actual classes you may well do so). However, there is no point doing so this time, as this is the decompiled version of your original. Thus any changes you make here will be lost once this run is completed (in addition the item following `show` has not been compiled yet and therefore remains as item where as the temporary variable at the beginning of the `do:` statement has been decompiled to `t2` - rather than `item`). It would therefore be better to go back to the Workspace and fix it there.

You should change the `show` statement to read:

temp do: [:item | Transcript show: item]

Now select all the code and "do it" again. This time the contents of the `set shou`ld be printed in the Transcript.

Notice that the order in which you input the strings may differ from the order in which they are printed. This is due to the way `add:` works (why not have a look and see for yourself).
Finally, you should see an **inspector** window displayed. Try clicking on some of the left hand items.

<figure><img src="image_34.png" /></figure>

The left hand view of the window shows instance variables (such as tally) and positions (e.g. 1 - 7) and the right shows the contents of the variables (e.g. the string 'John').

Here is a question for you to ponder on and experiment with: "What happens when the 8th item is added to this set?"<fnref n="7" />

## 5.8 Summary

By now you have used a number of Smalltalk tools, run VisualWorks (or whatever Smalltalk system you are using) and written some Smalltalk code. You have also had the chance to use some of the tools available to help you debug your code. You are now ready for the Smalltalk language itself!

## 5.9 Further reading

If you are going to do any serious development in Smalltalk then you should consider obtaining at least Vol. 1. of Inside Smalltalk [Lalonde and Pugh 1991] (which concentrates on the language) if not Vol. II. [Lalonde and Pugh 1991b] (which concentrates on the graphical facilities).

However, by far my own favorite book is [Hopkins and Horan 1995]. This is a very good introductory book on Smalltalk using the VisualWorks 2.0 system. Indeed it is based closely on the courses that were run by the University of Manchester by the authors and by the commercial suppliers of VisualWorks. This means that the material in the book has been "debugged" over a number of years. In particular it covers much of the same material as is in Part II of this book but spends much more time on the use of the graphical facilities in Smalltalk. It also goes into a great deal of detail about the tools in VisualWorks and how to use. However it does not cover issues such as 'what is object orientation in much detail', nor does it attempt to guide the novice through the application of object orientation to developing a system.

<footnote n="7">⁷ Answer: it grows. Try it for yourself - remember to use the inspector to examine the contents of the set.</footnote>
# 6. Smalltalk Building Blocks

## 6.1 Introduction

The aim of this chapter is to present an introduction to the Smalltalk Programming Language. The scope of this chapter is to describe some of the features of the Smalltalk language. As such it is not intended to be a comprehensive guide to the Smalltalk language. For a detailed description of the Smalltalk language's syntax and most commonly used constructs see, Appendix 1.

The remainder of the chapter is structured in the following manner: Section two introduces the basic elements of the Smalltalk language. Section three discusses the concept of classes and instances in Smalltalk and how they are defined. Section four presents methods and method definitions.

## 6.2 The basics of the language

Smalltalk is a completely object oriented language and as such has no other concept other than object. The actual language is very, very small, however the Smalltalk system (as exemplified by VisualWorks) is very big. All Smalltalk programmers make extensive use of the existing classes even when they are writing relatively trivial code. For example, even when a programmer writes the following version of the traditional "Hello World" program they are reusing existing classes (rather than just using the language):

```Smalltalk
| myName |
myName := 'John Hunt'.
(myName findString: 'Hunt' startingAt: 1)
  ifTrue: [Transcript show: 'Hello ', myName]
  ifFalse: [Transcript show: 'Hello World'].
```

In this example, I have reused the `String` class to represent the string 'John Hunt' and to find a substring in it using the message selector `findString:startingAt:`. Some of you may say that there is nothing unusual in this and that in many languages string handling facilities are extensions to the language. However, in this case, the result of the test is an instance of either `True` or `False` (subclasses of `Boolean`) and that this message receives the message `ifTrue:ifFalse:`. What is printed to the Transcript object depends on which object actually receives the message. Thus, `ifTrue:ifFalse:` is not part of the language but a method defined in a class. In most languages the `if-then-else` construct would be an inherent part of the language - in Smalltalk it is not. This is because everything is an object in Smalltalk, thus all language constructs are messages sent to objects. This feature also illustrates the extent to which existing classes are reused - that is, you can't help but reuse existing code in Smalltalk because you do so by the very act of programming.

As well as possessing a completely object oriented programming paradigm, Smalltalk also possesses an inheritance mechanism. It is this feature which separates Smalltalk from object based languages such as Ada - they do not possess inheritance.

The availability of inheritance is very important in Smalltalk. For example, it promotes the reuse of classes as well as enabling the explicit representation of abstract concepts (such as the class Collection) which can then be turned into concrete concepts (such as the class Set). It is also one of the primary reasons why Smalltalk is so successful as a rapid application development tool - you inherit much of what you want and only define the ways in which your application differs from what is already available.
### 6.2.1 Some terminology

We will now recap some of the terminology introduced in Part 1 of this book, however we will explain this terminology with reference to Smalltalk.

In Smalltalk programs are run or actions are performed by passing *messages* to and from objects. A *message* is a request for some procedure (referred to in Smalltalk terms as a *method*) to be performed by the object receiving the message (referred to as the *receiver* of the message). The object which sent the message in the first place is referred to as the *sender*. Just as procedure calls can contain parameters, so can messages. In addition, just as in some functional languages, all *method* executions result in a *response* being returned to the sender.

Smalltalk is not a *strongly typed* language. That is, you do not specify that a variable will take a certain type of data structure. Nor does the compiler attempt to check what types a variable possesses. However, it is not true to say that Smalltalk is not typed. Each object is an instance of a class. These classes give an object a type (as defined by the class). It is possible to send a message to an object to determine the type of its class. Smalltalk is thus a dynamically typed language. This is a feature of Smalltalk which promotes its abilities as a rapid application development tool. It also enables the polymorphic facilities available to be utilized appropriately.

### 6.2.2 The Smalltalk message passing mechanism

The Smalltalk message passing mechanism is somewhat like a procedure call in a conventional language. That is:

* The point of control is moved to the receiver; the object sending the message is suspended until a response is received.

* However, the receiver of a message is *not* determined when the code is created (at compile time) but is identified when the message is sent (at run time).

This *dynamic* (or *late*) binding mechanism is the feature which gives Smalltalk its polymorphic capabilities (see Chapter 1 for a discussion of polymorphism).

Another difference between the message passing mechanism of Smalltalk and the procedure call mechanisms of other languages, is that much of what one would consider the basis of the language are implemented using message passing (for example the equivalent of control and iterations structures). This means that not only is message passing fundamental to the language, it is also a critically important feature of the performance of the language.

### 6.2.3 Smalltalk statements

In the remainder of this chapter you will encounter a number of pieces of Smalltalk. It is therefore useful to introduce you to one of the features of the Smalltalk language; the statement terminator. In Smalltalk this is the full stop (or period). For example:

Transcript show: 'Hello World'.

Thus the majority of statements will terminate with a `.`. There are a few situations in which it is not necessary to terminate a statement with a full stop. However, in these situations it is often a good idea to do so. In this and following chapters, we shall adopt the convention of always terminating a statement with a full stop (period).

## 6.3 Classes

A class is the basic building block in Smalltalk. Classes act as *templates* which are used to construct instances. This means that programmers can specify the *structure* of an object (i.e. what instance variables etc. it will possess) and the function of an object (i.e. what methods it will have) separately from the objects themselves. This is important, as it would be extremely time-consuming (as well as inefficient) for the programmer to have to define each object individually. Instead, they define a class and create *instances* of that class.
### 6.3.1 Class definitions

In Smalltalk the format of a class definition is the following:

```
NameOfSuperclass subclass: #NameOfClass
    instanceVariableNames: 'instVarName1 instVarName2'
    classVariableNames: 'ClassVarName1 ClassVarName2'
    poolDictionaries: ''
    category: 'Class protocol'
```

It is not necessary to remember this format precisely as the Smalltalk browsers will present the above as a template for you to fill out whenever you wish to define a new class. The following is an example of a class definition:

```
Object subclass: #Person
    instanceVariableNames: 'name age'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Example classes'
```

This definition states that I wish to define a new class, `Person`, which will be a subclass of the `Object` class. My new class will possess two *instance variables* called `name` and `age`. It will have no class variable(s) or pool dictionaries (we will discuss these later). Finally, it will be part of the class category 'Example Classes'. This last field is normally filled in for you by the system. It is derived from whatever class category you are in when you attempt to define the new class.

Note that our class name is currently a symbol (see below for an explanation of a symbol) denoted by a #. This is because we have not defined it yet and it is therefore not a class name. An error would be raised if we tried just to use it as class name in the definition. As soon as the definition is complete, we can forget about the #.

However, classes are not just used as templates, they have three further responsibilities which include; actually holding the methods, providing facilities for inheritance and creating instances. We shall consider each of these separately below.

### 6.3.2 Classes and messages

When a message is actually sent to an object requesting it to perform some service, it is not the object which possesses the method but the class. This is for efficiency reasons. For example, if each object possessed a copy of all the methods defined for that class then there would be a great deal of duplication. Instead, only the class possesses the method definitions. Thus when an object receives a message, it searches its class for a method with the name in the message. If its own class does not possess a method with the appropriate name, it goes to its class's superclass and searches again. This search process continues up the class hierarchy until either an appropriate method is found or the class hierarchy terminates (with the class `Object`). If this happens an error is raised.

If an appropriate method is found, then that method is then executed *within the context of the object*. This means that although the definition of the method resides in the class, the method executes within the object. Thus different objects can be executing the same method at the same time but without any conflict.

Do not confuse methods with instance variables. Each instance possesses its own copy of the *instances variables* (as each instance possesses its own state). Figure 6.1 illustrates this idea more clearly.

### 6.3.3 Instances and instance variables

In Smalltalk objects are instances of classes. All instances of a class share the same responses to messages (methods), but they will contain different data (i.e. they will possess a different "state"). For example, the instances of class `Point` will all respond in the same way to messages inquiring about the value of the x coordinate, but may provide different values.

The class definition consists of variable declarations and all method definitions. The different state of each instance is maintained in one or more instance variables.
<figure><img src="image_35.png" /><figcaption>Figure 6.1: Multiple instance variables but a single method</figcaption></figure>

In Figure 6.1 there are four instance of the class `Person`. Each instance contains copies of the instance variable definitions for `name` and `age`. Thus enabling them to have their own values for these instance variables. In contrast, each instance references the single definition for the method `birthday` which is held by the class.

### 6.3.4 Classes and inheritance

It is through classes that an object can inherit facilities from other types of objects. That is, a subclass inherits properties from its superclass. For example, in the `Person` definition above, we stated that `Person` was a subclass of `Object`. Therefore, `Person` inherits all the methods and instance variables etc. which were defined in `Object` (except those that were overwritten in `Person`). Thus, subclasses are used to refine the behavior and data structures of a superclass. It should be noted that Smalltalk supports single inheritance while some of the object oriented languages (most notably C++) support multiple inheritance. Multiple inheritance is where a subclass can inherit from more than one superclass. However, difficulties can arise when attempting to determine where different methods will be executed.

#### 6.3.4.1 An example of inheritance

To illustrate how single inheritance works consider Figure 6.2. We will assume that we have three classes called `Class1`, `Class2` and `Class3`. `Class1` is a subclass of `Object`, `Class2` is a subclass of `Class1` and `Class3` is a subclass of `Class2`.

When an instance of `Class3` is created, it contains all the instance variables defined in classes 1 to 3 and class `Object`. If any instance variable possesses the same name as an instance variable in a higher class, then only one instance variable of that name will be created. We do not need to consider which one is created as they are both instance variables which can take any value (Smalltalk is not strongly typed remember!).

When we have an instance of `Class3` we can send it a message requesting that a particular method is executed. Remember that methods are held by classes and not by instances. This means that the system will first find the class of the instance (in this case `Class3`) and search that class for the required method. If the method is found, then it is executed and the search stops. However, if the method is not found, then the system will search `Class3`'s immediate super class; in this case `Class2`. This process is repeated until the method is found. Eventually, the search thrives through the superclasses may reach the class `Object` (which is the root class in the Smalltalk system). If the required method is not found here, then the search process terminates and the `doesNotUnderstand:` method in the class `Object` is executed instead. This method causes an exception to be raised stating that the message sent to the original instance is not understood.
<figure><img src="image_36.png" /><figcaption>Figure 6.2: Class inheritance in Smalltalk</figcaption></figure>

This search process is repeated every time a message is sent to the instance of `Class3`. Thus, if the method which matches the original message sends a message to itself (i.e. the instance of `Class3`), then the search for that method starts again in `Class3` (even if the original method was found in `Class1`).

#### 6.3.4.2 The Yo-Yo problem

The process described above can pose a problem for a programmer trying to follow the execution of the system by tracing methods and method execution. This problem is known as the Yo-Yo problem (see Figure 6.3). It occurs because, every time you encounter a message which is sent to "self" you must start searching from your own class. This may result in the programmer jumping up and down the class hierarchy.

<figure><img src="image_37.png" /><figcaption>Figure 6.3: The Yo-Yo Problem</figcaption></figure>

The problem occurs because you know that the execution search will start in the current instances class, even if the method which sends the message is defined in a superclass of the current class. In the figure, the programmer starts the search in `Class3`, but finds the method definition in `Class1`, however this method sends a message to "self" which means that the programmer must restart the search in `Class3`. This time, the method definition is found in the class `Object` etc. Even with the browsing tools provided, this can still be a tedious and confusing process (particularly for those new to Smalltalk).

### 6.3.5 Instance creation

Classes are also the things which construct the instances. They do so in response to a class message. It is probably confusing, but classes can possess class specific methods as well as class instance variables. These are often referred to as class side methods and variables. They can then respond to a message as an instance would (this is because classes are in fact special instances - we will discuss this in a later chapter. For the moment merely accept that classes can be sent messages).

The message most commonly sent to a class is the message `new`. This message causes a method to execute which constructs a new instance of the class. This process is referred to as instantiation. You do not need to know the details of this process. An example of sending the message `new` to a class `Person` is presented below:

Person new.
The result of sending this method is illustrated in Figure 6.4 along with the structure of a class. The class *Person* receives the message new which causes the class *Person* to execute a method new which generates a new *instance* of the class, with its own copy of the instance variables *age* and *name*.

<figure><img src="image_38.png" /><figcaption>Figure 6.4: Instance creation</figcaption></figure>

The issue of classes having methods, some of which are intended for an instance of the class, and some of which are intended for the class, is not as complicated as it may at first seem. Not least because the tools used with Smalltalk tend to keep the two sides of the classes pretty well distinct. In an attempt to make it clearer here are some definitions:

* **Instance variables**: Defined by the class, but a copy is maintained in each instance which has its own value for that instance variable.

* **Class variables**: Defined in the class with a single copy in the class accessible by instances of the class.

* **Class instance variables**: Defined in the class with a single copy in the class and only accessible by the class.

* **Instance methods**: Defined in the class with a single copy maintained in the class but executed within the context of an object.

* **Class methods**: Defined in the class with a single copy maintained in the class and executed within the context of the class.

Some of these concepts will be considered in greater detail later.

### 6.3.6 Classes in Smalltalk

There are very many classes in any Smalltalk system, e.g. in VisualWorks there over 1,000 classes. However, you will only need to become familiar with a very few of them. The remaining classes provide facilities that you use without even realizing it.

## 6.4 Method definitions

Methods provide a way of defining the behavior of an object i.e. what the object does. For example, a method may change the state of the object or it may retrieve some information. A method is the equivalent of a procedure in most other languages. A method can only be defined within the scope of an object (and there is no concept such as the main method as there is in C). It has a specific structure:

```
messagePattern arguments
  "comment"
  | temporaries
  | statements
```

where the **messagePattern** represents the name of the method and the **arguments** represent the names of arguments. These arguments are accessible within the method.

The **"comment"** field is a comment describing the operation performed by the method and any other useful information. Note that comments cannot be nested in Smalltalk. This can be awkward if you wish to comment out some code for later. For example, consider the following piece of Smalltalk which I have just commented out:

```
x := 12 * 4.
```
```
```
```
Now calculate y
y := x * 23.
```

The Smalltalk compiler would read this as a comment ``, followed by the code `Now calculate y`, followed by another comment. This is (almost) certainly going to cause an error.

The `| temporaries |` format is used to define variables which are local to the method. They must be declared at the beginning of the method (just after the message pattern) and are initially `nil`.

The **statements** represents any legal set of Smalltalk statements. These statements are used to implement the behavior of the method.

One of the uses of methods is in providing an interface between an object's internal data and the outside world. Such methods are often termed accessor methods. Such a method retrieves the value of an instance variable and makes it available to other objects. For example, the class `Employee` has two instance variables `age` and `name`. A method implemented in `Employee` returns the age of an employee. Thus in response to the message `age`, this method would be executed and the value of the employee's age returned to the object sending the message.

In this situation the employee's age is held explicitly. An equally valid internal representation for an `Employee` would be to have an instance variable `dateOfBirth`. The method `age`, would now need to take the date of birth away from the current date, in order to obtain the employees' age.

Note that this would be a change to the implementation of `Employee`, but there would be no visible change as far as any other object in the system is concerned. This illustrates the encapsulation possible within Smalltalk (and other OOP languages).

### 6.4.1 The ^ (or return) operator

Once a method has finished executing, an answer is returned to the sender of the message. By default the object returned is the receiver itself (i.e. self). However, other objects can be returned by use of a `return` expression - an expression preceded by an up arrow (`^`). The return expression must be the last expression executed in a method. This does not mean that it must be the last expression in the method, merely that it is the last executed. For example:

```
C Version                      Smalltalk
if (x == y)                    (x = y)
    return x;                 ifTrue: [^x]
else
    return y;                 ifFalse: [^y].
```

In this case, either the value of `x` or `y` will be returned depending upon whether `x` and `y` are equal or not.

### 6.4.2 An example method

Let us compare a procedure definition in a language such as C with the Smalltalk equivalent. We will assume that we wish to define a procedure to take in a number, add 10 to it and return the result.

```
int myAdd (int x)      myAdd: aNumber
{ int result;
    result = x + 10;
    return result;
}
```
```
| result |
result := aNumber + 10.
^result.
```

From this example you will see that although the format is different you should soon be able to get used to it. Let us look at some of the constituent parts of the method definition. The method name (and its message selector) is `myAdd:`. Note that because this method takes a parameter, the method name must have a trailing colon. It has one parameter called `aNumber`. Just as in any other language, this parameter variable is limited to the scope of this method. The method also defines a temporary variable (`result`) which is also limited to the scope of this method.

Variable names are identifiers containing only letters and numbers which must start with a letter. Some examples are:
anObject MyCar totalNumber

A capitalization convention is used consistently throughout Smalltalk and most Smalltalk programmers adhere to this standard which it is therefore advisable to follow:

* Private variables (instance/temporary variables) start with a lower-case letter.

* Shared variables (class/global/ pool variables) start with an upper-case letter.

Note that *message selectors* should start with a lower-case letter.

Another convention worth noting is that if a variable or a message selector combines two or more words, the convention is to capitalize the first letter of the second word onwards. E.g. `displayTotalPay`, `returnStudentName`.

If we consider our new method above, we have still to consider what happens in the assignment statement (`:=`). We shall look at this in the next chapter along with the range of arithmetic functions available.
# 7. Smalltalk Constructs

## 7.1 Introduction

This chapter presents more of the Smalltalk language. Section two considers the representation and use of numbers in Smalltalk while Section three considers strings and characters. Section four discusses variables in Smalltalk and Section five literals and variables. Sections six considers messages, message types and their precedence.

## 7.2 Numbers and operators

### 7.2.1 Numeric values in Smalltalk

Numbers in Smalltalk are all objects, that means that they are instances of a class. For example, integer numbers such as 2 are an instance of the class `SmallInteger`. In fact there are a number of classes which together provide for the types of numbers normally used, these include `SmallInteger`, `LargePositiveInteger`, `LargeNegativeInteger`, `Float` and `Double`. These will all be considered in greater detail later in the book. For the moment we will just consider what numbers look like in Smalltalk.

Just as in most programming languages, a numeric value in Smalltalk is a series of numbers which may or may not have a preceding `-` and may contain a decimal point. For example:

25 -10 1996 12.45 0.13451345 -3.14

It is also possible to specify numbers in bases other than 10. This is done by preceding the number with the base and the letter r (which stands for radix). For example:

2r101 16r452

Numbers can also be expressed using scientific notation using the 'e' (for exponent) or 'd' (for double-precision) suffix plus the exponent in decimal. For example:

10e3 which equals 1000

In addition to integers and real numbers, Smalltalk also explicitly supports fractions (e.g. 7/8) and radians. In all other ways numbers in Smalltalk are just like numbers in any other language.

### 7.2.2 Arithmetic operators

<table><caption>Table 7.1: Numeric operators</caption><tr><td>+</td><td>addition</td><td>*</td><td>multiplication</td></tr><tr><td>-</td><td>subtraction</td><td>/</td><td>division</td></tr><tr><td>//</td><td>modulus</td><td>quo</td><td>quotiant</td></tr><tr><td>rem</td><td>remainder</td><td>\</td><td>remainder from modulo division</td></tr><tr><td>&lt;</td><td>less than</td><td>&lt;=</td><td>less than or equal to</td></tr><tr><td>&gt;</td><td>greater than</td><td>&gt;=</td><td>greater than or equal to</td></tr><tr><td>max:</td><td>maximum</td><td>min:</td><td>minimum</td></tr><tr><td>ceiling</td><td>roundup</td><td>floor</td><td>round down</td></tr></table>