From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,c890e6ab3fb2c5fc X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,c890e6ab3fb2c5fc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-07 15:30:28 PST Newsgroups: comp.lang.ada,comp.lang.c++ Path: swrinde!gatech!udel!news.mathworks.com!uunet!noc.near.net!ray.com!news.ray.com!news.ed.ray.com!swlnews.msd.ray.com!swlvx2!jgv From: jgv@swl.msd.ray.com (John Volan) Subject: Subject/Object Confusion Syndrome [was: Ada Objects Help] Sender: news@swlvx2.msd.ray.com (NEWS USER) Organization: Raytheon Company, Tewksbury, MA Message-ID: References: <3f9g1u$j4m@nps.navy.mil> <3fu6qc$pc5@gnat.cs.nyu.edu> <1995Jan29.181902.23255@mole-end.matawan.nj.us> <1995Feb5.180601@hobbit> Date: Tue, 7 Feb 1995 23:04:33 GMT Xref: swrinde comp.lang.ada:26351 comp.lang.c++:112611 Date: 1995-02-07T23:04:33+00:00 List-Id: hathawa2@marshall.edu (Mark S. Hathaway) writes: >There has been some discussion recently on comp.object about the question >of what mechanism should be used to bring together two (2) or more objects >to work with and to affect. I've suggested that in such cases it's always >better to have such a "higher authority" than to allocate to an object a >method which doesn't belong. To have a mow() method in a lawn object seems >absurd to me. Since when does a lawn do anything but grow_crab_grass()? Mark, you've fallen right into one of the prime conceptual traps of the object-oriented paradigm: You've swallowed the fallacy that "object-oriented software models the real world." Despite the all-too-frequent hype you might have heard, object-oriented software does *not* model real-world behavior. Object-oriented software -- like *any* computer software -- is a formalized model of the behavior we want to elicit out of a *computer*. Now, there might be a very compelling *analogy* between objects-in-the-real-world and objects-in-the-computer, but it's still nothing more than an *analogy*. Every analogy eventually breaks down if you push it too far. I would submit that the point where the "real-world" analogy breaks down is precisely when you start trying to deal with behavior. Definition: A software object is an encapsulation of a *computer's* responsibilities *with respect to* some real-world object in its problem domain. A software object encapsulates the computer's responsibilities to know things (data) and to do things (processing) *pertaining to* some real-world object. This knowledge and behavior might bear very little resemblance to the actual knowledge and behavior that the real-world object itself might be endowed with. In general, the purpose of computer software is *not* to mimic what real-world entities do. In fact, the whole point is usually to hold the kind of data and to perform the kind of processing that real-world entities are *not* already capable of doing. Otherwise why bother programming? >The authority which mow()s is not the lawn. Of course lawns don't mow themselves -- in the real world. Of course there's always some "higher authority" or "agent" actually responsible for mowing a given lawn -- in the real world. But if we're talking about the real world, isn't our lawn-mowing *software* a *part* of the "real world"? Isn't the program itself that "higher authority" or "agent" you're seeking? Of course, our hypothetical program is probably responsible for mowing a lot of lawns, and for mowing a lot of different *kinds* of lawns, and for doing a lot of other things to/for/with/about/upon lawns, and for doing things to/for/with/about/upon a lot of other things besides lawns. That's a lot of different responsibilities -- things are getting pretty complex. So it would be beneficial if we could to encapsulate all those responsibilities in a nice compartmentalized way. Let's say we take all the responsibilities that pertain just to one particular lawn of one particular type, and concentrate those responsibilities into one cohesive software entity, distinct from everything else in the system. For simplicity, we might call this entity a "lawn" object -- but never in our wildest dreams do we imagine that it's *really* a lawn. (Last time I looked inside my workstation, I didn't see any sod on the motherboard. :-) No, a "lawn" object is really just a particular chunk of our computing resources that happens to be devoted to managing a lawn. The only reason we don't call it a "lawn manager" or a "lawn controller" is that the role of "managing" or "controlling" is something you can assume about *every* software object. That's what software does: it "manages" or "controls" or at least "keeps track of" things. So it would be kind of redundant to tack on that extra verbiage. It should just be understood. Well ... this assumes that programmers actually *understand* what programming is all about ... >Create another object which >can manipulate the mower and lawn objects. How about... > > class lawn_mowin_fool is > -- states: poverty, drunk, out of control :-) > proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ) is > ... > end mow; > end lawn_mowin_fool; > > spirit lawn_mowin_fool is > proc mow ( lawn is in out yard_of_grass; mower is in lawn_mower ); > end lawn_mowin_fool; > > proc lawn_care () is > obj lmf is lawn_mowin_fool; > begin > lmf.mow(MyLawn,SearsSpecial); > end lawn_care; > >This way you can command lmf to mow MyLawn yard_of_grass with a >SearsSpecial lawn_mower. > >Is that decent or what? >It beats the heck out of asking a lawn to mow itself! This is silly. Does our hypothetical program have any responsibilities that pertain to some real-world "lawn-mowing fools"? Are there some real human beings out there that the software is supposed to give orders to, telling them what lawns to mow with what lawn mowers? If so, then I suppose I could understand the need for a "lawn_mowing_fool" class. But if the program itself is supposed to control the lawn mowers *directly*, then inventing a lawn_mowing_fool class is just an unnecessary complication. The computer *itself* is supposed to be the "lawn-mowing fool". Or perhaps we've already had experience with a non-computerized system in which "lawn-mowing fools" -- who sometimes get "drunk" or "out of control" -- are employed to mow lawns. Perhaps we're actually trying to *replace* the "lawn-mowing fools" with software that can do the job better. If that's case, then imitating the behavior of "lawn-mowing fools" in software would be not be "cool" or "decent" -- it would be totally *foolish*. :-) The point of this thread was that when you see a C++ member-function call like: theFrontLawn.mowWith(theSearsSpecialMower); or a Smalltalk method call like: theFrontLawn mowWith: theSearsSpecialMower. you should never feel complled to imagine this as meaning "the front lawn will mow itself using the Sears Special lawn mower". Unfortunately, the syntax seems to encourage this kind of interpretation, and a lot of people even *advocate* this kind of thinking as being "cool". However, I (today) believe this is a silly way of interpreting what object-oriented software does. Instead, I'd read this kind of call as meaning "the part of the computer devoted to the front lawn will mow it (the front lawn) using the Sears Special lawn mower." You always have to keep in mind that "theFrontLawn" is just a chunk of *software* responsible for the front lawn -- and I think "mowing the lawn" should be an integral part of its responsibilities, not something off-loaded to another object. The equivalent call in Ada95 might be something like: Lawns.Mow (The_Lawn => The_Front_Lawn, With_Mower => The_Sears_Special_Mower); (assuming "Lawns" is a package containing a tagged type "Lawn" with a primitive procedure "Mow"). With this syntax, I'd wager you'd be much less likely to view "The_Front_Lawn" as somehow "mowing itself". Yet this Ada subprogram-call might have exactly the same dynamic- dispatching semantics as the C++ member function call or the Smalltalk method invocation above. That is, "The_Front_Lawn" might be a special "controlling" parameter, whose run-time type information ("tag" in Ada95 jargon) would determine which overloaded implementation of "Mow" to dispatch to. >Mark S. Hathaway -------------------------------------------------------------------------------- Me : Person := (Name => "John G. Volan", E_Mail_Address => "jgv@swl.msd.ray.com", Employer => "Raytheon", Affiliation => "Enthusiastic member of Team-Ada!", Shameless_Controversial_Marketing_Slogan_For_Favorite_Language => "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>" & "Inheritance, hierarchical name-space, generic templates, type-safety, " & "readability, C/C++/COBOL/FORTRAN interoperability, numeric precision, " & "multi-threading, distributed systems, real-time, safety-critical ... " & "<< A d a 9 5 : Y o u n a m e i t , i t ' s i n t h e r e >>", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my employer, so using them would be " & "totally erroneous ... or would that be a bounded error? :-) "); --------------------------------------------------------------------------------