It's not easy diving into OOP at this level without general OOP concepts
and purpose, which are independent of the language being used.
Very (I mean VERY :)) briefly, the benefits of OOP are:
* Modularity - keeping related functionality/data together
* Encapsulation - Limiting access to the data/functionality only to
what's necessary
* Extensibility - Making it easy to leverage existing
data/functionality to create new capability
OOP is not the only way to achieve these goals, but it is a reasonable
way. OOP isn't the solution to every programming problem. There are
other methods (like functional programming) which may be more
appropriate depending upon the situation. It's not uncommon for a
programmer to look at a problem and approach it with OOP just because
they want to and it can become more cumbersome than solving it a
different way. On the other hand, sometimes it's worth looking at a
problem from different angles to see what the pros and cons are.
To me, one of the characteristics about OOP is that it causes me to
think about the data first before I think about functions. In this
specific example, we're looking at temperature. Then we think about what
kinds of attributes and functionality are associated with that data. For
temperature, I think the scale representation (F, C, etc) is an
attribute. As such, I would not use a subclass (or inherited object more
generally) as a way just to get a different representation of the same
data. I would have just one class, Temperature, and then have different
methods to obtain different representations of that temperature.
This will look different using different languages (Smalltalk, C++,
Python, ...) but since we're in the GNU Smalltalk world for the moment,
I'll toss in such an example. Now this is not perfect and there are way
better Smalltalk programmers than me, so just consider this an example
for study and discussion, and we can pick at the good or the bad. :)
Number subclass: Temperature [
| tempc tempf |
Temperature class >> new [
^self error: 'Use setC: or setF: to construct a Temperature'
]
Temperature class >> setC: tc [
^(super new) setC: tc
]
Temperature class >> setF: tf [
^(super new) setF: tf
]
setC: tc [
tempc := tc.
tempf := (tc * 9.0/5.0) + 32.0.
^self
]
setF: tf [
tempf := tf.
tempc := (tf - 32) * 5.0/9.0.
^self
]
asC [
^tempc
]
asF [
^tempf
]
]
I noticed in the original code there were a couple of issues:
* There was no constructor identified for creating a temperature with
a specific value
* Celsius and Fahrenheit representations were separate subclasses, so
a different representation meant a different data type, making
conversion back and forth difficult.
In the above example, since temperature is a number, it inherits from
Number rather than the high level Object. There an be benefits for this
which are outside of the scope of this email. The construction involves
passing an initial value either in C or F scale. You can also change
(set new) values in either scale once constructed. These setting
messages return "self" so that you retain the original object. Finally
there are messages for obtaining the value as C or F.
Some simple example usage:
st> t := Temperature new
Object: Temperature error: Use setC: or setF: to construct a Temperature
Error(Exception)>>signal (ExcHandling.st:254)
Error(Exception)>>signal: (ExcHandling.st:264)
Temperature class(Object)>>error: (SysExcept.st:1416)
Temperature class>>new (a String:2)
UndefinedObject>>executeStatements (a String:1)
nil
st> t := Temperature setC: 0
a Temperature
st> t asC
0
st> t asF
32.0
st> (t setF: 212) asC
100.0
st>
Note there's a difference between "instance messages (methods)" and
"class messages (methods)". A "class message" operates on the class
itself (and in Smalltalk, a class itself is just another object). An
"instance message" operates on an /instance of a class/. In the above I
have defined "setC:" and "setF:" both as class messages (for
construction) and instance messages (to reset the value of a specific
temperature object).
Here's a link to the GNU Smalltalk tutorial:
https://www.gnu.org/software/smalltalk/manual/html_node/Tutorial.html#Tutorial
Enjoy!
Mark
On 1/5/2026 9:46 PM, Duke Normandin wrote:
See it here:https://controlc.com/a19d683a
Critiques please!
My first impression(s) is that it seems a lot more complicated to
create the OOP logic to get things done than it is in C, e.g. IMHO
Maybe it's because I'm not familiar with the syntax yet. But I got
it done - thanks to Divine Intervention - I'm sure!! LOL
