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: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public From: Alan Lovejoy Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/13 Message-ID: <3289A2F6.1707@concentric.net> X-Deja-AN: 196189975 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> <55v177$ufo@grimsel.zurich.ibm.com> <3283BB94.2D82@concentric.net> <32875B03.3729@iconcomp.com> <32890CB7.19B5@concentric.net> <56bkvl$2ka@plath.bain.oz.au> content-type: text/plain; charset=us-ascii organization: Modulation mime-version: 1.0 newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai x-mailer: Mozilla 2.01Gold (Win95; U) Date: 1996-11-13T00:00:00+00:00 List-Id: Nick Thurn wrote: > > Alan Lovejoy (alovejoy@concentric.net) wrote: > > > > My usage of the word "design" in the quote above is being interpreted in a way > > other than I intended. In the context of the earlier posts, it should have been > > clear that by "design" I was referring to the objects that exist when the program > > runs, and how they interact. And I was **defining** the term design as I had > > used it, not trying to suggest that the implementation technology is not important, > > or that one should not consider such issues when producing a design or implementing > > a system! > > > Alan, > > These objects interpreted (compiled at runtime) or otherwise are > surely the products of implementation. You seem to presuppose an implementation > which leads to a design, isn't this backwards? > > The objects that exist when the program runs are a mixture of implementation > objects, domain objects, library objects, ui objects, comms... etc. Trying to > think back from them seems very unhelpful. IMHO even thinking *forward* to > these implementation objects too early is dangerous. > > Do you mean this or do I have it wrong? Pardon me, I see I wasn't clear. The "dynamic model" or "dynamic design" **deals with** or **is concerned with** the objects that will exist at run time, what roles they will play, what responsibilities they will have and how they will interact. Of course the run time objects are NOT themselves the design (in spite of the fact that my imprecise wording might give one the impression that I was saying that). Many objects that exist at run time may have internal mechanisms that you have no control over, such as those that may be instantiated from classes in the standard library. You can of course always choose not to use such "standard" or "system" objects, and in some languages (such as Smalltalk) you may be able to easily change them, but simply using them as-is is what usually happens. You don't need to design such "standard" objects, but you do need to know how to interface to them, and decide what roles (if any) they will play in your system. Perhaps a concrete example will clear up the confusion. The Model-View-Controller concept is now familiar to many, so I will use that as the example. The inventor of MVC (Trygve Reenskaug) calls the MVC architecture an example of what he calls a "role model." A role model specifies what objects collaborate together in the "role model," and what the role of each object is in the collaboration. The MVC "role model" specifies that there are three objects, a "model," a "view" and a "controller" that collaborate in an MVC "role model." The objects are named according to the role that each plays. It may be that more than one object will play the same role as another, but that does not happen in the basic case of the MVC role model. It may also be that the same object will play more than role, perhaps because it is also a collaborator in a different role model. Complex designs are constructed by composition of multiple role models. The responsibility of the "view" in the MVC role model is to graphically display informaition about the state of the model. The responsibility of the controller is to get and respond to user input. The responsibility of the model is to maintain displayable state. A formal role model would specify the messages each object in the role model will send to the other objects, what events would prompt the sending of such messages, and what the semantics of those message are. The collaborating objects in a role model are understood as instances, not classes. And a role is a function of a) the responsibility of an object and what purpose it serves, b) the messages that it will be expected to respond to (which might well be a subset of all the messages it could respond to), and c) the messages it will send to other collaborators (which might not be all the messages it could send, nor all the receivers to which it may potentially send messages). The MVC role model does not just say that there are models, views and controllers, and that they send certain messages to each other. It specifically says that a particular model, a particular view and a particular controller must collaborate together. The view can't collobarate with just any model it happens to find in memory. It becomes associated with a particular model and controller, and collaborates with those particular objects. Object identity matters, and is explicitly dealt with. If you want to dynamically change which model the view and controller are associated with, that change has to become part of the protocol specified by the role model. >From this it should be clear that roles are not classes. One can use multiple inheritance, dynamic typing with polymorphism, interfaces or dynamic delegation in order to put any object into one of the roles. It just has to correctly respond to all the messages specified by the role, and send only those messages allowed by the role. This is of course easier to do in a dynamically typed language, but it can also be done in statically typed languages that support interfaces or multiple inheritance. I wholeheartedly endorse role modelling, and recommend doing it **before** trying to worry overmuch about the class hiearchy. Wouldn't it be nice to identify the role models in which the objects in your program will participate before designing the class hierarchy that will provide the classes whose instances can be collaborators in those role models? -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|