[FRIAM] What is an object?

[Steven A Smith]

Nick -


Another answer to your question, and those raised by the other responses
to yours is to another question... rather than literally about what OO
Programmers/Designers mean by "Object", but what features are most
useful to someone who *doesn't* write software or design systems.

It is worth noting that OO programming/design was not coined to create a
better way of thinking about problems or designing systems necessarily,
but rather to make up for the weaknesses in existing programming
languages which made it awkward to think about problems (and systems
designed to resolve them), compared to existing natural language
understandings of the problem.  

In that sense *you* already thing in *Objects* not dissimilar to the way
OO programming was crafted to allow programmers to formally specify them
and their interactions.

To start with, an *Object* is, in everyday vernacular a "thing", a
physical (or maybe not, but often very physical) thing you can see,
touch, maybe even hear and smell... and for the purposes of this
description, *interact with*.   Your kitchen toaster, your cat, the
chair you are sitting in, your house, are all pretty good examples of
"an Object".  

Key elements in OO thinking include Modularity, Composability,
Encapsulation, Abstraction and Inheritance.   

Modularity is fairly obvious perhaps...  you interact (usually) with
your *toaster*, *cat*, *chair*, *house*, not the molecules (or usually
even subcomponents) that they consist of (in some sense).   Modularity
and Composability is useful when you "set up a kitchen" with a
collection of cooking utensils, kitchen appliances, eating utensils,
etc... and even moreso if you have one of those multi-function devices
that can be a blender, a slicer, a dicer, a ricer, julienner, a
breadmaker, etc. 

 Encapsulation is important because you want to deal with a toaster via
it's declared (and apt/obvious/simple) interfaces such as the power cord
you plug into a (modular) wall outlet, the slots in the top where bread
goes in and toast comes out, the dial which sets the "brownness" and
maybe the lever that you push down to initiate "toasting" and maybe the
bell that goes off when the toast is ready.  You don't want to care
about the myriad details of wiring that leads to heating elements and
the springs and ratchets and levers and thermocouple that leads to your
toast lowering, cooking and popping up again...  Abstraction and
Inheritance are  a little more "abstract" but not unfamiliar.  

Your toaster is an *instance* of the (mechanical design) class
"toaster"... the former being something you can pick up, touch, plug
into the wall, put bread in and take toast out of... the latter you can
maybe see diagrams of on paper and discuss in abstract ways, but can
never actually touch or more importantly, use.  

A toaster (your kind) is an instance of a subclass of a more abstract
class called a "Kitchen Appliance" and maybe a bit of "An Electronic
Gadget"... and probably even of a more abstract class like "Oster" or
"Black and Decker".  There is no archetypical "Kitchen Appliance" nor
"Electronic Gadget" nor even "Oster" (though I think there is a
multi-function kitchen appliance-gadget called an Osterizer that is a
modular mashup of several abstract types of kitchen gadget"

Your toaster, your cat, your chair, your house, are all *instances* of
*classes* which *inherit* properties from *superclasses*...  A toaster
is an electromechanical device, a kitchen appliance, an electronic
gadget (esp. if it has a digital interface, etc.).  A Cat is a Felidae,
a Domestic Animal, a House Pet, a Friend, etc.   and *inherits*
properties from *all* of those abstract classes.   A chair is Furniture
with Household or Office style/utility/??? features, and is
conventionally  *composed of* a Seat, 4 Legs, a Back.   Three legged
stools, kneeling chairs, sitting balls, all break some or all of the
above... 

What you said about your Troybuilt and the B&S engine replacing the
Tecumseh (trusting Eric here) describes interfaces, abstraction and
modularity... the fact that the B&S engine *could* be strapped up to the
rest of the Tiller is a testimony to relatively well conceived
*interfaces* (or a very clever mechanic)...   The fact that "an engine
is an engine is an engine" is the Abstraction, though Eric's point that
the Tecumseh design was notoriously torque-y and a *tiller* application
would seem to demand/utilize more torque than a lawnmowing
application...   you either didn't stress it past it's operating modes
(all those times the tiller bogs down and the engine stalls?) or the
design had a good torque-converter in it to make up for the less
torque=y engine.

What you said about the tomato plants being "seven feet tall" I take to
be (mostly) hyperbole for illustrative purposes... I'm guessing they are
more like 4-5' tall, and I suspect you can attribute much of that tall
growth to the Miracle Grow you applied liberally along the way... 
though if your soil is particularly difficult, a good deep *till* might
have made some of that difference.   I think it would be interesting to
see how different OO designers decomposed the system of systems involved
in your achieving a meta-goal like 7' tall tomato plants (but are they
bearing, and is the fruit equally beautiful, delicious and nutritious?)

Carry on,
 - Steve