Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!radar!cadillac!speyer From: speyer@cadillac.CAD.MCC.COM (Bruce Speyer) Newsgroups: comp.object Subject: Re: Objects and Interactions: Separate Definitions Summary: separating control and specification of objects Keywords: modeling Message-ID: <20696@cadillac.CAD.MCC.COM> Date: 28 May 91 14:53:54 GMT References: <3999@motcsd.csd.mot.com> <1991May21.064913.16149@netcom.COM> <1991May22.012821.12048@tkou02.enet.dec.com> <1991May22.183044.5634@Think.COM> <19807@crdgw1.crd.ge.com> <7051@stpstn.UUCP> Reply-To: speyer@MCC.COM (Bruce Speyer) Distribution: comp Organization: MCC CAD Program, Austin, TX Lines: 46 In article <7051@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >There's a famous misconception that I call 'The Sucker Trap of OO Programming', >that you should design by identifying the nouns and the verbs; then make >the nouns instances and the verbs methods. >... >Except at the very lowest levels of granularity where this is often proper, >a much better way is to distinguish between *active* objects and *passive* >objects. Both are objects, but one sort is more heavily weighted with data >and the other with procedure. In your terminology, the passive objects are >the entities, and the active ones the relationships. >... A number of us at MCC learned this lesson the hard-way (circa '84-87). My cut (which is the same thing as Brad is saying) is to separate the control of the object from the objects being controlled. Concrete examples include: provide a draw model (set of classes) rather than just objects which draw themselves; do not build versioning into the objects being versioned but rather provide a versioning and configuration control model for managing the objects. If you notice that you are having a class (type) explosion due to slight variations in the semantics of control then you are falling into the ``everything is just an object'' trap. In article <3999@motcsd.csd.mot.com> lance@motcsd.csd.mot.com Lance Norskog writes: >... >Separating objects and their interactions shears class definitions of >descriptions of their dealings with other specific objects, and leaves them >only with a small, simple set of messages and responses. My theory is that >this will encourage defining small, simple, reusable objects. Carrying this point a step further ... separating objects and interactions makes it easier to reach consensus and *standards*. This is due to the implementation-independent nature of the specification (i.e., it is not *necessary* to implement the standard using o-o techniques). This is especially important when dealing in industry-specific domains. To facilitate communication, modeling methodologies such as IDEF[01], NIAM, and Express are used. These methodologies explicitely separate structure from process (behavior) and control (stimulus, constraints, timing characteristics). If you imagine standardizing at the level of the enterprise (all business activities) you can begin to see why this explicit separation and specification (at a very detailed level) is necessary to reach consensus and standards. -- Bruce Speyer / MCC CAD Program EMail: speyer@mcc.com 3500 West Balcones Center Drive Phone: [512] 338-3668 Austin, TX. 78759 Fax: [512] 338-3897