(Smalltalk Textbook 49)
This final section of the Smalltalk Textbook provides a summary of OOP (Object-Oriented Programming). I don't consider OOP to be a modern programming style, because OOP is already 1/4 century old. OOP is characterized by terms such as class, instance, method, inheritance, polymorphism and so on. I do not think you need definitions of these terms because a lot of OOP books already cover them.
Instead, I'd like to discuss how Smalltalk can make your OOP come alive. In other words, what is appropriate OOP for Smalltalk.
After more than 10 years of Smalltalk programming, I believe there is an important distinction between 'this' and 'self.' By 'this' I mean the typical data structures used in non-OOP prgramming such as C or Fortran. My feeling in Fortran is that data is in some sense given to the CPU to process.
As a new Smalltalk programmer, you find yourself slightly uncomfortable with the word 'self.' For so long it has always referred to you personally, and now it refers to an object with data and behavior. There is a conceptual hurdle to overcome so that using 'self' becomes comfortable to you. 'Self' changes my view from "giving data to the cpu" to sending a message to an object and requesting that it provide some service. When an object receives a message, it tries to provide a service by using resources it knows about or is responsible for. The object comes to the foreground as a reflexive pronoun named 'self.' Notice carefully how related the words 'myself', 'yourself', 'itself' are. Recursion involves repeatedly sending the same message to 'self.'
In my opinion, a genuine OOP in Smalltalk requires the author to understand the difference between 'this' and 'self.'
Open a Workspace, type 'self' (not including the quotes), then highlight 'self' and choose 'print it' from the yellow-button menu. You will see 'nil'.
Next, open a Browser and make sure no class is selected. Type 'self' in the bottom pane and, again, 'print it'. You will see 'nil'.
Now, select a class you like and repeat 'print it' with 'self' highlighted. This time you'll see the class name rather than 'nil'.
One of the essential differences between a Workspace and a Browser is that a program you write in the Workspace is not associated with any class. In contrast, if a class is selected in the Browser, 'self' will refer to that class. If no class is selected in the Browser, it is just like the workspace in this regard.
Skillful Smalltalk OOP programmers create programs in a Browser for a certain class rather than the Workspace. Even beginners do not often write programs in the Workspace except to test small sections of code. I rarely create programs in the Workspace, because the Browser suffices.
There is a big difference between programs in the Workspace and those in the Browser. The Workspace is a wide open plane with lots of breathing room, like a text editor for the BASIC language. In contrast, the Browser feels like a certain class is constraining me, forcing me into a structured, cramped place.
The inside of the Smalltalk Browser is like a bookshelf which is partitioned by class categories, classes, class or instance selection, message categories, and messages. Actually, the Browser is a tool which segments a problem domain into conceptual pieces. It also teaches the programmer through the appropriate partitioning of the problem space.
The expert Smalltalk OOP programmer uses the Browser to transform himself into an object and view the world through the various protocols. Let me walk you through an example.
First, select the 'Magnitude-Numbers' class category in the Browser to enter that partition. Then, select the 'Integer' class to enter that partition, and click the instance button to became an instance of 'Integer'. Next, select the 'arithmetic' message category to became an integer example like 2 or 3. Now you feel the possiblities of arithmetical computation as an integer. Finally, select the 'abs' message to reach:
Program-49-1: (Integer; abs, self)
-----------------------------------------------------------------
abs
"Answer a Number that is the absolute value
(positive magnitude) of the receiver."
^self < 0
ifTrue: [0 - self]
ifFalse: [self]
-----------------------------------------------------------------
This answers an object which is the result of zero minus 'self' if 'self' is smaller than zero, otherwise it answers 'self'. We see several 'self's in the source.
If you immerse yourself fully to became an Integer now, then you will not experience dissonance with all the 'self's in the program. But until you do this, you will not be able to write source code like this and you will have difficulty understanding it.
Type and evaluate (print it) the following expression under the abs method.
------------------------------ 2 abs -3 abs ------------------------------
2 and 3 are answered. You can use the Browser to imagine being a 2 or 3. Smalltalkers enclose the expressions in comment quotes and keep them. I think you know why.
It is very difficult to write the above program in the Workspace. Using block closures or a compiler object is the only way to write the same kind of program in a Workspace, and even then it is awkward.
Program-49-2: (Object, Compiler; self, evaluate:for:logged)
------------------------------------------
[:myself |
^myself < 0
ifTrue: [0 - myself]
ifFalse: [myself]]
value: 2
------------------------------------------
Compiler
evaluate: '
^self < 0
ifTrue: [0 - self]
ifFalse: [self]'
for: 2
logged: false
------------------------------------------
You can transform yourself into a certain object in the integer partition of the Browser, but not in the Workspace.
You can do real OO programming in Smalltalk by using the Browser as illustrated in the simple simulation example above. But not if you use the Browser merely as a tool to refer to classes and methods. Because then you will never understand 'self'. Only a Smalltalker who immerses himself in his selection of a class category, a class, class or instance, message category, and message will truly understand the Browser, use it efficiently, and understand 'self'. Thus he can create true object oriented programs in Smalltalk.
One of the first things an expert Smalltalker does right after defining a class is to consider the issue of equality, or '='. This is natural, because the purpose of creating classes is to represent and partition a problem domain. Novices usually overlook this issue.
In implementing the '=' method, you have to consider the 'hash' method because it compares objects. This means that you have to consider the possibility of your new object being stored in a subclass of 'Set'. This also seems difficult for beginning Smalltalkers.
You should also consider '<' etc. to compare objects. One more thing: you need to implement 'printOn:' to map your object to a character string.
Evaluate '(Array new: 3) inspect' to open an inspector which plays such a vital role in testing Smalltalk programs. There will always be a 'self' in it and in this case selecting 'self' results in '#(nil nil nil)' which is an instance of an array. Try entering 'self' in the right pane and then print it. Again you see #(nil nil nil).
Message expressions executed in the inspector almost always use 'self' as a receiver or argument. The inspector is the ultimate tool to transform Smalltalkers into all sorts of objects; even better than a Browser.
The debugger is a tool which includes an inspector to facilitate the Smalltalker's transformation. It is also a history tool to trace the communication of objects.
Smalltalk arguments are often written as a class name prefixed with an indefinite article, e.g. 'at: anIntger put: anObject'. Please observe this custom to clarify a message's identity and purpose. I do not recommend starting message names with a capital letter because capitals should be reserved for class names, global variables, class variables, pool variables etc. Observing these conventions increases program readability.
Words, particularly names, divide things into pieces. For example there are names for parts of your body like 'face' or 'neck.' But it is difficult to define precisely where your face ends and your neck begins. Also, where exactly is the border between your face and head. Are your eyes in your face or in your head? How about your hairline?
Words are sometimes used to make unnecessary distinctions for expediency. We do this to make sense of the world by classifying named things. An object and it's name are two sides of a coin, so they exist together. Therefore I believe there is a deep relationship between OOP and names. Choosing good names allows a Browser to present a perspective which clearly divides a problem domain.
Good names capture the essence of an object and facilitate human collaboration. The best class names are nouns or at minimum adjectival nouns. (Please refer to 'Smalltalk with Style')
The best message names are verbs or adverbial phrases which accurately describe action, state and behavior. It is a Smalltalk custom to use full names and not abbreviations. But long names sometimes do conflict with stupid and anachronistic file systems which allow only 8 characters for a file name and 3 for an extension. Even in this case you should not compromise naming; instead, use the 'save' method described in section 19 to overcome this problem.