lance@motcsd.csd.mot.com (lance.norskog) (05/21/91)
preece@urbana.mcd.mot.com (Scott E. Preece) writes: >In article <1991May3.212005.29453@visix.com> amanda@visix.com (Amanda Walker) writes: >| >| ... A trivial example of this idea is that a heapsort >| should operate on any set of objects for which I can provide >| comparison and exchange operations. >--- >OK, let me expose my ignorance[1]. I'd like to see how object-oriented >design works. Would you care to sketch the design for this? My naive >model would be that a heap is an object and that it has add and remove >methods to take objects of unspecified type and stick them into the heap >in the right place. So where do the comparison and exchange procedures >go? I see two alternatives[2]: (1) the heap object has compare and >exchange methods that "know about" all of the types, figure out what's >involved, and operate on the member objects or (2) the objects have >methods that report their "comparable value" and size in canonical forms >that a generic routine in the heap object can operate on. Neither of >these makes me awfully happy. Standard practice, like Smalltalk, follows (2). C++ seems to do (1) for handling type conversions. Class definitions seem to have two jobs: a) defining the "Buddha Nature" of a class, and b) defining the interactions of that class and some other class. B) generally involves describing a particular interaction in two different places: one in the class, and another in some other class that interacts with the first class. I'm happy putting A) in a class definition, but B) splits the interaction into 2 different places, increasing "code entropy". An alternative is to have a separate set of declarations which define interactions between objects. These interaction definitions are where you code up classic algorithms. Let's say we have objects X and Y, and that in Smalltalk X would use Y in some way, by sending it messages and interpreting the responses. With interaction definitions, X would say "Start interaction Z with Y". An instance of interaction definition Z is created, and it sends any number of messages to X and Y, interpreting the responses. Objects don't send messages to other objects. 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. An interaction between classes, including abstract superclasses, is inherited by all subclasses. This solves my problem in my 3d software in which I have to define a new class PaintedObject with one operation Paint in order to impress a 2D or 3D texture onto any drawable object. It struct me as overkill to create a new class with one little operation, and interfered with my scoping system. Now, of course, we have the problem of making mutant copies of interactions easily. I have no clean solutions for this. I've heard the term entity-relationship (ER) bandied about, and seen it in books, but haven't tracked down a full comprehension. It may be that I'm crossing ER with objects. Comments? Lance Norskog
jls@netcom.COM (Jim Showalter) (05/21/91)
]>>OK, let me expose my ignorance[1]. I'd like to see how object-oriented ]>>design works. Would you care to sketch the design for this? My naive ]>>model would be that a heap is an object and that it has add and remove ]>>methods to take objects of unspecified type and stick them into the heap ]>>in the right place. So where do the comparison and exchange procedures ]>>go? I see two alternatives[2]: (1) the heap object has compare and ]>>exchange methods that "know about" all of the types, figure out what's ]>>involved, and operate on the member objects or (2) the objects have ]>>methods that report their "comparable value" and size in canonical forms ]>>that a generic routine in the heap object can operate on. Neither of ]>>these makes me awfully happy. Why does 2 make you unhappy? This is a perfect example of what is called genericity in Ada and templates in latest-greatest C++. The basic principle is "separation of concerns": one program entity knows how to quicksort stuff (arbitrary stuff), but since it doesn't know a priori what the stuff being sorted is, the responsibility for providing a "<" operation belongs to the client providing the stuff. This is a first-rate way to achieve a high degree of reuse--one optimized and fully-debugged quicksort that can be used to sort any kind of object. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
sakkinen@jyu.fi (Markku Sakkinen) (05/21/91)
In article <3999@motcsd.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: > ... >An alternative is to have a separate >set of declarations which define interactions between objects. These >interaction definitions are where you code up classic algorithms. > ... >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. > ... Your thoughts look a lot similar to those of Richard Helm, Ian Holland and Dipayan Gangopadhyay in their OOPSLA/ECOOP'90 paper "Contracts: Specifying Behavioral Compositions in Object-Oriented Systems". These ideas looked really worth pursuing further, and that's what at least Ian is currently doing. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
haim@taichi.uucp (24122-Haim Kilov(L028)m000) (05/21/91)
"Let's say we have objects X and Y, and that in Smalltalk X would use Y in some way, by sending it messages and interpreting the responses. With interaction definitions, X would say "Start interaction Z with Y". An instance of interaction definition Z is created, and it sends any number of messages to X and Y, interpreting the responses. Objects don't send messages to other objects." OK, but X and Y are (almost always) symmetric, so Y may also start the interaction Z with X. Therefore the creation of Z should be made possible both for X and for Y. Perhaps, one of these is created explicitly, and the other - "automatically". -Haim Kilov haim@bcr.cc.bellcore.com
davidm@uunet.UU.NET (David S. Masterson) (05/22/91)
>>>>> On 21 May 91 01:52:20 GMT, lance@motcsd.csd.mot.com (lance.norskog) said: Lance> preece@urbana.mcd.mot.com (Scott E. Preece) writes: Scott> In article <1991May3.212005.29453@visix.com> amanda@visix.com (Amanda Scott> Walker) writes: Amanda> ... A trivial example of this idea is that a heapsort Amanda> should operate on any set of objects for which I can provide Amanda> comparison and exchange operations. In object orientation, this seems to never be quite right. The real way of expressing a HeapSort() operation is that it operates on any set of Sortable objects (which is defined as having a comparison operation). Often, though, this looks like overkill as it expects an awful lot of things to derive from Sortable. Scott> OK, let me expose my ignorance[1]. I'd like to see how object-oriented Scott> design works. Would you care to sketch the design for this? My naive Scott> model would be that a heap is an object and that it has add and remove Scott> methods to take objects of unspecified type and stick them into the Scott> heap in the right place. So where do the comparison and exchange Scott> procedures go? I see two alternatives[2]: (1) the heap object has Scott> compare and exchange methods that "know about" all of the types, figure Scott> out what's involved, and operate on the member objects or (2) the Scott> objects have methods that report their "comparable value" and size in Scott> canonical forms that a generic routine in the heap object can operate Scott> on. Neither of these makes me awfully happy. Actually, using Sortable as the base class for anything that HeapSort() can work on eliminates a lot of conceptual problems, but the methodology for implementation still has a number of technical problems. One method is a technique called (I think) double polymorphism which is a tricky way of having the derivatives of Sortable promote themselves up the hierarchy until comparible values are found. Lance> Standard practice, like Smalltalk, follows (2). C++ seems to do (1) Lance> for handling type conversions. I think it could be done equally well in both languages, it just depends on the frame of mind of the implementor. An article on Generic Mathmetics (I think) appeared in Journal of Object-Oriented Programming in January and explained the ideas of double indirection better than I could. Lance> Class definitions seem to have two jobs: a) defining the "Buddha Lance> Nature" of a class, and b) defining the interactions of that class and Lance> some other class. B) generally involves describing a particular Lance> interaction in two different places: one in the class, and another in Lance> some other class that interacts with the first class. I'm happy Lance> putting A) in a class definition, but B) splits the interaction into 2 Lance> different places, increasing "code entropy". Lance> An alternative is to have a separate set of declarations which define Lance> interactions between objects. These interaction definitions are where Lance> you code up classic algorithms. True, but this "interaction definition" can be thought of as an object in its own right and, therefore, coded as a class. Lance> Let's say we have objects X and Y, and that in Smalltalk X would use Lance> Y in some way, by sending it messages and interpreting the responses. Lance> With interaction definitions, X would say "Start interaction Z Lance> with Y". An instance of interaction definition Z is created, Lance> and it sends any number of messages to X and Y, interpreting the Lance> responses. Objects don't send messages to other objects. Well, Entities don't communicate directly with other entities, they communicate via Relationships (you mentioned E-R later). Either the relationship controls the interaction by being the initiator of any interaction between entities or by being the go-between for the entities. Lance> Separating objects and their interactions shears class definitions Lance> of descriptions of their dealings with other specific objects, and Lance> leaves them only with a small, simple set of messages and responses. Lance> My theory is that this will encourage defining small, simple, Lance> reusable objects. Possibly, but it shouldn't be carried too far. Consider that inheritance could also be looked at as the interaction of two objects. Also, how do you handle a List class (which interacts with everything in the list)? Lance> I've heard the term entity-relationship (ER) bandied about, and seen Lance> it in books, but haven't tracked down a full comprehension. Lance> It may be that I'm crossing ER with objects. Which is not necessarily a bad cross. ER is used for determining Entities and Relationships which is very useful for understanding object definitions as well. Relationships can be treated, though, as objects just as easily as Entities. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
diamond@jit533.swstokyo.dec.com (Norman Diamond) (05/22/91)
In article <1991May21.064913.16149@netcom.COM> jls@netcom.COM (Jim Showalter) writes: [attribution lost]: >]>> or (2) the objects have methods that report their "comparable value" >]>>and size in canonical forms that a generic routine in the heap object >]>>can operate on. Neither of these makes me awfully happy. > >Why does 2 make you unhappy? ... "separation of concerns": one program >entity knows how to quicksort stuff (arbitrary stuff), ... the >responsibility for providing a "<" operation belongs to the client >providing the stuff. Responsibility for specifying a "<" operation belongs to the call site. For example, people have family names and given names. One might want to sort people's names to create a Western-style phone book or a Japanese-style phone book. To create a Western-style phone book, the key for a person's name is the family name followed by the given names. To create a Japanese-style phone book, the key for a Japanese person's name is the family name followed by the given name, while the key for a foreigner's name is the given names followed by the family name.(*) A person-object has a family name and given names, but can't construct the correct key for a "<" operation without knowing which "<" operation suits the call site. I do agree that the sorter entity should not specify the "<" operation. I think the call site has to specify it. (* My personal opinion is that Japanese don't know how to make a phone book, and that the inconsistency is mildly racist; -- DISCLAIMER: my employer has stated its disagreement with my opinion.) -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Permission is granted to feel this signature, but not to look at it.
amanda@visix.com (Amanda Walker) (05/22/91)
[Sorry for the delay in responding--I've been out of town for a week]
cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
Amanda> ... A trivial example of this idea is that a heapsort
Amanda> should operate on any set of objects for which I can provide
Amanda> comparison and exchange operations.
In object orientation, this seems to never be quite right. The
real way of expressing a HeapSort() operation is that it operates
on any set of Sortable objects (which is defined as having a
comparison operation). Often, though, this looks like overkill as
it expects an awful lot of things to derive from Sortable.
One of the advantages of a dynamic type system in this kind of case is that
Sortable need not be an explicitly declared class, as it would have to be in
C++, for example. Now, multiple inheritance can help, in the form of
"mixin" classes, but I find it most simply expressed in a dynamic type
system in which the methods are dispatched at run time. Generic functions
(or operators) allow some of this to happen in a static type system such
as C++, since you can write the algorithm in terms of the operations which
are available on the objects, and not their explicit types themselves.
This approach is most useful for expressing abstract operations (like
sorting) than for more concrete ones, admittedly.
One method is a technique called (I think) double polymorphism
which is a tricky way of having the derivatives of Sortable promote
themselves up the hierarchy until comparible values are found.
Yes. Not too many object systems easily support this, though.
Which is not necessarily a bad cross. ER is used for determining
Entities and Relationships which is very useful for understanding
object definitions as well. Relationships can be treated, though,
as objects just as easily as Entities.
Once again, agreed. I find ER and "objects" to both be useful ways of
looking at the same things in different ways...
--
Amanda Walker amanda@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
Don't try to out-weird me... I get stranger things than you free with my
breakfast cereal.haim@taichi.uucp (24122-Haim Kilov(L028)m000) (05/22/91)
On objects and ER: " Which is not necessarily a bad cross. ER is used for determining Entities and Relationships which is very useful for understanding object definitions as well. Relationships can be treated, though, as objects just as easily as Entities. Once again, agreed. I find ER and "objects" to both be useful ways of looking at the same things in different ways..." I am not sure these ways are different at all. Both entities and relation- ships (in fact, different kinds of entities -- like "composite", "dependent", etc.) can be treated as objects. They have different properties defined by their behavior. Now comes the interesting part. This behavior is defined not just by a par- ticular entity (class), but rather by operations jointly owned by this entity and its associated entities. For instance, in a simple case of a "relationship", an object becomes a relationship with respect to two or more entities because it has, e.g., an operation "create relationship with entities" with corresponding parameters, and also because the precondition of a successful execution of this operation states that instances of these entities should exist before an instance of the relationship is created. Naturally, for each of these entities there will be an operation like "get relationship instance", also with a parameter -- the name of the relationship type. "Delete" for an entity will have a precondition stating, say, that no instances of associated relationships should exist, i.e., that they should have been deleted earlier. (Cascade delete is another possible approach, of course.) The postcondition will state that after a successful deletion both the entity instance and associated relationship instances do not exist anymore. In this manner, the idea of "interaction" Z between two "objects" X and Y may be considered as the idea of using ER methodology in a precise way. In particular, the association between X and Z is the same as between Y and Z, and there also exist two other associations -- between Z and X and between Z and Y. Implementation-wise these may be considered pointers, but these "pointers" in fact have properties of their own. The designer states that there exists such a (typed) interaction and also states who participates in this interaction. The properties of the interaction and its elements are pre- defined and therefore reused. This example may be treated as a relationship Z between two "symmetric" entities X and Y. As entities need not be symmetric (e.g., parent and dependent), associations between them will look (slightly) differently. Note, however, that the association between a usual entity (say, X) and "its" relationship (say, Z) is also asymmetric and may be considered in the same manner as the association between a parent and a dependent (see my recent note in the April issue of ACM Software Engineering Notes). This seems to be very promising, and we are moving in the direction of integrating "ER" and "OO" approaches. Hope this helps. -Haim Kilov haim@bcr.cc.bellcore.com
barmar@think.com (Barry Margolin) (05/23/91)
In article <1991May22.012821.12048@tkou02.enet.dec.com> diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond) writes: >Responsibility for specifying a "<" operation belongs to the call site. Which then requires the call site to know about all the possible types of things it will compare, which is contrary to object orientation. The problem you're running into is that there is more than one way to compare two objects, but we'd like the generic sorter to simply use a generic comparison operator. Even with relatively simple data types such as strings, there's case-sensitivity to complicate the matter. With more complex objects, we might want to be able to sort on different fields (e.g. use a phone database to produce a regular directory sorted by names, and an inverse directory sorted by phone numbers). One possible way around this would be for the generic comparison function to take a third argument, which would be an object that represents the style of comparison being done. Sorry, I haven't really thought this through, but it could contain flags such as case-sensitivity, relative priority of fields, etc. Making it truly generic could be tough, though; it would probably work best in a language with good relexive capabilities (e.g. the field priorities could be passed in as a list of slot names if the language permits accessing slots using computed names, a la CLOS's SLOT-VALUE function). The other way to solve it is where I think this discussion started: implement a class that represents the collection, and implement operations on the collection class that do all the different sorts. Thus, for a phone number database, there could be SORT-JAPANESE, SORT-WESTERN, and SORT-BY-NUMBER methods. A single SORT method doesn't really make sense, unless you want to unilaterally declare that one of these would be a reasonable default and have SORT simply call it. This parallels the real world. If someone hands you a stack of baseball cards and just tells you to sort it, you've got to guess what he means. He could want them sorted by player name, team, year, batting average, etc. There's no such thing as a generic sort or a generic comparison operator. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
meltsner@crd.ge.com (Kenneth J Meltsner) (05/23/91)
In article <1991May22.183044.5634@Think.COM>, barmar@think.com (Barry Margolin) writes: [...] |>The other way to solve it is where I think this discussion started: |>implement a class that represents the collection, and implement operations |>on the collection class that do all the different sorts. Thus, for a phone |>number database, there could be SORT-JAPANESE, SORT-WESTERN, and |>SORT-BY-NUMBER methods. A single SORT method doesn't really make sense, |>unless you want to unilaterally declare that one of these would be a |>reasonable default and have SORT simply call it. |> |>This parallels the real world. If someone hands you a stack of baseball |>cards and just tells you to sort it, you've got to guess what he means. He |>could want them sorted by player name, team, year, batting average, etc. |>There's no such thing as a generic sort or a generic comparison operator. I'd like to second this concept, if only for the difficulties we'll soon see with successors to ASCII which no longer support a simple arithmetic comparison of character code to sort. And for more complex issues, like sorting book names that include Roman numerals, spelled-out numbers, words to ignore (like initial "The"), etc. Check the Library of Congress book title sorting rules if you want an idea of how complex this is. -- =============================================================================== Ken Meltsner | meltsner@crd.ge.com (518) 387-6391 GE Research and Development Center | Fax: (518) 387-7495 P.O. Box 8, Room K1/MB207 | Nothing I say should be attributed Schenectady, NY 12301 | to my employer, and probably vice-versa =================Dep't of Materials Science, ACME Looniversity=================
Chris.Holt@newcastle.ac.uk (Chris Holt) (05/23/91)
barmar@think.com (Barry Margolin) writes: >In article <1991May22.012821.12048@tkou02.enet.dec.com> diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond) writes: >>Responsibility for specifying a "<" operation belongs to the call site. >Which then requires the call site to know about all the possible types of >things it will compare, which is contrary to object orientation. I don't understand this. The call site has access to the type of thing being compared, or it wouldn't be able to build the structure that is to be sorted; and if it's got the type, it should have the operations that go with that type. Presumably, an ordering relation is one of these. If the caller doesn't know the ordering relation, why should it care whether the structure is sorted or not? >The problem you're running into is that there is more than one way to >compare two objects, but we'd like the generic sorter to simply use a >generic comparison operator. But there isn't always a "generic" comparison operator; unless you're happy with such things as sorting hash values derived from unique identifiers. >There's no such thing as a generic sort or a generic comparison operator. A generic sort is one that accepts a comparison operator as a parameter. ----------------------------------------------------------------------------- Chris.Holt@newcastle.ac.uk Computing Lab, U of Newcastle upon Tyne, UK ----------------------------------------------------------------------------- "They have been at a great feast of languages, and stolen the scraps." - WS
cox@stpstn.UUCP (Brad Cox) (05/25/91)
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. This is not to attack Grady who first formalized this as a design recipe. All of the early advocates, myself specifically included, are guilty of encouraging this notion in our rush to explain how OO differs from conventional data and procedures. Now that encapsulation of data with procedures is widely accepted as good, it is now quite proper to ask 'Now that we can have honext to goodness entities, how to express the relationships? 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. This is nothing more than the Smalltalk model-view-controller paradigm generalized to apply not only to user interface construction, but as a broadly applicable principle of good design. The phrase, 'levels of granularity' in the preceeding paragraph, opens up a whole new can of worms that I wish more people would concentrate on. A generally recognized vocabulary for architectural levels would greatly clarify many of these discussions. For example...most people's notion of objects/messages is one level of granularity. Because of the Software-IC notion, think of these as chip-level objects in order to leave room for lower-level kinds of objects such as friend/member functions (block-level objects) and inline procedures/macros (gate-level objects). Compose from these chip-level objects a higher-level construction involving active and passive chip-level objects working in combination, such as perhaps a Smalltalk user interface involving model-view-controller. What should we call this higher-level construction? Why not a card-level object, to suggest a new kind of object at a higher level of concretion. Or suppose that this user interface is part of a larger application that involves a number of lightweight tasks. Aren't these 'objects' too, at an even higher level of granularity than the others? I'm not hung up on the precise set of words here. I'm only arguing that different levels of *concretion* (*not* abstraction) do exist in software, and that we desperately need a vocabulary (apart from the object/message vocabularity) to point out which level of granularity we're talking about. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
speyer@joy.cad.mcc.com (Bruce Speyer) (05/28/91)
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
speyer@cadillac.CAD.MCC.COM (Bruce Speyer) (05/28/91)
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
jls@netcom.COM (Jim Showalter) (06/04/91)
>What should we call this higher-level construction? Why not >a card-level object, to suggest a new kind of object at a higher level >of concretion. I refer to the architectural-level chunks of a system as "subsystems", to distinguish them from the smaller objects of which they are constructed. (I think Grady calls these "class collections" in his newest book, but this is too restrictive for my taste: subsystems are often more than mere collections of related classes.) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (06/04/91)
>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. Careful--you're starting to sound like the people who've had serious reservations about "pure" OO since it first arrived on the scene! I know a number of people who think OO has been greatly oversold because it makes no more sense for everything to be an object than it does for everything to be a function. As with most things in life, a more middle- of-the-road, HYBRID strategy is required. A control sequence at the top of a pile of application code is not and never has been a proper object, and attempts to force it to be so result in non-intuitive, stilted code (the famous "XYZ_Manager" object, which is an object only by the most tortured misuse of the English language). Some things are objects and some things are not objects, and the pragmatist (as opposed to the religious nut) uses the most appropriate construct for each entity in the program, not the most politically correct construct. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *