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 ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
