Smalltalk and Object Orientation: an Introduction - Free

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 integratio n. 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 avai lable
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 o bjects 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 w e 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 programm ing 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 o ne 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 li terally 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.
30