Smalltalk and Object Orientation: an Introduction - Free

defining the behavior of different categories of vehicle. The second diagram presents th e 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.
Vehicle
Vehicle
Vehicle
MotorVehicle
MotorVehicle
MotorVehicle
Car
Car
Car with Hatch
Sports Hatch
Estate Car
Car
Car with Hatch
Estate Car
Subtyping
Car with Hatch
Sports Hatch
Estate Car
Subclassing (inheritance)
Sports Hatch
Specialization
Figure 2.6: Distinguishing between the relationships
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 poi nt
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 employ ment 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 constructi ng 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 relat e 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 obje ct 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.
28