* Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) @ 1996-11-06 0:00 Dong Oh Kim 1996-11-06 0:00 ` Paul_Gover ` (7 more replies) 0 siblings, 8 replies; 79+ messages in thread From: Dong Oh Kim @ 1996-11-06 0:00 UTC (permalink / raw) Hello~ First of all, thank you for your reading this article. I'm preparing for a paper associated with object-oriented modelling approach and now investigating the current state of OOA & OOD, and CASE tools... There're two sides about this topic. That is...some people told me, "It's good now...I can develop a program with 'xxx' oo method and its CASE tool". But others, "OO methods needed more supplement...And still I can't believe CASE tools " Let me have your opinions about followings: 1. Is everything OK with existing oo development methods? If not, what are needed? and what stage should be enforced in the future,i.e,analysis or design,etc...? 2. Are you using a specific CASE tool? If so, what are main advantages and disadvantages? 3. Did you have any experience of developing s/w systems by specific OO method? If so, could you do with ease? 4. What's really needed to an engineer,who is not accustomed to OOP, to develop a software by OO paradigm?? Your opinion will help many people engaged in this area and better software development environment... Thanks in advance... PS. "I'll send my paper all of you when completed with great pleasure.." -- Dongoh Kim Graduate student K-JIST ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim @ 1996-11-06 0:00 ` Paul_Gover 1996-11-06 0:00 ` Alan Lovejoy ` (2 more replies) 1996-11-07 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz ` (6 subsequent siblings) 7 siblings, 3 replies; 79+ messages in thread From: Paul_Gover @ 1996-11-06 0:00 UTC (permalink / raw) In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes: > ... >Let me have your opinions about followings: > > 1. Is everything OK with existing oo development methods? > If not, what are needed? and what stage should be enforced in the > future,i.e,analysis or design,etc...? > ... OK, here's my 2 cents: most OO development methods concentrate too much on objects and too little on classes. This obstructs investigation of inheritance and polymorphism, making it hard to attain the benefits of OO. IMHO, in many cases this is because the design method derives from some entity modelling tool from before the days of OO, and entities are objects, not classes. Paul Gover IBM Warwick Development Group Mumbling for myself, not IBM ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Paul_Gover @ 1996-11-06 0:00 ` Alan Lovejoy 1996-11-07 0:00 ` Piercarlo Grandi ` (2 more replies) 1996-11-06 0:00 ` Jan Steinman 1996-11-06 0:00 ` Snowball 2 siblings, 3 replies; 79+ messages in thread From: Alan Lovejoy @ 1996-11-06 0:00 UTC (permalink / raw) Paul_Gover@uk.ibm.com wrote: > > In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes: > > ... > >Let me have your opinions about followings: > > > > 1. Is everything OK with existing oo development methods? > > If not, what are needed? and what stage should be enforced in the > > future,i.e,analysis or design,etc...? > > ... > > OK, here's my 2 cents: most OO development methods concentrate too much > on objects and too little on classes. This obstructs investigation of > inheritance and polymorphism, making it hard to attain the benefits of OO. > IMHO, in many cases this is because the design method derives from some > entity modelling tool from before the days of OO, and entities are objects, > not classes. Objects are objects, not classes. OO programs are systems of interacting **objects**, not systems of interacting **classes**. The architecture and design of a program is a function of what **objects** it contains and how they interact. What classes these objects may or may not be instances of is a separate issue--a fact which becomes obvious in a Self program, for example. What matters is the **interface** supported by each object, and the **role** each object plays in the program. Note that two objects may support the same interface, but be instances of different classes and/or play different roles. Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do with architecture or design of a program. Proof: any program using class inheritance can easily be converted into a completely equivalent program where all the leaf classes are root classes: one simply duplicates all the inherited methods in each leaf class. Of course, this requires either dynamic typing or Java-like interfaces, but that's a different issue. It's true that static typing and improperly using classes as type constraints "obstructs investigation of...polymorphism, making it hard to attain the benefits of OO." But blaming that on OO methodologies that focus on objects instead of classes is unjustified. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Alan Lovejoy @ 1996-11-07 0:00 ` Piercarlo Grandi 1996-11-10 0:00 ` drs ` (2 more replies) 1996-11-08 0:00 ` Paul_Gover 1996-11-12 0:00 ` Robert C. Martin 2 siblings, 3 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-07 0:00 UTC (permalink / raw) >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes: alovejoy> Objects are objects, not classes. Ok, even if there are some famous authors that don't seem to agree. alovejoy> OO programs are systems of interacting **objects**, not alovejoy> systems of interacting **classes**. Consider: class complex { private: float rho,theta; public: float proj_real(); float proj_imag(); complex operator +(complex); .... }; class rational { private: float above,below; public: float num(); float den(); rational operator +(rational); .... } .... So far this is not an OO program, according to your definition, for there are no objects whatsoever in it, only classes, and there are no ``interactions'' among classes in it either. alovejoy> The architecture and design of a program is a function of what alovejoy> **objects** it contains and how they interact. Now let's try to add some more detail: // the above plus ... main() { complex c1, c2; operator >>(cin,c1); operator >>(cin,c2); operator <<(cout,operator +(c1,c2)); // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2); exit(0); } Is this an OO program? It's hard for me to see any objects in it either for I can only see variables (memory objects, a different concept) and they don't interact with each other in any sort of interesting meaning of the word. To my naked eye the above is an (outline of an) OO program, but it contains only classes ('complex' and 'rational', variables ('c1', 'c2', 'cin', 'cout') and procedures ('main', 'operator <<', 'operator >>' 'operator +', and 'exit'). Objects do come into existence (thanks to the execution of constructors) only during the _execution_ of the program, and they are passed as arguments to various procedures at execution time too; they don't seem to be contained in the *program*, and even when they are contained in a computation created by executing the program they don't seem to interact, any more than the arguments to a procedure may be said to ``interact''. alovejoy> What classes these objects may or may not be instances of is a alovejoy> separate issue--a fact which becomes obvious in a Self alovejoy> program, for example. What matters is the **interface** alovejoy> supported by each object, alovejoy> and the **role** each object plays in the program. Note that alovejoy> two objects may support the same interface, but be instances alovejoy> of different classes and/or play different roles. What is a role that an object may play? It is usually easy to see interfaces in OO programs; for example in the above program it is easy to discern which interfaces the 'complex' and 'rational' classes have got; but what roles do objects play in the above program? I do realize that according to your definitions the above program is not an OO program (there are no objects and no interaction among them); then perhaps you could provide an example of an OO program, in which according to your definition there are objects, they ``interact'', they have interfaces, and they play roles. For the sake of appealing to a wider audience, it would be important that the example be written in something resembling C++. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-07 0:00 ` Piercarlo Grandi @ 1996-11-10 0:00 ` drs 1996-11-12 0:00 ` Piercarlo Grandi 1996-11-10 0:00 ` Vlastimil Adamovsky 1996-11-11 0:00 ` Daniel Drasin 2 siblings, 1 reply; 79+ messages in thread From: drs @ 1996-11-10 0:00 UTC (permalink / raw) Piercarlo Grandi wrote: [C++ prototypes omitted] >So far this is not an OO program, according to your definition, for >there are no objects whatsoever in it, only classes, and there are no >``interactions'' among classes in it either. This is correct. "classes" are merely prototypes in C++. "Objects" are properly instantiations, as far as C++ or smalltalk is concerned. alovejoy> The architecture and design of a program is a function of what alovejoy> **objects** it contains and how they interact. >Now let's try to add some more detail: // the above plus ... main() { complex c1, c2; //etc. } >Is this an OO program? It's hard for me to see any objects in it either >for I can only see variables (memory objects, a different concept) and >they don't interact with each other in any sort of interesting meaning >of the word. Well, c1 and c2 are indeed instantiations of the above prototype; they have a defined address and can do things (unlike the prototype). You're wrong if you think c1 and c2 are not objects; they are. entities of the class complex create their own scope, which is internal and allows internal processes. This really is quite different from C. Now, if your idea is that "Object-oriented" boils down to message sending, then I think you're correct; but by that definition there are only a few true "object-oriented" languages, and C++ is not one of them. >Objects do come into existence (thanks to the execution of constructors) >only during the _execution_ of the program, and they are passed as >arguments to various procedures at execution time too; they don't seem >to be contained in the *program*, and even when they are contained in a >computation created by executing the program they don't seem to >interact, any more than the arguments to a procedure may be said to >``interact''. This is wrong. c1 and c2 are scoped within the whole of main(). This is not really different from any globally scoped object in, say, smalltalk. You could easily cause c1 and c2 to interact, although your example does not call for much interaction. Performing an addition of two complex numbers is not really much of an "interaction" anyway because the numbers themselves are probably const. The overloaded + probably instantiates a new number, and changes nothing in the args. But let's suppose class bicycle class bicycle { Wheel w1, w2; Brake b1, b2; Frame f1; Seat s1; Freewheel fw1; //etc. public: void ride(); void slowdown(); void changegears(); //more methods for interaction between parts }; The parts model the whole. If you now instantiate an instance of class bicycle, in order of it to do anything, the parts *must* interact. So the issue of what really is "Object-oriented" turns much more on a world-view (a way of concieving a problem, perhaps) than on any particular feature such as "runtime polymorphism." Setting up a bicycle object is *qualitatively* different than doing computations about riding using C functions. Regards, DRS ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-10 0:00 ` drs @ 1996-11-12 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-12 0:00 UTC (permalink / raw) >>> "drs" == drs <drs@inxpress.net> writes: [ ... much omitted,including an outline for a class 'complex' ... ] piercarl> main() piercarl> { piercarl> complex c1, c2; piercarl> //etc. piercarl> } piercarl> Is this an OO program? It's hard for me to see any objects in piercarl> it either for I can only see variables (memory objects, a piercarl> different concept) and they don't interact with each other in piercarl> any sort of interesting meaning of the word. drs> Well, c1 and c2 are indeed instantiations of the above prototype; Which ones? (rhetorical question alert) drs> they have a defined address and can do things (unlike the drs> prototype). What can they do? (rhetorical question alert) drs> You're wrong if you think c1 and c2 are not objects; they drs> are. entities of the class complex create their own scope, which is drs> internal and allows internal processes. This really is quite drs> different from C. Oh no, oh please -- we have been on this subject for the past few months (and before that a few years ago with the "simply put an object is a variable" thread). Not again, not so soon. Oh no, not again. Well, I'll then quote high authority, Grady Booch, hoping that it will be enough: OOADWA> Suppose that we have the following declarations: OOADWA> StorageTank s1,s2; OOADWA> WaterTank w; OOADWA> NutrientTank n; OOADWA> Variables such as 's1', s2' w, and 'n' are not objects. To be OOADWA> precise, they are simply names that we use to designate OOADWA> objects of their respective types: when we say ``the object OOADWA> 's1''' we really mean the instance of 'StorageTank' denoted by OOADWA> the variable 's1'. We will explain this subtlety again in the OOADWA> next chapter. Too bad that the next chapter does not really contain a good explanation, butnthis should be enough. drs> Now, if your idea is that "Object-oriented" boils down to message drs> sending, then I think you're correct; Oh no, not again, I think I have participated in thread on this very same subject at least three times in as many years. Oh no, not again. drs> but by that definition there are only a few true "object-oriented" drs> languages, and C++ is not one of them. Oh no, not again, I think I haveparticipated in threads on this very same subject at least N times in as many years. Oh no, not again. Well, as the saying goes, repetition is the very essence of USENET, whose very essence is repetition, as somebody said. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-07 0:00 ` Piercarlo Grandi 1996-11-10 0:00 ` drs @ 1996-11-10 0:00 ` Vlastimil Adamovsky 1996-11-11 0:00 ` Piercarlo Grandi 1996-11-11 0:00 ` Daniel Drasin 2 siblings, 1 reply; 79+ messages in thread From: Vlastimil Adamovsky @ 1996-11-10 0:00 UTC (permalink / raw) pcg@aber.ac.uk (Piercarlo Grandi) wrote: >>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes: >alovejoy> Objects are objects, not classes. >Ok, even if there are some famous authors that don't seem to agree. >alovejoy> OO programs are systems of interacting **objects**, not >alovejoy> systems of interacting **classes**. >Consider: > class complex > { > private: float rho,theta; > public: float proj_real(); float proj_imag(); > complex operator +(complex); > .... > > }; > class rational > { > private: float above,below; > public: float num(); float den(); > rational operator +(rational); > .... > } > .... >So far this is not an OO program, according to your definition, for >there are no objects whatsoever in it, only classes, and there are no >``interactions'' among classes in it either. It is correct, your above definitions of whatever is not Object oriented programming. You are actually defining algorithm. This issue has been succesfully addressed by STL. >alovejoy> The architecture and design of a program is a function of what >alovejoy> **objects** it contains and how they interact. >Now let's try to add some more detail: > // the above plus ... > main() > { > complex c1, c2; > operator >>(cin,c1); operator >>(cin,c2); > operator <<(cout,operator +(c1,c2)); > // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2); > exit(0); > } >Is this an OO program? No. >To my naked eye the above is an (outline of an) OO program, but it >contains only classes ('complex' and 'rational', variables ('c1', 'c2', >'cin', 'cout') and procedures ('main', 'operator <<', 'operator >>' >'operator +', and 'exit'). It contains only one class 'complex', which is in this context a mere type. >Objects do come into existence (thanks to the execution of constructors) >only during the _execution_ of the program, and they are passed as >arguments to various procedures at execution time too; they don't seem >to be contained in the *program*, and even when they are contained in a >computation created by executing the program they don't seem to >interact, any more than the arguments to a procedure may be said to >``interact''. The OO design describes objects and their behaivor at the run-time. Behavior and classes, types and delegees and delegators can change on demand during running the program. So classes are usefull to describe behavior of a object at given time but but not at another time. I Vlastimil Adamovsky ** C++ and Smalltalk consultant ** * http://www.stepweb.com * ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-10 0:00 ` Vlastimil Adamovsky @ 1996-11-11 0:00 ` Piercarlo Grandi 1996-11-11 0:00 ` Anthony Menio 1996-11-12 0:00 ` Anthony Menio 0 siblings, 2 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-11 0:00 UTC (permalink / raw) >>> "vlad" == Vlastimil Adamovsky <vlad@world2u.com> writes: vlad> pcg@aber.ac.uk (Piercarlo Grandi) wrote: >>>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes: alovejoy> OO programs are systems of interacting **objects**, not alovejoy> systems of interacting **classes**. pcg> Consider>: pcg> class complex { pcg> private: float rho,theta; pcg> public: float proj_real(); float proj_imag(); pcg> complex operator +(complex); pcg> .... }; pcg> class rational { pcg> private: float above,below; pcg> public: float num(); float den(); pcg> rational operator +(rational); pcg> .... }; pcg> .... pcg> So far this is not an OO program, according to your definition, for pcg> there are no objects whatsoever in it, only classes, and there are pcg> no ``interactions'' among classes in it either. vlad> It is correct, your above definitions of whatever is not Object vlad> oriented programming. You are actually defining algorithm. The above defines two ADT implementations, for some sort of 'complex' and 'rational' ADTs. The implementation is a class rather than a prototype, but that does not change much; the representation is encapsulated ('private:'), and it is implied without much detail that all and only the procedures that need to access that representation are listed in the class definition. This to me seems if not an OO progam, at the very least an OO library; In the above lines there is not much (perhaps it can be implied in the '....' bits) of an algorithm, for there is no definition of a procedure of function (only declarations of them). vlad> This issue has been succesfully addressed by STL. And by RogueWave's, and by quite a few other collections of OO components/templates/classes/prototypes/...; to me STL and things of its ilk do seem to be OO programs, even if they contain no interacting objects. Then as I remarked it is well reasonable that: alovejoy> The architecture and design of a program is a function of what alovejoy> **objects** it contains and how they interact. if one rephrases it a little :-) differently; but still it seems to me that in neither class/prototype/actor based systems programs are systems of interacting objects...; systems of objects happen when a program is executed, and then they interact in some meaningful way only in actor systems, while in both class and prototype systems it is procedure instances (os perhaps threads) that interact. pcg> Now let's try to add some more detail: pcg> // the above plus ... pcg> main() pcg> { pcg> complex c1, c2; pcg> operator >>(cin,c1); operator >>(cin,c2); pcg> operator <<(cout,operator +(c1,c2)); pcg> // or more briefly: cin >> c1; cin >> c2; cout << (c1+c2); pcg> exit(0); pcg> } pcg> Is this an OO program? vlad> No. pcg> To my naked eye the above is an (outline of an) OO program, but it pcg> contains only classes ('complex' and 'rational', variables ('c1', pcg> 'c2', 'cin', 'cout') and procedures ('main', 'operator <<', pcg> 'operator >>' 'operator +', and 'exit'). vlad> It contains only one class 'complex', Well, we also have 'rational' (the second bit is an extension of the first bit, perhaps you have missed where I say "add"), which is not used though -- fairly common, any given OO program usually mentions only a small fraction of the ADT implementations provided in the environment in which it is developed. vlad> which is in this context a mere type. Well, in C++ classes are types; so it's a type. But what do you mean by "mere" here? pcg> Objects do come into existence (thanks to the execution of pcg> constructors) only during the _execution_ of the program, and they pcg> are passed as arguments to various procedures at execution time pcg> too; they don't seem to be contained in the *program*, and even pcg> when they are contained in a computation created by executing the pcg> program they don't seem to interact, any more than the arguments to pcg> a procedure may be said to ``interact''. vlad> The OO design We were actually discussing "OO programs"; but then I don't see how OO design is much different vlad> describes objects and their behaivor at the run-time. Behavior and vlad> classes, types and delegees and delegators can change on demand vlad> during running the program. So classes are usefull to describe vlad> behavior of a object at given time but but not at another time. Yes, but what's the relevance of this to the question of whether "OO programs are systems of interacting **objects**" rather than systems of modules (either classes or prototypes or actors) that ``contain'' procedures that invoke each other? Do OO programs by and large describe static relationships between modules (or parts thereof like interfaces)? Or do they describe collections of instances/clones of those modules (or their types) and how they interact? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Piercarlo Grandi @ 1996-11-11 0:00 ` Anthony Menio 1996-11-18 0:00 ` Piercarlo Grandi 1996-11-12 0:00 ` Anthony Menio 1 sibling, 1 reply; 79+ messages in thread From: Anthony Menio @ 1996-11-11 0:00 UTC (permalink / raw) On 11 Nov 1996 > > Yes, but what's the relevance of this to the question of whether "OO > programs are systems of interacting **objects**" rather than systems of > modules (either classes or prototypes or actors) that ``contain'' > procedures that invoke each other? > > Do OO programs by and large describe static relationships between > modules (or parts thereof like interfaces)? Or do they describe > collections of instances/clones of those modules (or their types) and > how they interact? > > I think the answer to this can be found in the analysis model. The analysis model descibes the objects that will be existance during the systems existance. In this model and thus the functioning system your interested in definate articals ie actual entities not classes of entities(ie currentProcess, ActiveWindow, nextTransaction, rather than definitions of the types which these are instances of) . The relationships expressed are dynamic ones as the effects of the messaging between these objects will be related to thier state. Having state is a characteristic soley of objects not classes they have attributes whuch describe abstactly the set of possible states but not states themselves. In terms of database concepts the analysis model and the functioning system descibes the extension of the system and classes the intension of the system. Thus the design model is a description system in terms of the classes and class relations that will be used to create the objects and dynamic messaging relations which exists in the functioning system. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Anthony Menio @ 1996-11-18 0:00 ` Piercarlo Grandi 1996-11-20 0:00 ` Anthony Menio 0 siblings, 1 reply; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-18 0:00 UTC (permalink / raw) >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: menio> On 11 Nov 1996 > piercarl> Yes, but what's the relevance of this to the question of piercarl> whether "OO programs are systems of interacting **objects**" piercarl> rather than systems of modules (either classes or prototypes piercarl> or actors) that ``contain'' procedures that invoke each other? piercarl> Do OO programs by and large describe static relationships piercarl> between modules (or parts thereof like interfaces)? Or do they piercarl> describe collections of instances/clones of those modules (or piercarl> their types) and how they interact? menio> I think the answer to this can be found in the analysis model. menio> The analysis model descibes the objects that will be existance menio> during the systems existance. In this model and thus the menio> functioning system your interested in definate articals ie actual menio> entities not classes of entities(ie currentProcess, ActiveWindow, menio> nextTransaction, rather than definitions of the types which these menio> are instances of) . The relationships expressed are dynamic ones menio> as the effects of the messaging between these objects will be menio> related to thier state. According to your argument, which has already been seen in slightly different guises, if a bank has a customer list application, then the analysis model will describe N million objects if the bank has N million customers. If the bank acquires a new customer, or loses a customer, then the analysis model will have to be revised, for the "objects that will be in existance during the system existance" will have changed. "think before you leap"... ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-18 0:00 ` Piercarlo Grandi @ 1996-11-20 0:00 ` Anthony Menio 1996-11-27 0:00 ` Piercarlo Grandi 0 siblings, 1 reply; 79+ messages in thread From: Anthony Menio @ 1996-11-20 0:00 UTC (permalink / raw) On 18 Nov 1996, Piercarlo Grandi wrote: > >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: > > menio> On 11 Nov 1996 > > > piercarl> Yes, but what's the relevance of this to the question of > piercarl> whether "OO programs are systems of interacting **objects**" > piercarl> rather than systems of modules (either classes or prototypes > piercarl> or actors) that ``contain'' procedures that invoke each other? > > piercarl> Do OO programs by and large describe static relationships > piercarl> between modules (or parts thereof like interfaces)? Or do they > piercarl> describe collections of instances/clones of those modules (or > piercarl> their types) and how they interact? > > menio> I think the answer to this can be found in the analysis model. > menio> The analysis model descibes the objects that will be existance > menio> during the systems existance. In this model and thus the > menio> functioning system your interested in definate articals ie actual > menio> entities not classes of entities(ie currentProcess, ActiveWindow, > menio> nextTransaction, rather than definitions of the types which these > menio> are instances of) . The relationships expressed are dynamic ones > menio> as the effects of the messaging between these objects will be > menio> related to thier state. > > According to your argument, which has already been seen in slightly > different guises, if a bank has a customer list application, then the > analysis model will describe N million objects if the bank has N million > customers. If the bank acquires a new customer, or loses a customer, > then the analysis model will have to be revised, for the "objects that > will be in existance during the system existance" will have changed. > > "think before you leap"... > > A system in which a 1:N object relationship exists and often undergoes large changes in the n side of this relationship requires a structure capable of handling these changes. An analysis model which describes the system as dynamic interactions and relations between objects is fundamental in creating such a structure. The example you mention can only be though of in terms of varying numbers of instances of a customer class, thus in terms of objects. The behavior being modeled is in terms of messages between some subset of the N customers and the list object. The very concept of sending messages to multiple copies of the same class by definition requires you to think in terms of objects. Even in class definition your thinking is in terms of a typical instance of the class being created. Implementation of behavior is defined in terms of state, state is a characteristic of objects. Example customer_list::add_client(customer *new_client) { client_vector.add(new_client); } customer::customer(char *social_security, dollars opening_deposit) { this->identity = social_security; this->current_balance = opening deposit; } the very idea of the assignment of a runtime determined parameter(an argument) to an instance variable can only be though of terms of objects. The same holds true for the idea of increasing the current client list by the new client in the above customer_list::add_client() In a pure OO environment the very act of running an application is a create message to the application from the user via the O.S. Application execution begins with instantation of a class, object creation and messaging. Thus an application as a whole is a dynamic entity with equally dynamic relationships with other such entities in other words a a subsystem of a system of interacting objects. The very idea of persistance mechanisms revolves around allowing these objects to exist in a dormant state, construction and destruction can only be thought of in terms of objects, these activities are essential to OOP execution. Thus OOP programs are interacting systems of objects. Anthony Menio I.S. Student menio@pegasus.montclair.edu Your power is your ideas, your ideas are products of perception, your perception is the product of your architecture, architecture is everything - me ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-20 0:00 ` Anthony Menio @ 1996-11-27 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-27 0:00 UTC (permalink / raw) >>> "menio" == Anthony Menio <menio@earhart.montclair.edu> writes: menio> On 18 Nov 1996, Piercarlo Grandi wrote: >>>>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: menio> On 11 Nov 1996 > piercarl> Do OO programs by and large describe static relationships piercarl> between modules (or parts thereof like interfaces)? Or do they piercarl> describe collections of instances/clones of those modules (or piercarl> their types) and how they interact? menio> I think the answer to this can be found in the analysis model. menio> The analysis model descibes the objects that will be existance menio> during the systems existance. In this model and thus the menio> functioning system your interested in definate articals ie actual menio> entities not classes of entities(ie currentProcess, ActiveWindow, menio> nextTransaction, rather than definitions of the types which these menio> are instances of) . The relationships expressed are dynamic ones menio> as the effects of the messaging between these objects will be menio> related to thier state. piercarl> According to your argument, which has already been seen in piercarl> slightly different guises, if a bank has a customer list piercarl> application, then the analysis model will describe N million piercarl> objects if the bank has N million customers. If the bank piercarl> acquires a new customer, or loses a customer, then the piercarl> analysis model will have to be revised, for the "objects that piercarl> will be in existance during the system existance" will have piercarl> changed. menio> A system in which a 1:N object relationship exists I am not familair with this concept: what is an 1:N object relationship? A customer list application has N million customer objects, which can be related among them in many ways; for example there might be a "provided_reference" relationships between one object and many others, or a "cosignatory" relationships between several customer objects (and an account object, presumably). menio> and often undergoes large changes in the n side of this menio> relationship requires a structure capable of handling these menio> changes. An analysis model which describes the system as dynamic menio> interactions and relations between objects is fundamental in menio> creating such a structure. Why is it fundamental to model N million objects, as opposed to just modeling their type/class/prototype? menio> The example you mention can only be though of in terms of varying menio> numbers of instances of a customer class, thus in terms of menio> objects. I frankly cannot think in those terms; I can only think of it in terms of classes, for otherwise one has to keep track of all the individual relationships among individual objects. That's sometthing computers are good at; when I write a program i want to deal with abstractions, be they classes or prototypes. menio> The behavior being modeled is in terms of messages between some menio> subset of the N customers and the list object. Which list object? I haven't seen any mention of a list object. What I have seen mentioned is a list of N million customers; this list may be implemented as a list object, or anything else; then there may be M million customer accounts, X million transactions between those accounts, and so on. menio> The very concept of sending messages to multiple copies of the menio> same class Which concept? Where has this concept arosen? menio> by definition requires you to think in terms of objects. Why? It seems to me that to model relationships between groups of essentially similar entities one should well describe them abstractly in terms of the types of those entities. menio> Even in class definition your thinking is in terms of a typical menio> instance of the class being created. Really? Consider some sort of 'complex' class: what is a ``typical'' complex number? menio> Implementation of behavior is defined in terms of state, state is menio> a characteristic of objects. Really? What is the state of the object representing the complex number (2,3i)? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Piercarlo Grandi 1996-11-11 0:00 ` Anthony Menio @ 1996-11-12 0:00 ` Anthony Menio 1996-11-18 0:00 ` Piercarlo Grandi 1 sibling, 1 reply; 79+ messages in thread From: Anthony Menio @ 1996-11-12 0:00 UTC (permalink / raw) On 11 Nov 1996, Piercarlo Grandi wrote: > > Do OO programs by and large describe static relationships between > modules (or parts thereof like interfaces)? Or do they describe > collections of instances/clones of those modules (or their types) and > how they interact? > > In addition to the comments made in my last post I though following would offer a clear and correct answer. Systems with an object oriented architecture consist of objects. Classes are merely blue prints to create objects from. Just as a building is made of beams, rooms,prefab components and cars of transmissions,radiators,exhust systems system and not the blueprints of these things so with an OO software system. The essence of OO architecture is the viewing of abstract systems in terms of the real world, ie as if the were physical systems. Thus it a fundamental process to resolve such questions through examing systems of the source domain of the metaphor to gain a better understanding of conceptual issues in the target domain. Anthony Menio I.S. Student menio@pegasus.montclair.edu ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Anthony Menio @ 1996-11-18 0:00 ` Piercarlo Grandi 1996-11-19 0:00 ` Anthony Menio 0 siblings, 1 reply; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-18 0:00 UTC (permalink / raw) >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: menio> On 11 Nov 1996, Piercarlo Grandi wrote: piercarl> Do OO programs by and large describe static relationships piercarl> between modules (or parts thereof like interfaces)? Or do they piercarl> describe collections of instances/clones of those modules (or piercarl> their types) and how they interact? menio> In addition to the comments made in my last post I though menio> following would offer a clear and correct answer. Systems with an menio> object oriented architecture consist of objects. Classes are menio> merely blue prints to create objects from. Just as a building is menio> made of beams, rooms,prefab components and cars of menio> transmissions,radiators,exhust systems system and not the menio> blueprints of these things so with an OO software system. "Just as" is a bit ambitious above, isn't it? Just look at how buildings are built, and build OO systems accordingly. I wonder why nobody :-) ever realized it is so simple. It is also extremely convenient for the sake of terseness to make statements without any sort of supporting argument. It reminds me of the writing style of several OO-speak gurus. menio> The essence of OO architecture is the viewing of abstract systems menio> in terms of the real world, ie as if the were physical systems. Please describe how you would view an OO program that does calculations using matrixes of complex numbers as if it were a physical system... menio> Thus it a fundamental process to resolve such questions through menio> examining systems of the source domain of the metaphor to gain a menio> better understanding of conceptual issues in the target domain. Continue writing in this style and you'll become a wealthy OO-speak guru like Brady Gooch or Steve Mellor. ``A sucker is born every minute.'' menio> Anthony Menio I.S. Student menio@pegasus.montclair.edu Just as a curiosity: could you post the titles of the OO books from which you have gleaned the above statements? I must confess that I have some expectations as to what they can be... ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-18 0:00 ` Piercarlo Grandi @ 1996-11-19 0:00 ` Anthony Menio 1996-11-27 0:00 ` Piercarlo Grandi 0 siblings, 1 reply; 79+ messages in thread From: Anthony Menio @ 1996-11-19 0:00 UTC (permalink / raw) To: Piercarlo Grandi On 18 Nov 1996, Piercarlo Grandi wrote: > >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: > > menio> On 11 Nov 1996, Piercarlo Grandi wrote: > > piercarl> Do OO programs by and large describe static relationships > piercarl> between modules (or parts thereof like interfaces)? Or do they > piercarl> describe collections of instances/clones of those modules (or > piercarl> their types) and how they interact? > > menio> In addition to the comments made in my last post I though > menio> following would offer a clear and correct answer. Systems with an > menio> object oriented architecture consist of objects. Classes are > menio> merely blue prints to create objects from. Just as a building is > menio> made of beams, rooms,prefab components and cars of > menio> transmissions,radiators,exhust systems system and not the > menio> blueprints of these things so with an OO software system. > > "Just as" is a bit ambitious above, isn't it? Just look at how buildings > are built, and build OO systems accordingly. I wonder why nobody :-) > ever realized it is so simple. It is also extremely convenient for the > sake of terseness to make statements without any sort of supporting > argument. It reminds me of the writing style of several OO-speak gurus. > Evidence ? witness Component architectures this is a prime example of reuse of concepts and methods of construction from the physical domain. > menio> The essence of OO architecture is the viewing of abstract systems > menio> in terms of the real world, ie as if the were physical systems. > > Please describe how you would view an OO program that does calculations > using matrixes of complex numbers as if it were a physical system... > I think the problem here is your interpretation of of the phrase "as if they were physical systems". The meaning I wished conveyed is in "in terms of conceptually" not of "not in terms of literally". As far as your specific example wouldn't such a OOP program still consist of instances of needed classes and method invocations between them ? Hence the ideas of classification, instances, encapsulation would still be key to design and evident in the runtime system. These concepts are paramount to our viewing of real world systems, of physical systems, and such systems are the source of these ideas. OO is every where in the real world isn't the blue prints for a new Buick LeSabre simply a class ? The interface to an instance of this class(brakes,gas pedal,sterring) provide an implementation independent means of communicating with it. Thus if this is so then isn't the OO program for matrix calculations modeled in terms of the physical world? > menio> Thus it a fundamental process to resolve such questions through > menio> examining systems of the source domain of the metaphor to gain a > menio> better understanding of conceptual issues in the target domain. > > Continue writing in this style and you'll become a wealthy OO-speak guru > like Brady Gooch or Steve Mellor. ``A sucker is born every minute.'' > Drwaing parallels from my ideas and communication skills to those of accepted OO speakers is hardly an argument against my ideas and communication skills. In fact thanks for the complement :) > menio> Anthony Menio I.S. Student menio@pegasus.montclair.edu > > Just as a curiosity: could you post the titles of the OO books from > which you have gleaned the above statements? I must confess that I have > some expectations as to what they can be... > > If you are of the opinion that my posting are simply a regurgitation for the exposings of the authors I have read, rather than critical reflections upon their ideas, than you should take this argument up with them. I'm not sure of Ivar Jacobson's and Grady Booch's email addresses but I'm sure you can find them someplace. Anthony Menio I.S. Student menio@pegasus.montclair.edu Your power is your ideas, your ideas are products of perception, your perception is the product of your architecture, architecture is everything - me ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-19 0:00 ` Anthony Menio @ 1996-11-27 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-27 0:00 UTC (permalink / raw) >>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: menio> On 18 Nov 1996, Piercarlo Grandi wrote: >>>>>> "menio" == Anthony Menio <menio@pegasus.montclair.edu> writes: menio> On 11 Nov 1996, Piercarlo Grandi wrote: piercarl> Do OO programs by and large describe static relationships piercarl> between modules (or parts thereof like interfaces)? Or do they piercarl> describe collections of instances/clones of those modules (or piercarl> their types) and how they interact? menio> In addition to the comments made in my last post I though menio> following would offer a clear and correct answer. Systems with an menio> object oriented architecture consist of objects. Classes are menio> merely blue prints to create objects from. Just as a building is menio> made of beams, rooms,prefab components and cars of menio> transmissions,radiators,exhust systems system and not the menio> blueprints of these things so with an OO software system. piercarl> "Just as" is a bit ambitious above, isn't it? Just look at how piercarl> buildings are built, and build OO systems accordingly. I piercarl> wonder why nobody :-) ever realized it is so simple. It is piercarl> also extremely convenient for the sake of terseness to make piercarl> statements without any sort of supporting argument. It reminds piercarl> me of the writing style of several OO-speak gurus. menio> Evidence ? Easy enough: OOADWA> In the field of artificial intelligence, developments in OOADWA> knowledge representation have contributed to an understanding OOADWA> of an object-oriented world. In 1975, Minsky first proposed a OOADWA> theory of frames to represent real-world objects as perceived OOADWA> by image and natural language recognition systems. Since then, OOADWA> frames have been used as the architectural foundation for a OOADWA> variety of intelligent systems. OOADWA> Lastly, philosophy and cognitive science have contributed to the OOADWA> advancement of the object model. The idea that the world could OOADWA> be viewed either in terms of objects or processes was Greek OOADWA> innovation, and in the seventeenth century, we find Descartes OOADWA> observing that humans naturally apply an object-oriented view OOADWA> of the world. In the twentieth century, Rand expanded upon OOADWA> these themes in her philosophy of objectivist epistemology. OOADWA> More recently, Minsky has proposed a model of human OOADWA> intelligence in which he considers the mind to be organized as OOADWA> a society of otherwise mindless agents. Minsky argues that OOADWA> only through the cooperative behaviour of these agents do we OOADWA> find what we call _intelligence_. This is an excellent example of the work on an OO-speak guru, and consists of a series of rather daring statements unsupported by any argument. menio> witness Component architectures this is a prime example of reuse menio> of concepts and methods of construction from the physical domain. Really? Please exemplify how component architectures are such a prime example. In fact I would regard them as a prime example that concepts and methods of construction in the software domain are nowhere like those of the physical domain. Software component reuse is uniquely useful and powerful precisely because it is not at all anything like in the physical word: for reuse of abstractions has uniquely convenient properties that are simply impossible to achieve in the physical world. menio> The essence of OO architecture is the viewing of abstract systems menio> in terms of the real world, ie as if the were physical systems. piercarl> Please describe how you would view an OO program that does piercarl> calculations using matrixes of complex numbers as if it were a piercarl> physical system... menio> I think the problem here is your interpretation of of the phrase menio> "as if they were physical systems". The meaning I wished conveyed menio> is in "in terms of conceptually" not of "not in terms of menio> literally". Wonderful! How would you view software systems "in terms of conceptually" "as if they were physical systems". Let me say that I suspect that the "conceptually" bit will be amazingly flexible. menio> As far as your specific example wouldn't such a OOP program still menio> consist of instances of needed classes and method invocations menio> between them ? Hence the ideas of classification, instances, menio> encapsulation would still be key to design and evident in the menio> runtime system. These concepts are paramount to our viewing of menio> real world systems, of physical systems, and such systems are the menio> source of these ideas. Amazing news from America! Just consider encapsulation: if you really think that it "paramount to our viewing of real world systems" please exemplify a real world system which involves encapsulation. menio> OO is every where in the real world isn't the blue prints for a menio> new Buick LeSabre simply a class ? No. It is isn't even remotely so. A class is a mental construct, precisely defined formal entity; a set of blueprints are not even remotely anything like that. menio> The interface to an instance of this class(brakes,gas menio> pedal,sterring) provide an implementation independent means of menio> communicating with it. Do you really think that a pedal is anything remotely related to a method or an attribute? menio> Thus if this is so then isn't the OO program for matrix menio> calculations modeled in terms of the physical world? Well, I am seriously unable to see how. To me your arguments above are incomprehensible gibberish, for you mix in various types of analogies entities that to me are on entirely different levels and domains of discourse. You have mentioned "classification, instances, encapsulation", which are purely abstract mental activities, and nowhere even remotely related to the physical world. menio> Thus it a fundamental process to resolve such questions through menio> examining systems of the source domain of the metaphor to gain menio> a better understanding of conceptual issues in the target menio> domain. piercarl> Continue writing in this style and you'll become a wealthy piercarl> OO-speak guru like Brady Gooch or Steve Mellor. ``A sucker is piercarl> born every minute.'' menio> Drwaing parallels from my ideas and communication skills to those menio> of accepted OO speakers is hardly an argument against my ideas menio> and communication skills. In fact thanks for the complement :) It is not an argument against or for: it is merely a good omen for your future wealth. Your phrase above is admirable: it is entirely content-free, but it sounds profound and important, and uses a good number of buzzword: "metaphor", "conceptual", "issues", "domain". This is going to sell very well. As OOADWA has demonstrated, there are a lot of happy customers that are prepared to pay quite a bit of money to read this sort of speak. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-07 0:00 ` Piercarlo Grandi 1996-11-10 0:00 ` drs 1996-11-10 0:00 ` Vlastimil Adamovsky @ 1996-11-11 0:00 ` Daniel Drasin 1996-11-12 0:00 ` Anthony Menio 2 siblings, 1 reply; 79+ messages in thread From: Daniel Drasin @ 1996-11-11 0:00 UTC (permalink / raw) Piercarlo Grandi wrote: > > >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes: > > alovejoy> Objects are objects, not classes. > > Ok, even if there are some famous authors that don't seem to agree. > > alovejoy> OO programs are systems of interacting **objects**, not > alovejoy> systems of interacting **classes**. > > Consider: > > class complex > { > private: float rho,theta; > public: float proj_real(); float proj_imag(); > complex operator +(complex); > .... > > }; > > class rational > { > private: float above,below; > public: float num(); float den(); > rational operator +(rational); > .... > } > > .... > > > To my naked eye the above is an (outline of an) OO program, but it > contains only classes ('complex' and 'rational', variables ('c1', 'c2', > 'cin', 'cout') and procedures ('main', 'operator <<', 'operator >>' > 'operator +', and 'exit'). [Bunch of more stuff that only includes class descriptions/definitions] > > Objects do come into existence (thanks to the execution of constructors) > only during the _execution_ of the program, ... > [More examples/discussions along the same lines -------------------------------Break------------------------------ You are both right (and wrong). The question is, what is the point of the distinction. P.G. Just 'cause you can't "see" the objects doesn't mean that they're not there. E.g. A psychiatry textbook will describe behavior of "humans," "men," and "women." These are types but clearly in actual application, these "laws of psychiatry" apply to the actual individual people involved. Smalltalk, C++, and java use what's called "class-based programming" which means that the behavior of individual objects is described by its type or class. Therefor classes will be manipulated in order to affect the behavior of objects. Which leads back to by origional question: What is the point of the distinction? What is the point of saying that an OO program is the interaction of objects (and not classes)? If the point is to direct the student to understand the runtime behavior that needs to be focused on, then objects are what the program consists of (ognoring the reflective meta abilities...). However, if the aim is to understand what must be created at compile time in order to create a program, then "classes" are the elements are the program. Dan -- Daniel Drasin Applied Reasoning Systems Corporation drasin@arscorp.com 2840 Plaza Place, Suite 325 (919)-781-7997 Raleigh, NC 27612 http://www.arscorp.com ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Daniel Drasin @ 1996-11-12 0:00 ` Anthony Menio 0 siblings, 0 replies; 79+ messages in thread From: Anthony Menio @ 1996-11-12 0:00 UTC (permalink / raw) On Mon, 11 Nov 1996, Daniel Drasin wrote > You are both right (and wrong). The question is, what is the point of > the distinction. P.G. Just 'cause you can't "see" the objects doesn't > mean that they're not there. E.g. A psychiatry textbook will describe > behavior of "humans," "men," and "women." These are types but clearly > in actual application, these "laws of psychiatry" apply to the actual > individual people involved. > > Smalltalk, C++, and java use what's called "class-based programming" > which > means that the behavior of individual objects is described by its > type or class. Therefor classes will be manipulated in order to affect > the behavior of objects. Which leads back to by origional question: > What is the point of the distinction? What is the point of saying > that an OO program is the interaction of objects (and not classes)? > If the point is to direct the student to understand the runtime behavior > that needs to be focused on, then objects are what the program consists > of (ognoring the reflective meta abilities...). However, if the aim > is to understand what must be created at compile time in order to > create a program, then "classes" are the elements are the program. > > Dan The classes are simply blue prints of the the objects which can be created, and thus describe the attributes and behavior of objects. The runtime system consists of objects and these are what must be specified and the interactions between them at implementation time. Your source code consists of instances of these classes and the messages you designate to have happen and the states and messages these result in across the system. The messages you designate might simply create the system (constructors) and determine interobject relations and than wait for user messages.The system you build is thus described by the objects created and the methods you specify to be called and the states these create and manipulate a runtime. Classes are simply blueprints and thus describe the domain of states and possible behaviors an instance can assume. A software system consists of assumed behavoirs and determined behavoirs in response to runtime user messages and thus of objects. In terms of source code your system is really object creations and method invocations that occur at runtime implied by code like the following: Application my_App(); myapp.setDbase("Oracle"); FileSever netsever10(CURRENT_IP); requestObject *action= application.idle(); if (interupt) { netserver.request(requestObject); myapp.continue(requestObject); } further more even this is simply a blue print for the system as a whole the true system only exists at runtime however even its implementation description refers to definite articals to be created ie objects. I think this distinction maybe subtle but is important. Anthony Menio I.S. Student menio@pegasus.montclair.edu Your power is your ideas, your ideas are products of perception, your perception is the product of your architecture, architecture is everything - me ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Alan Lovejoy 1996-11-07 0:00 ` Piercarlo Grandi @ 1996-11-08 0:00 ` Paul_Gover 1996-11-08 0:00 ` Ell ` (2 more replies) 1996-11-12 0:00 ` Robert C. Martin 2 siblings, 3 replies; 79+ messages in thread From: Paul_Gover @ 1996-11-08 0:00 UTC (permalink / raw) In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes: > ... >The architecture and design of a program is a function of what **objects** it contains and >how they interact. What classes these objects may or may not be instances of is a separate >issue--a fact which becomes obvious in a Self program, for example. What matters is the >**interface** supported by each object, and the **role** each object plays in the program. >Note that two objects may support the same interface, but be instances of different >classes and/or play different roles. > >Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do >with architecture or design of a program. Proof: any program using class inheritance can >easily be converted into a completely equivalent program where all the leaf classes are root >classes: one simply duplicates all the inherited methods in each leaf class. > ... Alan, If you restrict your statements above to "architecture" or "analysis" I'd be in complete agreement. However, I disagree when it comes to design; this might be a difference in our view of where to separate design from coding. My view is that design includes implementation detail such as inheritance. I most certainly consider that "OO development methods" should address it. I think from your statement about converting to equivalent programs indicates you consider implementation to be outside the scope of the design (since you describe two different implementations for the same design); in that case, do you think that questions of inheritance and so forth are not part of the development method? I think this is dangerous; in your example, the coverted program has large amounts of duplicated code, so making changes is harder because the programmer has to find all occurrences of the duplicated code, and we have lost one of the benefits of OO. Paul Gover IBM Warwick Development Group Mumbling for myself, not IBM ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-08 0:00 ` Paul_Gover @ 1996-11-08 0:00 ` Ell 1996-11-08 0:00 ` Alan Lovejoy 1996-11-08 0:00 ` Alan Lovejoy 1996-11-10 0:00 ` vlad 2 siblings, 1 reply; 79+ messages in thread From: Ell @ 1996-11-08 0:00 UTC (permalink / raw) Paul_Gover@uk.ibm.com wrote: : In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes: : >Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do : >with architecture or design of a program. Proof: any program using class inheritance can : >easily be converted into a completely equivalent program where all the leaf classes are root : >classes: one simply duplicates all the inherited methods in each leaf class. : > ... : I think from your statement about converting to equivalent programs indicates you : consider implementation to be outside the scope of the design (since you describe two : different implementations for the same design); in that case, do you think that : questions of inheritance and so forth are not part of the development method? : I think this is dangerous; in your example, the coverted program has large amounts of : duplicated code, so making changes is harder because the programmer has to find all : occurrences of the duplicated code, and we have lost one of the benefits of OO. I agree with you that inheritance should be more than a means of code sharing. But it seems he is saying we can take all of the methods declared and defined along the branch of an inheritance hierarchy and aggregate them in root classes. Perhaps he will clarify. Elliott ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-08 0:00 ` Ell @ 1996-11-08 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Ell 0 siblings, 1 reply; 79+ messages in thread From: Alan Lovejoy @ 1996-11-08 0:00 UTC (permalink / raw) Ell wrote: > > Paul_Gover@uk.ibm.com wrote: > : In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes: > : >Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do > : >with architecture or design of a program. Proof: any program using class inheritance can > : >easily be converted into a completely equivalent program where all the leaf classes are root > : >classes: one simply duplicates all the inherited methods in each leaf class. > : > ... > > : I think from your statement about converting to equivalent programs indicates you > : consider implementation to be outside the scope of the design (since you describe two > : different implementations for the same design); in that case, do you think that > : questions of inheritance and so forth are not part of the development method? > : I think this is dangerous; in your example, the coverted program has large amounts of > : duplicated code, so making changes is harder because the programmer has to find all > : occurrences of the duplicated code, and we have lost one of the benefits of OO. > > I agree with you that inheritance should be more than a means of code > sharing. But it seems he is saying we can take all of the methods > declared and defined along the branch of an inheritance hierarchy and > aggregate them in root classes. Perhaps he will clarify. I am saying that all classes could be root classes--that is, one can have classes and objects without inheritance, and construct objects and programs that have exactly the same functionality as those that use inheritance. The only difference is the amount of code that must be written, and the effort required to make certain changes in the program. The point is that whether or not one uses inheritance does not change the **design** of the program at the architectural level at which a design methodology should concern itself (although using or not using inheritance can be said to be a difference in design, it is a physical implementation difference, not an architectural difference). Using inheritance versus duplicating code does not in itself change what an object or program does. Consider an argument from the opposite direction: One can construct many very different programs using the very same class library. Let's say the class library has 26 leaf classes, named A through Z. One program can be started by instantiating an instance of class M, and then sending it the message "startUpProgram1." Another program can be started by instantiating an instance of class C, and sending it the message "doSomeStuff." Either program may instantiate objects of any class (A through Z), and send whatever messages such instances will understand. The set of possible programs in this situations is a function of what messages can be understood by which objects, and what each method does. The inheritance hierarchy used to povide each object with a set of messages it can understand makes no difference. If the same class hierarchy can be used to create many different programs (without defining any new classes or methods), then it should be obvious that the class inheritance hierarchy and program architecture and design are not at all the same things! -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-08 0:00 ` Alan Lovejoy @ 1996-11-13 0:00 ` Ell 0 siblings, 0 replies; 79+ messages in thread From: Ell @ 1996-11-13 0:00 UTC (permalink / raw) Alan Lovejoy (alovejoy@concentric.net) wrote: : If the same class hierarchy can be used to create many different : programs : (without defining any new classes or methods), then it should be obvious : that the class inheritance hierarchy and program architecture and design : are not at all the same things! Earlier I should have said that using the term "design" in a non-standard way can lead to incorrect thinking about related issues. I think you need to distinguish analysis from arcitecture from design. From what I gather in my experience in and readings on the development phases, analysis examines requirements and traditionally in sw engineering posits a logical solution. Architecture takes that and creates an overall physical design for implementation based in large part on language. Design is mostly considered to be subsystem and category/object creation - though architecture is the first part of it. I agree with you however that polymorphism/subtstitution in analysis should be portrayed as a kind of non-specific (indefinite :-) generalization rather than inheritance. And that inheritance if applicable should only first show up in architectural blueprints. Elliott ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-08 0:00 ` Paul_Gover 1996-11-08 0:00 ` Ell @ 1996-11-08 0:00 ` Alan Lovejoy [not found] ` <6KZQfjK-3RB@herold.franken.de> 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Bill Gooch 1996-11-10 0:00 ` vlad 2 siblings, 2 replies; 79+ messages in thread From: Alan Lovejoy @ 1996-11-08 0:00 UTC (permalink / raw) Paul_Gover@uk.ibm.com wrote: > > In <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> writes: > > ... > >The architecture and design of a program is a function of what **objects** it contains and > >how they interact. What classes these objects may or may not be instances of is a separate > >issue--a fact which becomes obvious in a Self program, for example. What matters is the > >**interface** supported by each object, and the **role** each object plays in the program. > >Note that two objects may support the same interface, but be instances of different > >classes and/or play different roles. > > > >Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do > >with architecture or design of a program. Proof: any program using class inheritance can > >easily be converted into a completely equivalent program where all the leaf classes are root > >classes: one simply duplicates all the inherited methods in each leaf class. > > ... > > Alan, If you restrict your statements above to "architecture" or "analysis" I'd be in > complete agreement. However, I disagree when it comes to design; this might be a > difference in our view of where to separate design from coding. My view is that design > includes implementation detail such as inheritance. I most certainly consider that > "OO development methods" should address it. I think you've hit the nail on the head. I do distinguish between "design" and "coding". To me, the "design" of a program is a language-independent abstraction. Implementation inheritance is a coding issue. It's about how to express the program in a programming notation with the least amount of code duplication and/or the least amount of code changes when requirements change. > I think from your statement about converting to equivalent programs indicates you > consider implementation to be outside the scope of the design (since you describe two > different implementations for the same design); in that case, do you think that > questions of inheritance and so forth are not part of the development method? I think implementation inheritance is overemphasized. Many seem to think that the class hierarchy **is** the design! As I noted in another post: the same class hiearchy may permit the specification of many different programs, each with a different architecture and design. > I think this is dangerous; in your example, the coverted program has large amounts of > duplicated code, so making changes is harder because the programmer has to find all > occurrences of the duplicated code, and we have lost one of the benefits of OO. Hey, I'm not saying that inheritance is not a good thing! Far from it! Yes, the "converted program" has those problems, but I wasn't recommending that programs be coded that way, but rather pointing out that they could be. I was hoping that contemplation of that fact would illuminate the difference between design, class hiararchies and implementation inheritance. The issues that a design methodology should address with respect to implementation inheritance would be questions such as the following: * Just because two objects have the same behavior may or may not mean that they should inherit the shared behavior. The methodology should provide the guidance needed to resolve this issue (is the fact that the behavior is the same simply accidental, or does it depend upon some reliable invariant? How likely is it that a changed requirement will necessitate changing the behavior of one of the objects, but not the other?). * When should delegation be used instead of inheritance? * When should the Strategy pattern be used instead of inheritance? However, implementation inheritance should be treated as a refinement of the design, not as the body and soul of it. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
[parent not found: <6KZQfjK-3RB@herold.franken.de>]
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t [not found] ` <6KZQfjK-3RB@herold.franken.de> @ 1996-11-10 0:00 ` Chris 1996-11-10 0:00 ` Vlastimil Adamovsky 0 siblings, 1 reply; 79+ messages in thread From: Chris @ 1996-11-10 0:00 UTC (permalink / raw) OOP design is interresting for two points. First, it may be a way to think about/to solve your problem. Just a different approach (not better, not worse than others). You may not have here to really think about inheritance or polymorphism. Second, when designing your solution, you may think about reusing what you found. Then inheritance and polymorphism are useful. What's making OOP a better approach than other non-OOP paradigms is that you can orient your design toward the present problem AND the futures at the same time (could get it a little longer, thus). -- Chris, drunk philosoph and bad programmer -------------------------------------------------------------------- "The nail pulling up calls the hammer" zen proverb > > I think implementation inheritance is overemphasized. Many seem to think > > that the class hierarchy **is** the design! > > > As I noted in another post: the > > same class hiearchy may permit the specification of many different programs, > > each with a different architecture and design. > > This is possible, but is it useful? If my implementation hierarchy differs > too far from the design hierarchy, I'd expect horrible costs just to keep > them in sync. > > If the objects involved are design objects, I'd take a long, hard look at > the classes involved. If two objects have identical behaviour, and I feel > they shouldn't go in the same class, then I probably forgot to include > some behaviour that differs. (Or behaviour that might differ in the > future. In that case, the future evolution paths should be fixed by some > constraints on the class.) > > > * When should delegation be used instead of inheritance? > > > > * When should the Strategy pattern be used instead of inheritance? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-10 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Chris @ 1996-11-10 0:00 ` Vlastimil Adamovsky 0 siblings, 0 replies; 79+ messages in thread From: Vlastimil Adamovsky @ 1996-11-10 0:00 UTC (permalink / raw) "Chris" <gaijin@infonie.fr> wrote: >Second, when designing your solution, you may think about reusing what you >found. Then inheritance and polymorphism are useful. Inheritance can be a maintanance nightmare. To be really able to reuse inheritance effeciently. you need source code. Thus, inheritance is very usefull for in-house development. When you use objects written by other companies, you should use aggregation instead. Approach of Microsoft's OLE is surprisingly effecient and reusability is high. Vlastimil Adamovsky ** C++ and Smalltalk consultant ** * http://www.stepweb.com * ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-08 0:00 ` Alan Lovejoy [not found] ` <6KZQfjK-3RB@herold.franken.de> @ 1996-11-11 0:00 ` Bill Gooch 1996-11-12 0:00 ` Alan Lovejoy 1996-11-12 0:00 ` Jan Steinman 1 sibling, 2 replies; 79+ messages in thread From: Bill Gooch @ 1996-11-11 0:00 UTC (permalink / raw) To: Alan Lovejoy Alan Lovejoy wrote: > > I think you've hit the nail on the head. I do distinguish between "design" and "coding". > > To me, the "design" of a program is a language-independent abstraction. Implementation > inheritance is a coding issue.... I'd like to hear more about how you think design can be done independent of language, and what such a "design" would look like. I can see that the most abstract levels of design can be language-independent, but refinement from this level is an essential aspect (IMO) of doing good design. Such refinement necessarily goes down through layers including language, frame- work, database,... dependencies; in fact, it takes into account *all* requirements, including hardware constraints. If you don't agree that all of this is important in producing good designs, then I have a question: what do you call a program specification, not involving code, which does take these issues into account? I think it is impossible to progress very far from a domain model into design without considering target language, and the other things I've mentioned. A very abstract design, not considering these issues, may be useful some of the time, but the design one actually implements *must* consider them. > Many seem to think that the class hierarchy **is** the design! ... Well, I do not. But there are many levels of design, and it is important to ultimately be specific. > The issues that a design methodology should address with respect to implementation inheritance > would be questions such as the following: > > * Just because two objects have the same behavior may or may not mean that they should > inherit the shared behavior. The methodology should provide the guidance needed to > resolve this issue (is the fact that the behavior is the same simply accidental, or > does it depend upon some reliable invariant? How likely is it that a changed requirement > will necessitate changing the behavior of one of the objects, but not the other?). > > * When should delegation be used instead of inheritance? > > * When should the Strategy pattern be used instead of inheritance? I agree that IWBNI methods could help with these things. I don't know of any method that even comes close, however. This is why design remains largely a black art - not the best situation, but it's the way things are. I'd really like to hear from anyone who can suggest how to address questions such as the ones Alan has raised here in a method(olog)ical or systematic fashion. > However, implementation inheritance should be treated as a refinement of the design, not > as the body and soul of it. From the last, I gather that in some sense, we are in agreement. But again, what do you call this refinement, if it isn't another (more specific, closer to code) layer of design? -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Bill Gooch @ 1996-11-12 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Ell ` (2 more replies) 1996-11-12 0:00 ` Jan Steinman 1 sibling, 3 replies; 79+ messages in thread From: Alan Lovejoy @ 1996-11-12 0:00 UTC (permalink / raw) Bill Gooch wrote: > > Alan Lovejoy wrote: > > > > I think you've hit the nail on the head. I do distinguish between "design" and "coding". > > > > To me, the "design" of a program is a language-independent abstraction. Implementation > > inheritance is a coding issue.... > > I'd like to hear more about how you think design can be done > independent of language, and what such a "design" would look > like. I can see that the most abstract levels of design can > be language-independent, but refinement from this level is an > essential aspect (IMO) of doing good design. Such refinement > necessarily goes down through layers including language, frame- > work, database,... dependencies; in fact, it takes into account > *all* requirements, including hardware constraints. > > If you don't agree that all of this is important in producing > good designs, then I have a question: what do you call a > program specification, not involving code, which does take > these issues into account? Oh dear. I think what we have here is merely :-) a terminology problem. There is a difference between design methodology, the process of producing a design, and the result of that process. Unfortunately, the term "design" (without modifiers) can be applied to any or all of these things. Please believe that I am well aware of the fact that one absolutely must take the idiosyncracies of the implementation technology (such as the programming language) into account in desgining and coding a program. I'm sorry that so many people seem to think I have suggested otherwise! Any "program specification" that could be used to actually execute a program, or generate an executable program, is by definition a program text, and the notation in which it is written is in effect a programming language. "Programming languages" such as C or Smalltalk are designed so that human beings find it convenient to write program texts in them, and also so that computer programs can translate such texts into equivalent programs that execute efficiently on typical hardware. Design notations have a different purpose: to communicate what the design of the program is to human readers--often ommitting details that should be specified if the program actually needs to be executed by a computer. However, those details should be **optionally** specifiable, so that those cases in which such details are important at the "design level" can be dealt with there. My thesis is that a design **methodology** should be able to handle designing a program regardless of language, although it will certainly need to take the differences between langauges into account. If I have to use a completely different methodology for each part of the system that is implemented in a different language, something is wrong. Similarly, the design notation should be flexible enough to handle any and all implementation languages. One may use different capabilities of the notation and/or and specify different designs due to the intended target language. But if the notation becomes completely worthless in the face of an implementation language such as Self, perhaps there is something wrong with the notation (and/or its underlying object metamodel) at a fundamental level. > I think it is impossible to progress very far from a domain > model into design without considering target language, and > the other things I've mentioned. A very abstract design, not > considering these issues, may be useful some of the time, but > the design one actually implements *must* consider them. > > > Many seem to think that the class hierarchy **is** the design! ... > > Well, I do not. But there are many levels of design, and > it is important to ultimately be specific. Agreed. I am reacting to all the times I've seen people start their design process by drawing class hierarchies. > > The issues that a design methodology should address with respect to implementation inheritance > > would be questions such as the following: > > > > * Just because two objects have the same behavior may or may not mean that they should > > inherit the shared behavior. The methodology should provide the guidance needed to > > resolve this issue (is the fact that the behavior is the same simply accidental, or > > does it depend upon some reliable invariant? How likely is it that a changed requirement > > will necessitate changing the behavior of one of the objects, but not the other?). > > > > * When should delegation be used instead of inheritance? > > > > * When should the Strategy pattern be used instead of inheritance? > > I agree that IWBNI methods could help with these things. > I don't know of any method that even comes close, however. > This is why design remains largely a black art - not the > best situation, but it's the way things are. I'd really > like to hear from anyone who can suggest how to address > questions such as the ones Alan has raised here in a > method(olog)ical or systematic fashion. Yep. The methodologists have some work to do. I think patterns have started the right things happening in this regard. > > However, implementation inheritance should be treated as a refinement of the design, not > > as the body and soul of it. > > From the last, I gather that in some sense, we are in > agreement. But again, what do you call this refinement, > if it isn't another (more specific, closer to code) layer > of design? Implementation? But again, I think we are arguing terminology, not substance. My practice has been to use the term "design" in way that is apparently more abstract than those who have read and objected to my posts. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Alan Lovejoy @ 1996-11-13 0:00 ` Ell 1996-11-13 0:00 ` Nick Thurn 1996-11-14 0:00 ` Bill Gooch 2 siblings, 0 replies; 79+ messages in thread From: Ell @ 1996-11-13 0:00 UTC (permalink / raw) Alan Lovejoy (alovejoy@concentric.net) wrote: : Bill Gooch wrote: : > I'd like to hear more about how you think design can be done : > independent of language, and what such a "design" would look : > like. I can see that the most abstract levels of design can : > be language-independent, but refinement from this level is an : > essential aspect (IMO) of doing good design. Such refinement : > necessarily goes down through layers including language, frame- : > work, database,... dependencies; in fact, it takes into account : > *all* requirements, including hardware constraints. : Oh dear. I think what we have here is merely :-) a terminology problem. : : There is a difference between design methodology, the process of producing a design, : and the result of that process. Unfortunately, the term "design" (without modifiers) : can be applied to any or all of these things. As I observe, most in the software engineering area use the term "design" similar to what Gooch is saying above. *Implementation* of analysis. Otherwise there is a muddle. Elliott ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Ell @ 1996-11-13 0:00 ` Nick Thurn 1996-11-14 0:00 ` Bill Gooch 2 siblings, 0 replies; 79+ messages in thread From: Nick Thurn @ 1996-11-13 0:00 UTC (permalink / raw) Alan Lovejoy (alovejoy@concentric.net) wrote: [...] > > Design notations have a different purpose: to communicate what the design of the > program is to human readers--often ommitting details that should be specified > if the program actually needs to be executed by a computer. However, those > details should be **optionally** specifiable, so that those cases in which > such details are important at the "design level" can be dealt with there. > > My thesis is that a design **methodology** should be able to handle designing > a program regardless of language, although it will certainly need to take the > differences between langauges into account. If I have to use a completely > different methodology for each part of the system that is implemented in a > different language, something is wrong. > Alan, I think you are refering to what I would call domain modeling or analysis. > Similarly, the design notation should be flexible enough to handle any and > all implementation languages. One may use different capabilities of the > notation and/or and specify different designs due to the intended target > language. But if the notation becomes completely worthless in the face of > an implementation language such as Self, perhaps there is something wrong with > the notation (and/or its underlying object metamodel) at a fundamental level. > Big ask! Personally I prefer something that fits *my* needs not tries to be all things to all people. > > Agreed. I am reacting to all the times I've seen people start their design process > by drawing class hierarchies. > This may or may not be appropriate, horses for courses! [...] > Yep. The methodologists have some work to do. I think patterns have started the right > things happening in this regard. > > Implementation? But again, I think we are arguing terminology, not substance. > > My practice has been to use the term "design" in way that is apparently more abstract > than those who have read and objected to my posts. > I fear you are confusing analysis with design. I agree analysis should be largely language independent (I guess this means you don't do any if you're creating a C++ library :-). Design should not *be* implementation but it can not be done without regard to the limitations and idiosyncrasies (?) of the implementation language. cheers Nick (my opinions only) > -- > Alan L. Lovejoy |==============================================| > Smalltalk Consultant | Beware of Geeks bearing GIFs! | > alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Ell 1996-11-13 0:00 ` Nick Thurn @ 1996-11-14 0:00 ` Bill Gooch 1996-11-19 0:00 ` Tim Ottinger 2 siblings, 1 reply; 79+ messages in thread From: Bill Gooch @ 1996-11-14 0:00 UTC (permalink / raw) Alan Lovejoy wrote: > > Bill Gooch wrote: > > > > I'd like to hear more about how you think design can be done > > independent of language, and what such a "design" would look > > like.... I have a question: what do you call a > > program specification, not involving code, which does take > > these issues into account? > .... > Please believe that I am well aware of the fact that one absolutely must take the > idiosyncracies of the implementation technology (such as the programming language) > into account in desgining and coding a program. I'm sorry that so many people seem > to think I have suggested otherwise!... Well, I'm sorry that I apparently misinterpreted what you wrote. I do believe that you know these things, and perhaps what we are dealing with is a reflection of the fact that "design" is a very broad term. I think of software designs in layers, from the most abstract (related directly to the domain model) to concrete (the closest to the implementation, and most language-specific). This covers such a broad range that the relationship between layers at each end is often lost, simply because there are so many refining transformations in between, and methods don't support specifying those refinements very clearly or completely. (This can change.) > Any "program specification" that could be used to actually execute a program, > or generate an executable program, is by definition a program text, and the notation > in which it is written is in effect a programming language.... "In effect," maybe it is - but consider that many CASE tools can generate executable, and by itself entirely useless, code from diagrams. Does this qualify the diagram notation as a "programming language?" Maybe some notations could be, but mostly I think they are not, because there are too many details they can't deal with effectively, if at all. In any case, I didn't say that the specification I referred to was necessarily executable, nor usable to generate a program. > My thesis is that a design **methodology** should be able to handle designing > a program regardless of language, although it will certainly need to take the > differences between langauges into account. If I have to use a completely > different methodology for each part of the system that is implemented in a > different language, something is wrong. More or less, I agree. But in a practical sense, it isn't so much the *methods* that are limited (with some exceptions), it is the *notations* which don't span languages very well. The need to be able to specify language-dependent aspects of design when appropriate argues for multi-lingual, rather than language independent, notation. IOW, perhaps you flip a language switch when you're ready to deal with the more concrete design layers. Mapping designs between languages is even more problematic. > Similarly, the design notation should be flexible enough to handle any and > all implementation languages. One may use different capabilities of the > notation and/or and specify different designs due to the intended target > language. OK, now it seems that we're on the same track... > But if the notation becomes completely worthless in the face of > an implementation language such as Self, perhaps there is something wrong with > the notation (and/or its underlying object metamodel) at a fundamental level. Perhaps; I'm not sure. I think the notations probably don't have more trouble with Self than some other languages, but the inter- pretation of the models (the meta-model) is very different. Sure, the designed structures are likely to be different also. The question in my mind is: is a prototype-based language really the same kind of animal as a class-based language? There must be limits on the domain our methods and notations are intended for, so where do we draw the line? > I am reacting to all the times I've seen people start their design process > by drawing class hierarchies.... I don't have too much trouble with that, as long as they've previously built some reasonable domain models which aren't concerned with implementation or class structure. It's a question of the starting point; if you understand the problem well enough, then solutions (including some of the class structure) may be fairly apparent. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-14 0:00 ` Bill Gooch @ 1996-11-19 0:00 ` Tim Ottinger 0 siblings, 0 replies; 79+ messages in thread From: Tim Ottinger @ 1996-11-19 0:00 UTC (permalink / raw) Bill Gooch wrote: > Well, I'm sorry that I apparently misinterpreted what you wrote. > I do believe that you know these things, and perhaps what we are > dealing with is a reflection of the fact that "design" is a very > broad term. I think of software designs in layers, from the most > abstract (related directly to the domain model) to concrete (the > closest to the implementation, and most language-specific). This > covers such a broad range that the relationship between layers at > each end is often lost, simply because there are so many refining > transformations in between, and methods don't support specifying > those refinements very clearly or completely. (This can change.) > In any case, I didn't say that the specification I referred to > was necessarily executable, nor usable to generate a program. > [Alan Lovejoy wrote] > > My thesis is that a design **methodology** should be able to handle designing > > a program regardless of language, although it will certainly need to take the > > differences between langauges into account. If I have to use a completely > > different methodology for each part of the system that is implemented in a > > different language, something is wrong. > > More or less, I agree. But in a practical sense, it isn't so > much the *methods* that are limited (with some exceptions), it > is the *notations* which don't span languages very well. The > need to be able to specify language-dependent aspects of design > when appropriate argues for multi-lingual, rather than language > independent, notation. IOW, perhaps you flip a language switch > when you're ready to deal with the more concrete design layers. > > Mapping designs between languages is even more problematic. If there's one thing that we should learn from Mr. Booch and the many others who've been with OO through the good, the bad, and the ugly projects, it's that we have to watch out for "the big project". The Big Project is the "clean-break from the past", "do it all", "no limits", type of project which typically fails. Typically, people believe that they can build a complex system, which works, from scratch. An end-all notation is a great idea, and if you can make a notation or method which is independent of all technologies but which uses every technology well, then I would love to see it. We have to face the "fact" that a design notation has to map cleanly into the engineering realm. If I could borrow the flimsy and much- touted "other fields" analogy, what good would a circuit diagramming notation do if it didn't map cleanly into manufacturing? In fact, if we don't consider manufacturing in our notation, we're probably making a big mistake. For instance, it's sometimes a mistake to use OO notation for a SA/SD software project, likewise it's frequently troublesome to use SA/SD design, and expect to manufacture an OO system easily from it. [ SOAP BOX WARNING: BEGINS NOW ] As much as we like to glorify our jobs, we analyse in order to design well, and design well so that we can build well, and we build well so that the software will run well. If my design is "independent of tech" that might be nice unto itself, but it pushes problems downstream. A lot of the analysis/design/code/test/release/revisit talks I hear are legitimate. You clearly should know what you want before you start, etc. Ad-hoc hacking can lead to some pretty ill-conceived systems, which act ill-conceived. Nobody wants that. On the other hand, a lot of talk seems to be trying to maintain a status quo for the "SE" career path (tester->coder->designer->analyst->manager). Let's face it, our separation of concerns is often separation of careers, and it exists to give us a promotion path with requisite pay raises and status. We're in an incremental world now. We iterate (okay, not all of us, SM). If we can't maintain our business organization and separation of roles and pay ranges in this world, is that a problem with the methods or the status quo? It's a hard call. It's bigger than this list, and can't be corrected by developers (though we can push for this). When we change our manufacturing methods, we must change the front-line skills, the tools (notation/language) and the organization of labor. We can surf, or we can get washed away. [SOAPBOX WARNING OVER] But the "ultimate" methodology should match the way we generate software. It should not be independent of it. It should not limit our abilities, and some tradeoff must be made from time to time. But our early analysis must eventually map onto hardware, or it wasn't a very useful part of the software development process (though it can be good for professional development ;-) ) -- Tim +------------------------------------------------------------------+ | Tell me again, *why* must we publish estimates before we | | gather requirements? | +------------------------------------------------------------------+ | Tim Ottinger, Sr Tech tottinge@csci.csc.com | | CSC Communications Industry Services 217-351-8508x2420 | | TRIS Division -- Cellular Billing and Support Fax 217-351-2640 | +------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Bill Gooch 1996-11-12 0:00 ` Alan Lovejoy @ 1996-11-12 0:00 ` Jan Steinman 1996-11-12 0:00 ` Alan Lovejoy 1 sibling, 1 reply; 79+ messages in thread From: Jan Steinman @ 1996-11-12 0:00 UTC (permalink / raw) In article <32875B03.3729@iconcomp.com>, bill@iconcomp.com wrote: > Alan Lovejoy wrote: > > > > I think you've hit the nail on the head. I do distinguish between "design" and "coding". > > > > To me, the "design" of a program is a language-independent abstraction. Implementation > > inheritance is a coding issue.... > > I'd like to hear more about how you think design can be done > independent of language, and what such a "design" would look > like... The biggest disasters I've seen were designed with the philosophy that the implementation vehicle was unimportant. (In fact, the January issue of The Smalltalk Report is rumored to have a column on this very topic... :-) Conversely, the most successful projects I've seen were ones where the designers were well-versed in the implementation language. I think it is necessary for the designer to understand -- if not excel in -- the implementation vehicle. "Real" architects study civil engineering as well as architecture, or else they might design a skyscraper made of wood and paper. > I think it is impossible to progress very far from a domain > model into design without considering target language... Here here! > > * When should delegation be used instead of inheritance? Hmmm... how do you accomplish *that* in a language independent manner? Turn it over to a C++ coder, they might consider multiple inheritance, turn it over to a Smalltalker, they're going to think of general delegation. Programming is still a combination of art, craft, and science. Most methodologies I've encountered try to force programming entirely into the "science" realm. I think that is a mistake. : To foil junk mailers, REPLY won't work. Please paste address in. : Jan Steinman <mailto:Jan@Bytesmiths.com> : Bytesmiths <http://www.bytesmiths.com> : 2002 Parkside Court, West Linn, OR 97068 USA, +1 503 657 7703 : Java: the elegant simplicity of C++ and the blazing speed of Smalltalk. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Jan Steinman @ 1996-11-12 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Nick Thurn 0 siblings, 1 reply; 79+ messages in thread From: Alan Lovejoy @ 1996-11-12 0:00 UTC (permalink / raw) Jan Steinman wrote: > > In article <32875B03.3729@iconcomp.com>, bill@iconcomp.com wrote: > > > Alan Lovejoy wrote: > > > > > > I think you've hit the nail on the head. I do distinguish between > "design" and "coding". > > > > > > To me, the "design" of a program is a language-independent > abstraction. Implementation > > > inheritance is a coding issue.... > > > > I'd like to hear more about how you think design can be done > > independent of language, and what such a "design" would look > > like... > > The biggest disasters I've seen were designed with the philosophy that the > implementation vehicle was unimportant. (In fact, the January issue of The > Smalltalk Report is rumored to have a column on this very topic... :-) > Conversely, the most successful projects I've seen were ones where the > designers were well-versed in the implementation language. > > I think it is necessary for the designer to understand -- if not excel in > -- the implementation vehicle. "Real" architects study civil engineering > as well as architecture, or else they might design a skyscraper made of > wood and paper. 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! For a design to be "language independent", it is sufficient that it be implementable in any language. Whether it would be the optimal implementation in each language is a different (although admittedly important) issue. So I actually agree with your thesis. > > I think it is impossible to progress very far from a domain > > model into design without considering target language... > > Here here! Well, not **impossible**, just ill-advised. > > > * When should delegation be used instead of inheritance? > > Hmmm... how do you accomplish *that* in a language independent manner? Again, I did not suggest that you should. > Turn it over to a C++ coder, they might consider multiple inheritance, > turn it over to a Smalltalker, they're going to think of general > delegation. Of course. But the methodology should deal with this issue, and give the right answer for each language--or perhaps suggest that the wrong implementation language is being used for the problem at hand. > Programming is still a combination of art, craft, and science. Most > methodologies I've encountered try to force programming entirely into the > "science" realm. I think that is a mistake. Yes, but the goal of scientific rigor is a good one. Recognizing that we aren't there yet can only be healthy, whether one is a methodology user or a methodology researcher. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Alan Lovejoy @ 1996-11-13 0:00 ` Nick Thurn 1996-11-13 0:00 ` Alan Lovejoy 0 siblings, 1 reply; 79+ messages in thread From: Nick Thurn @ 1996-11-13 0:00 UTC (permalink / raw) 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? cheers Nick (my opinions only) ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-13 0:00 ` Nick Thurn @ 1996-11-13 0:00 ` Alan Lovejoy 1996-11-14 0:00 ` Nick Thurn 0 siblings, 1 reply; 79+ messages in thread From: Alan Lovejoy @ 1996-11-13 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-13 0:00 ` Alan Lovejoy @ 1996-11-14 0:00 ` Nick Thurn 0 siblings, 0 replies; 79+ messages in thread From: Nick Thurn @ 1996-11-14 0:00 UTC (permalink / raw) Alan Lovejoy (alovejoy@concentric.net) wrote: > Nick Thurn wrote: > > > > 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). > Alan, I see what you mean, however I still don't agree. In my experience the dynamic model is several things: - sanity check on static model - discoverer of missing abstractions - discoverer of patterns of interaction to be further encapsulated The static and dynamic model interact in a feedback loop so precedence is not clear ie static first vs dynamic first. IMHO you must start with a static model of your domain prior to embarking on the dynamic model. Sure this model may be incomplete or prove inappropriate but it is the seed from which an implementable system should be grown (IMO). read on.. > 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, > Again I disagree. Standard objects *are* part of your design just because you *use* vs. *implement* doesn't reduce their importance. In fact the greatest benefits come when programmers -stop- -writing- -code- and -start- -using- -code-. > but you do need to know how to interface to them, and > decide what roles (if any) they will play in your system. > I agree with this. The timing is still *after* you have a static analysis or domain model and a set of requirements stating what your users want this system to do. How can you even think about object roles until you know which objects you have? and what your program should do? > 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. > [...snipped MVC discription...] > > 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) messages that it will be expected to respond to > (which might well be a subset of all the messages it could respond to) > 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). > [...snipped MVC discription...] > > From this it should be clear that roles are not classes. > No they are perhaps patterns and certainly design artifacts. They may be implemented as classes if appropriate, and could be abstract base classes or cooperating generics. Or whatever your language supports. > 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? > You are forgetting that at this point you know stuff that makes the role relevant eg that your app is GUI based vs embedded vs commandline vs ... How did you get to know this stuff? You are talking about plumbing which IMO should be put into librarys if possible and reused. Yes plumbing is a design issue, yes object interaction roles are relevant but plumbing comes AFTER your static model, AFTER you know what you are doing and why you are doing it. Object roles are *discovered* during dynamic modeling, (this can mean "force fit" :) they are not ends in themselves. cheers Nick (my opinions only) > -- > Alan L. Lovejoy |==============================================| > Smalltalk Consultant | Beware of Geeks bearing GIFs! | > alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-08 0:00 ` Paul_Gover 1996-11-08 0:00 ` Ell 1996-11-08 0:00 ` Alan Lovejoy @ 1996-11-10 0:00 ` vlad 2 siblings, 0 replies; 79+ messages in thread From: vlad @ 1996-11-10 0:00 UTC (permalink / raw) Paul_Gover@uk.ibm.com wrote: >However, I disagree when it comes to design; this might be a >difference in our view of where to separate design from coding. My view is that design >includes implementation detail such as inheritance. I most certainly consider that >"OO development methods" should address it. Design of what? Design of a class or design of a system. In the design of a system you don't need to bother with inheritance. What about objects, that are not defined by classes or what about objects, which can change it's class at run-time. In the design of a system the most important thing is a object interface and how it coopeates with other objects. If you design a class, then you will find inheritance usefull. Of course the "inheritance" can be replace by delegating and then we even don't need classes. So inheritance is a implementation detail, that is not important in design of your application. It is my view and I may be wrong. >I think from your statement about converting to equivalent programs indicates you >consider implementation to be outside the scope of the design (since you describe two >different implementations for the same design); in that case, do you think that >questions of inheritance and so forth are not part of the development method? >I think this is dangerous; in your example, the coverted program has large amounts of >duplicated code, so making changes is harder because the programmer has to find all >occurrences of the duplicated code, and we have lost one of the benefits of OO. >Paul Gover >IBM Warwick Development Group >Mumbling for myself, not IBM Vlastimil Adamovsky ** C++ and Smalltalk consultant ** * http://www.stepweb.com * ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Alan Lovejoy 1996-11-07 0:00 ` Piercarlo Grandi 1996-11-08 0:00 ` Paul_Gover @ 1996-11-12 0:00 ` Robert C. Martin 1996-11-12 0:00 ` Alan Lovejoy 2 siblings, 1 reply; 79+ messages in thread From: Robert C. Martin @ 1996-11-12 0:00 UTC (permalink / raw) In article <328109CD.6685@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > The architecture and design of a program is a function of what **objects** it contains and > how they interact. I disagree. The architecture of a program is a function of the way it manages to decouple the source code while allowing the interactions to remain unaffected. This is true irrespective of language. It is as true in Smalltalk as it is in Java or C++. Whenever one neglects to manage the static relationships between source code units, one winds up in trouble. > Class inheritance is an abstraction mechanism for code sharing. It has nothing much to do > with architecture or design of a program. Proof: any program using class inheritance can > easily be converted into a completely equivalent program where all the leaf classes are root > classes: This is truer for Smalltalk than it is for Java or C++. But it isn't really even true in Smalltalk. Consider, that the way your two systems are affected by a change in specifications is very different. In the flattened model, the classes can, and must, be changed independently. But in the hierarchical model a change in the middle of a hierarchy affects all those classes that depend upon it. Thus, the design of the heirarchy must take into consideration the most likely changes that will occur; and should strive to minimize the effort involved in making those changes. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Robert C. Martin @ 1996-11-12 0:00 ` Alan Lovejoy 1996-11-14 0:00 ` David N. Smith 1996-11-20 0:00 ` Robert C. Martin 0 siblings, 2 replies; 79+ messages in thread From: Alan Lovejoy @ 1996-11-12 0:00 UTC (permalink / raw) Robert C. Martin wrote: > > In article <328109CD.6685@concentric.net>, Alan Lovejoy > <alovejoy@concentric.net> wrote: > > > The architecture and design of a program is a function of what > **objects** it contains and > > how they interact. > > I disagree. The architecture of a program is a function of the way > it manages to decouple the source code while allowing the interactions > to remain unaffected. > > This is true irrespective of language. It is as true in Smalltalk as > it is in Java or C++. I have to admit that I don't really understand what you mean. Perhaps you could clarify? > > Class inheritance is an abstraction mechanism for code sharing. It has > nothing much to do > > with architecture or design of a program. Proof: any program using > class inheritance can > > easily be converted into a completely equivalent program where all the > leaf classes are root > > classes: > > This is truer for Smalltalk than it is for Java or C++. But it isn't really > even true in Smalltalk. Consider, that the way your two systems are affected > by a change in specifications is very different. In the flattened model, > the classes can, and must, be changed independently. > But in the hierarchical model a change in the middle of a hierarchy affects > all those classes that depend upon it. Thus, the design of the heirarchy > must take into consideration the most likely changes that will occur; and > should strive to minimize the effort involved in making those changes. The design/architecture of the **source code** of a program (what you called the "static model" in another post, assuming I understood you) is different than the desgign/architecture of the program as it exists at execution time (what you called the "dynamic model"). As I have used the term "design" in earlier posts, it refers to what you have called the "dynamic model" (assuming I have correctly understood you). My thesis is not that the "static model" is unimportant, but rather that one needs to know what dynamic model one wants to achieve before one can optimally derive a static model. The dynamic model is the heart of the design, because it is where the real work gets done, and because the purpose of the static model is the specification of the dynamic model. You can't implement a good static model that specifies a dynamic model without having a good idea of what dynamic model you intend to specify! That being said, I completely agree that a "flat" class library with no inheritance is not a good idea. I mentioned it solely to highlight the difference between the static and dyanmic models. Finally, this thread started with the claim that there wasn't enough focus on class inheritance in the static model in typical design methodologies. I and some others objected to this, because in our experience typical methodologies don't have sufficient support for handling the dynamic model, and overemphasize static modelling issues such as class inheritance. In view of the OO languages such as Self that don't even have classes, one has to question how central class inheritance (as opposed to type inheritance) really is to even static modelling (not that getting inheritance right is easy, or that getting it wrong is inconsequential). The earlier posts should be interpreted in that context. Bottom line: "Design" involves much more than class hierarchies. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Alan Lovejoy @ 1996-11-14 0:00 ` David N. Smith 1996-11-14 0:00 ` Bill Gooch 1996-11-20 0:00 ` Robert C. Martin 1 sibling, 1 reply; 79+ messages in thread From: David N. Smith @ 1996-11-14 0:00 UTC (permalink / raw) In article <32891BA4.4AA5@concentric.net> Alan Lovejoy, alovejoy@concentric.net writes: >In view of the OO languages such as Self that don't even >have classes, >one has to question how central class inheritance (as opposed to type inheritance) really >is to even static modelling (not that getting inheritance right is easy, or that getting >it wrong is inconsequential). Alan: One can think of SELF as a language in which all objects are classes since any object can serve the function of a prototype for a family of objects differing only in their 'data'. Inheritence in SELF is not type inheritence; it is much more purely implementation inheritence than even Smalltalk. I do agree that classes are often thought of as necessary an basic in all OOP languages and the definition of OOP often includes the concept of class. That's basically wrong. Classes are necessary and basic only in those restricted 'OOP' languages that use type inheritence. Dave _____________________________________________ David N. Smith IBM T J Watson Research Center, Hawthorne, NY Mailto: dnsmith@watson.ibm.com Home Page: http://www.dnsmith.com/ _____________________________________________ Any opinions or recommendations are those of the author and not of his employer. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-14 0:00 ` David N. Smith @ 1996-11-14 0:00 ` Bill Gooch 0 siblings, 0 replies; 79+ messages in thread From: Bill Gooch @ 1996-11-14 0:00 UTC (permalink / raw) David N. Smith wrote: > .... > I do agree that classes are often thought of as necessary an basic in all > OOP languages and the definition of OOP often includes the concept of > class. That's basically wrong. Agreed. > Classes are necessary and basic only in those restricted 'OOP' languages > that use type inheritence. Type inheritance is independent of classes; indeed, it is not at all restricted to OO. I'd say that classes are necessary and basic only in those restricted "OOP" languages in which classes are necessary and basic. None of the useful things about OO depend on a class/instance stratification. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Alan Lovejoy 1996-11-14 0:00 ` David N. Smith @ 1996-11-20 0:00 ` Robert C. Martin 1996-11-20 0:00 ` Michael Malak ` (2 more replies) 1 sibling, 3 replies; 79+ messages in thread From: Robert C. Martin @ 1996-11-20 0:00 UTC (permalink / raw) In article <32891BA4.4AA5@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > Robert C. Martin wrote: > > > > In article <328109CD.6685@concentric.net>, Alan Lovejoy > > <alovejoy@concentric.net> wrote: > > > > > The architecture and design of a program is a function of what > > **objects** it contains and > > > how they interact. > > > > I disagree. The architecture of a program is a function of the way > > it manages to decouple the source code while allowing the interactions > > to remain unaffected. > > > > This is true irrespective of language. It is as true in Smalltalk as > > it is in Java or C++. > > I have to admit that I don't really understand what you mean. Perhaps you could > clarify? Sure. Imagine a program that trasmits files between computers using modems. That program could deal with lots of different kinds of modems in several different ways. It could use a switch statement every time it needed to interact with a modem, choosing the correct modem each time and executing the right code. Or it could create an abstract Modem class and then create derivative for each type of modem. In the first example, adding a new modem means ripping through all the code and finding every place where there is a switch statement and adding the new modem to it. In the second example, adding a new modem is a easy as writing a new derivative class of Modem. On the other hand, if we need to add a new function to all the modems, then in the first example, all we have to do is add a switch statement, but in the second example, we must modify the abstract modem class and all its derivatives. This is an architectural choice; and it is based upon which kind of change is more likely. If it is more likely that new functions will be added to existing modems, then the switch statement is probably the better choice. If it is more likely that new kinds of modems will be added, then the class structure is probably better. The point is that the interactions between the program and the modems remain identical regardless of which architecture you choose. The architecture is strategy for decoupling the source code so that changes are easily made. > As I have used the term "design" in earlier posts, it refers to what you have called > the "dynamic model" (assuming I have correctly understood you). My thesis is not that > the "static model" is unimportant, but rather that one needs to know what dynamic model > one wants to achieve before one can optimally derive a static model. The dynamic model > is the heart of the design, because it is where the real work gets done, and because > the purpose of the static model is the specification of the dynamic model. You can't > implement a good static model that specifies a dynamic model without having a good idea > of what dynamic model you intend to specify! Damn straight! Static models are meaningless without dynamic models to justify them. By the same token, dynamic models are fantasies without static models to support them. Both are important. Neither can stand alone. One cannot create a static model without a decent dynamic model. But by the same token, one cannot create a realistic dynamic model without it being constrained by a good static model. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-20 0:00 ` Robert C. Martin @ 1996-11-20 0:00 ` Michael Malak 1996-11-20 0:00 ` Robert Dewar 1996-11-20 0:00 ` Robert Dewar 1996-11-26 0:00 ` Tucker Taft 2 siblings, 1 reply; 79+ messages in thread From: Michael Malak @ 1996-11-20 0:00 UTC (permalink / raw) In article <rmartin-2011960223130001@vh1-036.wwa.com>, Robert C. Martin <rmartin@oma.com> wrote: > >Sure. Imagine a program that trasmits files between computers using >modems. That program could deal with lots of different kinds of modems in >several different ways. It could use a switch statement every time it needed >to interact with a modem, choosing the correct modem each time and executing >the right code. Or it could create an abstract Modem class and then create >derivative for each type of modem. > > [snip] > >This is an architectural choice; and it is based upon which kind of change >is more likely. If it is more likely that new functions will be added to >existing modems, then the switch statement is probably the better choice. >If it is more likely that new kinds of modems will be added, then the class >structure is probably better. THANK YOU! for confirming my conjecture. I posted this idea a few weeks ago on comp.lang.c++.moderated to see if it was valid, and I got blasted. Response 1: Use templates My unspoken response: I still have to write a bunch of functions for every new method I wish to implement Response 2: Arthur Reil's book says you're in danger of creating a "God" class My unspoken response: none, since I don't have the book Response 3: This is the Visitor pattern; buy the Gamma book My unspoken response: Yes, I have the Gamma book, and yes, I was familiar with the Visitor pattern, but the Visitor pattern looked too complicated to achieve what I wanted. As "bad" as "switch/case" is, it appears to minimize the complexity in this situation. I was just a meek C++ student back then, so I didn't post any responses. I put those bad old thoughts of "switch/case" out of my mind. If you are interested in seeing the thread, search for this message ID in DejaNews: <54titl$imt@netlab.cs.rpi.edu> -- Michael Malak Home: malak@access.digex.net Washington, DC Work: malak@notes.sonix.com ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-20 0:00 ` Michael Malak @ 1996-11-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 79+ messages in thread From: Robert Dewar @ 1996-11-20 0:00 UTC (permalink / raw) Michael says " My unspoken response: Yes, I have the Gamma book, and yes, I was familiar with the Visitor pattern, but the Visitor pattern looked too complicated to achieve what I wanted. As "bad" as "switch/case" is, it appears to minimize the complexity in this situation." One thing you will learn rapidly that there are a lot of people in this field who are much more interested in fiddling with the latest gizmos than in writing clearly and minimizing complexity :-) ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-20 0:00 ` Robert C. Martin 1996-11-20 0:00 ` Michael Malak @ 1996-11-20 0:00 ` Robert Dewar 1996-11-26 0:00 ` Tucker Taft 2 siblings, 0 replies; 79+ messages in thread From: Robert Dewar @ 1996-11-20 0:00 UTC (permalink / raw) Robert Martin says "On the other hand, if we need to add a new function to all the modems, then in the first example, all we have to do is add a switch statement, but in the second example, we must modify the abstract modem class and all its derivatives. This is an architectural choice; and it is based upon which kind of change is more likely. If it is more likely that new functions will be added to existing modems, then the switch statement is probably the better choice. If it is more likely that new kinds of modems will be added, then the class structure is probably better. " Yes indeed, this is an important fundamental principle that does not seem to be widely enough understood. It is useful to think of a matrix with operations on the columns and types on the rows, then the issue of whether to organize a program vertically or horizaonally with respect to this particular subdomain is made on the basis of whether you expect to add to rows or columns. It is also appropriate to consider domains of expertise, does a typical expertise extend over columns or rows of this matrix? If there is a clear answer to this question, which is sometimes the case, then that may be another consideration in deciding whether to organize horizontally or vertically. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-20 0:00 ` Robert C. Martin 1996-11-20 0:00 ` Michael Malak 1996-11-20 0:00 ` Robert Dewar @ 1996-11-26 0:00 ` Tucker Taft 1996-12-03 0:00 ` Robert C. Martin 2 siblings, 1 reply; 79+ messages in thread From: Tucker Taft @ 1996-11-26 0:00 UTC (permalink / raw) Robert C. Martin (rmartin@oma.com) wrote: : ... Imagine a program that trasmits files between computers using : modems. That program could deal with lots of different kinds of modems in : several different ways. It could use a switch statement every time it needed : to interact with a modem, choosing the correct modem each time and executing : the right code. Or it could create an abstract Modem class and then create : derivative for each type of modem. : In the first example, adding a new modem means ripping through all the code : and finding every place where there is a switch statement and adding the : new modem to it. : In the second example, adding a new modem is a easy as writing a new derivative : class of Modem. : On the other hand, if we need to add a new function to all the modems, then : in the first example, all we have to do is add a switch statement, but in : the second example, we must modify the abstract modem class and all its : derivatives. : This is an architectural choice; and it is based upon which kind of change : is more likely. If it is more likely that new functions will be added to : existing modems, then the switch statement is probably the better choice. : If it is more likely that new kinds of modems will be added, then the class : structure is probably better. This is certainly a good point, but I think that the class structure still has certain advantages over the "switch" structure even when adding new "functions" is somewhat more common than adding new modem variants. In the "switch" world (in which I have spent many pleasant hours ;-), one tends to presume that almost every new function requires its own personal switch statement. In the "class" world, when adding a new operation, one has the option of implementing it in terms of some preexisting more primitive operation, rather than creating a new operation for every modem variant. Although this is difficult to prove, my sense is that by being forced by the "class" structure to express the differences between type variants by a set of primitive operations, one is more likely to find that many new "interesting" operations are implementable in terms of the existing operations. In the "switch" structure, you often don't ever get around to defining the "primitive" operations, but instead just keep defining miscellaneous operations, each with their own switch statement, without any great thought to creating a minimal but complete set of "primitive" operations. The net effect is that when you want to change some aspect of the implementation, or fix a bug, there is much more cut & paste that has happened in the "switch" world, and hence much more of a maintenance problem. To reiterate, when it comes to writing a new operation, with the "switch" structure, you will often have to write a new switch statement, probably partially copying and then editing some existing switch statement. With the "class" structure, it is more likely that you will only have to write a small amount code, containing calls on preexisting operations. : Robert C. Martin | Design Consulting | Training courses offered: : Object Mentor | rmartin@oma.com | Object Oriented Design : 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ : Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-26 0:00 ` Tucker Taft @ 1996-12-03 0:00 ` Robert C. Martin 1996-12-08 0:00 ` Tucker Taft 0 siblings, 1 reply; 79+ messages in thread From: Robert C. Martin @ 1996-12-03 0:00 UTC (permalink / raw) In article <E1Hpuz.5w2.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com (Tucker Taft) wrote: > Robert C. Martin (rmartin@oma.com) wrote: > > : This is an architectural choice; and it is based upon which kind of change > : is more likely. If it is more likely that new functions will be added to > : existing modems, then the switch statement is probably the better choice. > : If it is more likely that new kinds of modems will be added, then the class > : structure is probably better. > > This is certainly a good point, but I think that the class structure > still has certain advantages over the "switch" structure even when adding > new "functions" is somewhat more common than adding new modem variants. Building class structures is also my preference; even when new functions are added with relative frequency. I will use 'Visitor' or 'Decorator' to add those functions. However, in the extreme case, when adding new new functions will continue to be the primary means of modifying the software, the switch statement route is probably the better choice. > > In the "switch" world (in which I have spent many pleasant hours ;-), > one tends to presume that almost every new function requires its > own personal switch statement. In the "class" world, when adding > a new operation, one has the option of implementing it in terms of > some preexisting more primitive operation, rather than creating > a new operation for every modem variant. This is a matter of style. There is no reason why primitives cannot be created when using switch statements. That some people tend not to do that is unfortunate, but no different from the fact that some people tend to build classes with no behaviors other than accessors and mutators. I don't want to seem that I am advocating a programming structure based upon procedural principles. Generally I do not support such structures. I ususally try to arrange the structure of the program such that the 'types' vary more frequently than the functions. However, there are times when a procedural architecture is the right choice. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-12-03 0:00 ` Robert C. Martin @ 1996-12-08 0:00 ` Tucker Taft 0 siblings, 0 replies; 79+ messages in thread From: Tucker Taft @ 1996-12-08 0:00 UTC (permalink / raw) Robert C. Martin (rmartin@oma.com) wrote: : ...There is no reason why primitives cannot : be created when using switch statements. I certainly agree. What I was trying to convey was the "typical" behavior, not the "possible" behavior. Empirically, you take the same programmers, expose them to the same problem, and my anecdotal evidence indicates that they tend to create more switch statements than would be necessary if they focused on creating the right "primitives," resulting in even more information "spreading" and de-modularization. : Robert C. Martin | Design Consulting | Training courses offered: : Object Mentor | rmartin@oma.com | Object Oriented Design : 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ : Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Paul_Gover 1996-11-06 0:00 ` Alan Lovejoy @ 1996-11-06 0:00 ` Jan Steinman 1996-11-07 0:00 ` Paul_Gover 1996-11-12 0:00 ` Robert C. Martin 1996-11-06 0:00 ` Snowball 2 siblings, 2 replies; 79+ messages in thread From: Jan Steinman @ 1996-11-06 0:00 UTC (permalink / raw) In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote: > In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes: > > ... > >Let me have your opinions about followings: > > > > 1. Is everything OK with existing oo development methods? > > If not, what are needed? and what stage should be enforced in the > > future,i.e,analysis or design,etc...? > > ... > > OK, here's my 2 cents: most OO development methods concentrate too much > on objects and too little on classes... Gee, in my 8 month experience with one well-known methodology, I felt just the opposite! It was impossible to model instance-specific behavior without pretending it was a class. Of course, we might just have been using it wrong... -- : To foil junk mailers, REPLY won't work. Please paste address in. : Jan Steinman <mailto:Jan@Bytesmiths.com> : Bytesmiths <http://www.bytesmiths.com> : 2002 Parkside Court, West Linn, OR 97068 USA, +1 503 657 7703 : On the Internet since it was the DARPANET. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Jan Steinman @ 1996-11-07 0:00 ` Paul_Gover 1996-11-12 0:00 ` Robert C. Martin 1 sibling, 0 replies; 79+ messages in thread From: Paul_Gover @ 1996-11-07 0:00 UTC (permalink / raw) In <Jan-0611961134040001@news.imagina.com>, Jan Steinman <No@Junk.Mail.Please> writes: >In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote: >> ... >> OK, here's my 2 cents: most OO development methods concentrate too much >> on objects and too little on classes... > >Gee, in my 8 month experience with one well-known methodology, I felt just >the opposite! > ... Jan, I did say "most", not "all"! So, which well-known methodology was it? I'd like to know more; either I don't know it, or I've misunderstood it. Paul Gover IBM Warwick Development Group Mumbling for myself, not IBM ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Jan Steinman 1996-11-07 0:00 ` Paul_Gover @ 1996-11-12 0:00 ` Robert C. Martin 1996-11-12 0:00 ` Snowball 1996-11-12 0:00 ` Alan Lovejoy 1 sibling, 2 replies; 79+ messages in thread From: Robert C. Martin @ 1996-11-12 0:00 UTC (permalink / raw) In article <Jan-0611961134040001@news.imagina.com>, Jan Steinman <No@Junk.Mail.Please> wrote: > In article <55pqr5$136a@grimsel.zurich.ibm.com>, Paul_Gover@uk.ibm.com wrote: > > > In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim > <kdo@kyebek3.kjist.ac.kr> writes: > > > ... > > >Let me have your opinions about followings: > > > > > > 1. Is everything OK with existing oo development methods? > > > If not, what are needed? and what stage should be enforced in the > > > future,i.e,analysis or design,etc...? > > > ... > > > > OK, here's my 2 cents: most OO development methods concentrate too much > > on objects and too little on classes... > > Gee, in my 8 month experience with one well-known methodology, I felt just > the opposite! It was impossible to model instance-specific behavior > without pretending it was a class. Of course, we might just have been > using it wrong... Objects execute inside computers. They take up memory space and CPU cycles. Classes are source code. They specify the objects and create a structure from which the objects are created. Any method that concentrates on one more than the other is doing a disservice to its inventors and its users. Rather we must focus on both. We generally use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify objects and the way that they interact. We use static models (i.e. class diagrams, package diagrams, etc) to specify classes and the static relationships between them. There is a mapping between the two kinds of models that must be maintained. Every relationship on a dynamic model; that is, ever pathway accross which a message is sent; must be supported by a static relationship in a static model. For example, if object A sends a message to object B, then there must be a class relationship somewhere that supports that. For example, the relationships might be an "aggregation" relationship between the class of A and the class of B. Or it might be an 'association' between one of the base classes of A and one of the base classes of B, etc. Static models, when developed in the absense of dynamic models, cannot be proven correct. They often have missing relationships and unnecesary relationship because the suite of relationships was untested by dymnamics. On the other hand when dynamic models are developed in the absense of static models, the structure of the software is seldom as flexible and maintainable as needed. Opportunities for reuse and robustness are lost. The code becomes interdependent and slowly rots. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Robert C. Martin @ 1996-11-12 0:00 ` Snowball 1996-11-15 0:00 ` Soren Skogstad Nielsen ` (2 more replies) 1996-11-12 0:00 ` Alan Lovejoy 1 sibling, 3 replies; 79+ messages in thread From: Snowball @ 1996-11-12 0:00 UTC (permalink / raw) Robert C. Martin wrote: > > Objects execute inside computers. They take up memory space and CPU cycles. > Classes are source code. They specify the objects and create a structure > from which the objects are created. > This is true for C++ and some other languages, however for Smalltalk Classes are objects which take up memory space (and sometimes CPU cycles). > Any method that concentrates on one more than the other is doing a disservice > to its inventors and its users. Rather we must focus on both. We generally > use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify > objects and the way that they interact. We use static models (i.e. class > diagrams, package diagrams, etc) to specify classes and the static > relationships between them. When we are talking about static and dynamic models, something bothers me. There are two types of complexities in any system. One is the static or structural (or sometimes I call it detail) complexity, the other one is dynamic complexity. To me some canonical forms of systems such as class hierarchy can be reasonably understood by static diagrams, however, it is not very intuitive to attempt to model dynamic behavior in static diagrams such as object or interaction diagrams. I can differentiate between structural complexity and dynamic complexity with an example: a car engine totally taken apart and lying on the floor with all parts visible, and even sorted out to parts, may create an atmosphere for us to develop a detailed understanding of each part but will not give us a clear idea of how it runs. An engine timing diagram can help us but the best way to understand how an engine works is to observe it "running" preferably with a power to control the motion of the time domain. This means that we can take the engine, replace one of the side walls of it with say a glass panel, and let it slowly run, even single step, so that we can follow the entire motion. Same analogy for a software system running would be to add a layered visual debugger and a reverse engineering tool to obtain and animate certain diagrams to observe how the behavior of the system changes in time. (It just happens that I am working on such a visual debugger for Smalltalk to be added to a tool I developed) > There is a mapping between the two kinds of models that must be maintained. > Every relationship on a dynamic model; that is, ever pathway accross which > a message is sent; must be supported by a static relationship in a static > model. I totally agree here. To me, they are essentially two different views of the same system. We are mostly defining the structure (time independent portion) of the system with the static models, and we shape the behavior of the system (or how a system behaves in time). Of course in many current languages there is a sharp distinction between these two views although in the real world this distinction is thinner than we think. For every system adaptation is a key to survival. Adaptation requires structural change. That means adding and/or deleting classes, or changing class structure or behavior in time. If this is the case the ?staticness? (is there such a word?) of the static diagrams will not hold any more. A correct class diagram for a system initially will not be the correct diagram after some classes are added or modified dynamically. Tansel Ersavas RASE Inc. mailTo:tansel@deep.net http://www.rase.com/ ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Snowball @ 1996-11-15 0:00 ` Soren Skogstad Nielsen 1996-11-28 0:00 ` Piercarlo Grandi 1996-11-28 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 79+ messages in thread From: Soren Skogstad Nielsen @ 1996-11-15 0:00 UTC (permalink / raw) Snowball wrote: (and many others) > > When we are talking about static and dynamic models, something bothers > me. There are > two types of complexities in any system. One is the static or structural > (or > sometimes I call it detail) complexity, the other one is dynamic > complexity. > To me some canonical forms of systems such as class hierarchy can be > reasonably understood > by static diagrams, however, it is not very intuitive to attempt to > model dynamic behavior > in static diagrams such as object or interaction diagrams. I can > differentiate between > structural complexity and dynamic complexity with an example: a car > engine totally taken > apart and lying on the floor with all parts visible, and even sorted out > to parts, may > create an atmosphere for us to develop a detailed understanding of each > part but will not > give us a clear idea of how it runs. An engine timing diagram can help > us but the best way > to understand how an engine works is to observe it "running" preferably > with a power to control > the motion of the time domain. This means that we can take the engine, > replace one of the side walls > of it with say a glass panel, and let it slowly run, even single step, > so that we can follow the > entire motion. Same analogy for a software system running would be to > add a layered visual > debugger and a reverse engineering tool to obtain and animate certain > diagrams to observe how the > behavior of the system changes in time. (It just happens that I am > working on such a visual > debugger for Smalltalk to be added to a tool I developed) > > > There is a mapping between the two kinds of models that must be maintained. > > Every relationship on a dynamic model; that is, ever pathway accross which > > a message is sent; must be supported by a static relationship in a static > > model. > I have some experience with a notation which keeps the dynamic and static properties in sync. Thereby you actually have ONE basic model from which you may derive a static AND a dynamic view. It is my experience that the interplay between the static and dynamic views enlightens my understanding of the structure of both and thereby of their same underlying model. To this notation is coupled a description of when to look for what in the two views. This guide telling when to decide on what (coupling, inheritance, methods, aggregation, etc) is in fact what I understand with the concept a methodology. It is described under the name of OoASE, a tool supporting the notation and the methodology is available too. You may send me a mail if interested in more information. - The world is just one big friendly surprise - Soren Skogstad Nielsen A-Informatik Bredgade 36 E Copenhagen Denmark email: soren.s.nielsen@ddf.dk ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Snowball 1996-11-15 0:00 ` Soren Skogstad Nielsen @ 1996-11-28 0:00 ` Piercarlo Grandi 1996-11-28 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-28 0:00 UTC (permalink / raw) >>> "snowballinfo" == Snowball <snowballinfo@rase.com> writes: snowballinfo> Robert C. Martin wrote: Robert> Objects execute inside computers. I would say that they can be stored; given that most OO systems are not actor based, the idea that objects "execute" lacks generality. Robert> They take up memory space and CPU cycles. Usually but not always... Robert> Classes are source code. Never; they are linguistic constructs, often represented as source code (but not always: for example in Smalltalk-80 there is no source code representation for classes, only printed, displayed and reified representations). There is an interesting section in Bjarne's Stroustrup's "The design and evolution of C++" on decoupling languages from their textual representation as source code as a possible evolution of C++, on page 207, with title "Beyond files and Syntax": " A C++ program contains a wealth of information that in a typical environment is available only to a compiler. I want that information at the programmer's fingertips. However, most people look at a C++ programs as a set of source files or as a string of characters. That is to confuse the representation with what is represented. A program is a collection of types, functions, statements, etc. To fit traditional programming environments, these concepts are represented as characters in files. Basing C++ implementations on character oriented tools has been a major impediment to progress. [ ... much more ... ]" I personally sympathize with the sentiment, but after many years I have become persuaded that there is no hope of easy interchange except in text files, and that easy interchange is of such paramount importance that it overrides even the desires to have the representation of a program in a more directly structural form than a stream of characters. Robert> They specify the objects and create a structure from which the Robert> objects are created. snowballinfo> This is true for C++ and some other languages, however for snowballinfo> Smalltalk Classes are objects which take up memory space snowballinfo> (and sometimes CPU cycles). Well, surely not in Smalltalk-80, which is arguably the ``classic'' Smalltalk that most people have heard of; which is the Smalltalk dialect you are thinking of in which classes are objects, instead of being merely represented by objects as in Smalltalk-80? Can it still be called ``Smalltalk''? After all that classes are not objects and that the two concepts are very distinct is one of the major design decisions of Smalltalk-80 (in the early versions of PARC Smalltalk the distinction was, arguably, not that sharp). ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Snowball 1996-11-15 0:00 ` Soren Skogstad Nielsen 1996-11-28 0:00 ` Piercarlo Grandi @ 1996-11-28 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-28 0:00 UTC (permalink / raw) >>> "snowballinfo" == Snowball <snowballinfo@rase.com> writes: snowballinfo> Robert C. Martin wrote: Robert> Objects execute inside computers. I would say that they can be stored; given that most OO systems are not actor based, the idea that objects "execute" lacks generality. Robert> They take up memory space and CPU cycles. Usually but not always... Robert> Classes are source code. Never; they are linguistic constructs, often represented as source code (but not always: for example in Smalltalk-80 there is no source code representation for classes, only printed, displayed and reified representations). There is an interesting section in Bjarne's Stroustrup's "The design and evolution of C++" on decoupling languages from their textual representation as source code as a possible evolution of C++, on page 207, with title "Beyond files and Syntax": " A C++ program contains a wealth of information that in a typical environment is available only to a compiler. I want that information at the programmer's fingertips. However, most people look at a C++ programs as a set of source files or as a string of characters. That is to confuse the representation with what is represented. A program is a collection of types, functions, statements, etc. To fit traditional programming environments, these concepts are represented as characters in files. Basing C++ implementations on character oriented tools has been a major impediment to progress. [ ... much more ... ]" I personally sympathize with the sentiment, but after many years I have become persuaded that there is no hope of easy interchange except in text files, and that easy interchange is of such paramount importance that it overrides even the desires to have the representation of a program in a more directly structural form than a stream of characters. Robert> They specify the objects and create a structure from which the Robert> objects are created. snowballinfo> This is true for C++ and some other languages, however for snowballinfo> Smalltalk Classes are objects which take up memory space snowballinfo> (and sometimes CPU cycles). Well, surely not in Smalltalk-80, which is arguably the ``classic'' Smalltalk that most people have heard of; which is the Smalltalk dialect you are thinking of in which classes are objects, instead of being merely represented by objects as in Smalltalk-80? Can it still be called ``Smalltalk''? After all that classes are not objects and that the two concepts are very distinct is one of the major design decisions of Smalltalk-80 (in the early versions of PARC Smalltalk the distinction was, arguably, not that sharp). ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-12 0:00 ` Robert C. Martin 1996-11-12 0:00 ` Snowball @ 1996-11-12 0:00 ` Alan Lovejoy 1 sibling, 0 replies; 79+ messages in thread From: Alan Lovejoy @ 1996-11-12 0:00 UTC (permalink / raw) Robert C. Martin wrote: > For example, if object A sends a message to object B, then there must > be a class relationship somewhere that supports that. For example, the > relationships might be an "aggregation" relationship between the class > of A and the class of B. Or it might be an 'association' between > one of the base classes of A and one of the base classes of B, etc. Really? Supose the implementation language has objects, messages and methods, but no classes? For example, a program written in Self. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Paul_Gover 1996-11-06 0:00 ` Alan Lovejoy 1996-11-06 0:00 ` Jan Steinman @ 1996-11-06 0:00 ` Snowball 1996-11-13 0:00 ` Peter Pflaum 2 siblings, 1 reply; 79+ messages in thread From: Snowball @ 1996-11-06 0:00 UTC (permalink / raw) Paul_Gover@uk.ibm.com wrote: > > In <32813322.41C6@kyebek3.kjist.ac.kr>, Dong Oh Kim <kdo@kyebek3.kjist.ac.kr> writes: > > ... > >Let me have your opinions about followings: > > > > 1. Is everything OK with existing oo development methods? > > If not, what are needed? and what stage should be enforced in the > > future,i.e,analysis or design,etc...? > > ... > > OK, here's my 2 cents: most OO development methods concentrate too much > on objects and too little on classes. This obstructs investigation of > inheritance and polymorphism, making it hard to attain the benefits of OO. > IMHO, in many cases this is because the design method derives from some > entity modelling tool from before the days of OO, and entities are objects, > not classes. > > Paul Gover > IBM Warwick Development Group > Mumbling for myself, not IBM I agree with Paul here, this is the reason I have been developing Snowball Rapid Rapid Systems Engineering Tool, a dedicated Smalltalk tool which I call a RASE (Rapid Systems Engineering) tool. It looks like a CASE tool but it is radically different to one. The site is still under heavy construction but you can read about my ideas and approach in our web pages http://www.rase.com/ and http://www.rase.com/snowball/ Tansel Ersavas mailTo:tansel@deep.net ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 ` Snowball @ 1996-11-13 0:00 ` Peter Pflaum 1996-11-13 0:00 ` David N. Smith 0 siblings, 1 reply; 79+ messages in thread From: Peter Pflaum @ 1996-11-13 0:00 UTC (permalink / raw) To: snowballinfo *SYNERGY-NET on http://metro.turnpike.net/~pflaump http://www.altavista.forum.digital.com/ Floor 503 If you need other assistance, please write to synergy@mail.trevista.com (do not reply to this e-mail). RE: Punctuated Equilibrium - PC revolution II How to survive ? The recruits to a tough training program are traditionally told to "Look to the right, look to the left, one of you won't be here next year." Sixty five million years ago, at the annual meeting of the Dinosaurs /IBM/MS/PC Productions Inc. they heard a talk by the current management guru about becoming small, fast and furry. They were told, their survival depended on their ability to adapt to the rapid changes in their global environment. The huge Dinosaurs looked at each other and wondered how they were going to change from large, cold blooded reptiles to mammals. The motivational speaker suggested "visualization". They should relax and imagine "in their minds" eye that they were small, fast and furry. If they had a "positive" attitude nothing was impossible. It didn't work. Almost all species that ever existed are extinct. Human, as all creatures large and small ( except maybe insects ) are not biologically designed for rapid change. What happens is mass extinctions. The space ( niches ) made by short periods of extinctions are then slowly filled ( somewhat at random ) by the survivors. Species survive by geographic dispersion and innate variety. How to survive the mass extinction that NC's will cause among PC 's or how to become very small, very fast and very furry. The high ground is an expanded vision of the ISP ( Internet Service Provider ) and this will happen a order of magnitude faster than most people think. RE: EPCOT II: Electronic Prototype Community On-line Technology MS/GE/NBC, ATT, MCI/BT, Oracle/Netscape/Sun - ( and others ) evolve and create new networks of low orbit satellites, earth stations, transponders, cells, wires, cables, something like the NSA/DOD and Navy global communications systems. For big organizations the systems are almost in place, for middle size companies they are serviced from "EPCOT II Club Houses ", and individual consumers on a ad hoc basis using AS phone modems, cable, dishes, microwaves and what ever sort of works. The earth stations are all purpose servers using object management multi- channel programs to provide complete on-line services. (IIOP) So you can do a lot of things from almost anywhere. EPCOT II is a set of franchise EPCOT II clubs offering work station cubicles to office suites with T3 satellite up links. Within their zone they are a quality Internet Service Provider ( ISP ) for the big organization and individual users. People can work on the road or at home, so they can live in some very nice places. The current market targets are places where there is already a high density of high tech users. The idea is "synergy" shared resources rather than stand alone systems. The idea is "plug and play" turn-key utilities rather than complex on-site equipment and operations. Larry ( Oracle ) has it about right but is a little possessive, Marc (Netscape) understands the technology and Bill (MS) who is very possessive will get on board by the end of the year. Where do you want to be, alone on the California coast, in a planned community in Costa Rica, The Swiss or Colorado Mountains, New Zealand or Australia, the French Riviera, a Greek Village; the EPCOT work and pay master will help you do your work, using temporary synergy groups, video conferences, high quality image processing, what ever, where ever. EPCOT II global work groups can produce content, hardware, software, server management, education and training, video, web pages, news, applications what ever. It's a company made of off site locations, with a temporary work group and employment agency, it's a server of home and remote work locations, it's a hotel, it's a cafe, it's a node and ISP, it's a planned physical place and network of hard wired connections between international high-tech communities of transponders, cables and phones. It is the Electric Prototype Community on-line Technology of today and tomorrow, the global village, the world according to Charles Handy. see http://metro.turnpike.net/~pflaump/hotflash.htm for AS lines and communications systems. http://www.washingtonpost.com/wp-srv/WPlate/1996-11/12/098L-111296-idx.html Wireless connections: businesses and schools that have been trying out a system that beams data from the Internet to their computers using high- frequency radio waves. The wireless technology allows users to travel in cyberspace at about 10 million bits per second, nearly seven times faster than today's high-speed data lines and almost 350 to 700 times faster than the average modem. "The speed is just blinding," said Stephen Coran, a partner at the firm who uses the Internet to search legal databases. The radio wave pilot project, which has been operating since early summer, is run by CAI Wireless Systems Inc. in Albany, N.Y., and Hybrid Networks Inc. in Cupertino, Calif. Hybrid plans to offer commercial service in the area by the middle of next year, said Chuck Zumbaugh, a Hybrid consultant working on the project. Copies of the SYNERGY JOURNAL sent by request: pflaump@MSN.COM SYNERGY-NET on http://synergy.trevista.com/ Peter E. Pflaum Ph.D. , Headmaster GLOBAL_VILLAGE_SCHOOLHOUSE 225 Robinson Road, New Smyrna Beach, FL 32169-2176 (904) 428-9609 pflaump@mail.trevista.com http://metro.turnpike.net/~pflaump/ http://forum.trevista.com/ or join #synergybunch on IRC. Go in and set up conference, documents, newspaper, teams. http://www.altavista.forum.digital.com/ Directory Floor 503 & 504 http://earth.ics.uci.edu:8080/faqs/punc-eq.html http://earth.ics.uci.edu:8080/origins/biblio/punctuated_equilibri um.html Natura non facit saltum; ( Nature does not take leaps but it does?) http://metro.turnpike.net/~pflaump/winhttpd/htdocs/doc1a.htm Evolution, competition, survival of the fittest is a fact but Darwin's theory of evolution does not explain the " Origins of the Species" or the "Decent of man". The physical fossil record does not support, and never has, the idea of slow steady "progress" from simple to complex, in small steps from ammonites to people. "Time Frames" by Niles Eldredge explains how science adjusted to the reasonable social expectations of the machine age by imposing on the data preconceived notions of progress and order. Darwin's type of slow evolution does happen but so does rather sudden extinctions and discontinuous bursts of creative activity. Physics: The Uncertainty principle: Con't doc1a.htm ( above ) Copies of the SYNERGY JOURNAL sent by request: pflaump@MSN.COM SYNERGY-NET on http://synergy.trevista.com/ Peter E. Pflaum Ph.D. , Headmaster GLOBAL_VILLAGE_SCHOOLHOUSE 225 Robinson Road, New Smyrna Beach, FL 32169-2176 (904) 428-9609 pflaump@mail.trevista.com http://metro.turnpike.net/~pflaump/ http://forum.trevista.com/ or join #synergybunch on IRC. Go in and set up conference, documents, newspaper, teams. http://www.altavista.forum.digital.com/ Directory Floor 503 & 504 ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-13 0:00 ` Peter Pflaum @ 1996-11-13 0:00 ` David N. Smith 0 siblings, 0 replies; 79+ messages in thread From: David N. Smith @ 1996-11-13 0:00 UTC (permalink / raw) >jhd@herold.franken.de (Joachim Durchholz) writes: > >>> execution of a program. And in a Self program, classes never exist at all >>> (not even in the program text). It is interesting to note that the optimizer creates things that look a lot like classes so that clones of objects don't take up a lot more space than necessary. But they are fully hidden. Dave _____________________________________________ David N. Smith IBM T J Watson Research Center, Hawthorne, NY Mailto: dnsmith@watson.ibm.com Home Page: http://www.dnsmith.com/ _____________________________________________ Any opinions or recommendations are those of the author and not of his employer. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim 1996-11-06 0:00 ` Paul_Gover @ 1996-11-07 0:00 ` Joachim Durchholz 1996-11-08 0:00 ` Richard A. O'Keefe 1996-11-08 0:00 ` Jon S Anthony ` (5 subsequent siblings) 7 siblings, 1 reply; 79+ messages in thread From: Joachim Durchholz @ 1996-11-07 0:00 UTC (permalink / raw) alovejoy@concentric.net wrote 06.11.96: > Objects are objects, not classes. Of course :) > OO programs are systems of interacting **objects**, not systems of > interacting **classes**. I think this is a bit misleading. OO program texts are definitely systems of classes (or, rather, textual representations of classes). We don't specify a single objects when writing code for a class; instead, we specify the behaviour of a set of objects, of which there may be none, one, or an unlimited number present at run-time. > The architecture and design of a program is a function of what **objects** > it contains and how they interact. Well, now I have to disagree. An OO program consists of classes, which are descriptions of the behaviour of object sets. I.e. it is object behaviour that we describe, not objects themselves (which are a bit irrelevant anyway, we want the computer to *behave*, not to *be*). > Class inheritance is an abstraction mechanism for code sharing. It is much more. It is a mechanism for specifying similarities, and in this respect goes far beyond mere code sharing. I can have exactly the same amount of code sharing with subroutines (that take routines as parameters in cases where I need dynamic dispatch). This is available in C, but nobody would regard C equivalent to an OO language! > It has > nothing much to do with architecture or design of a program. Proof: any > program using class inheritance can easily be converted into a completely > equivalent program where all the leaf classes are root classes: one simply > duplicates all the inherited methods in each leaf class. On the same basis, I could declare C to be equivalent to assembler. Proof: it is always possible to mechanically produce an equivalent assembler program. (I won't do this :) The mere possibility to reproduce a program in a different way just proves Turing equivalence, which we aren't too interested in when discussing software engineering issues. The real issues are readability, maintainability, and reusability of the code, by a human programmer, and representation can have a tremendous impact on that. Regards, -Joachim -- Looking for a new job. Resume available on request. WWW version of resume available under http://www.franken.de/users/herold/jhd/resume/index.html ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-07 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz @ 1996-11-08 0:00 ` Richard A. O'Keefe 1996-11-09 0:00 ` Piercarlo Grandi 0 siblings, 1 reply; 79+ messages in thread From: Richard A. O'Keefe @ 1996-11-08 0:00 UTC (permalink / raw) jhd@herold.franken.de (Joachim Durchholz) writes: >I think this is a bit misleading. >OO program texts are definitely systems of classes (or, rather, textual >representations of classes). This is an overgeneralisaton. Not every OO language is class based. The OO system in Xlisp-Stat, for example, is not class based, and nor is SELF. Nor need there be any text or fixed collection of texts that describes a SELF program. SELF is not alone in this: I have used a GUI builder where you constructed _objects_ on the screen that were then dumped out as textul representations to be used to construct _objects_, not classes. >> The architecture and design of a program is a function of what **objects** >> it contains and how they interact. >Well, now I have to disagree. Well, no, you don't. What you _do_ have to do is understand that there is more than one way to skin a cat, and that in some OO languages you _do_ describe objects and methods that are attached to objects (individual objects, not classes), while in some other OO languages you _don't_. Looked at NewtonScript lately? -- Mixed Member Proportional---a *great* way to vote! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-08 0:00 ` Richard A. O'Keefe @ 1996-11-09 0:00 ` Piercarlo Grandi 1996-11-13 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-09 0:00 UTC (permalink / raw) Alan Lovejoy writes: > OO programs are systems of interacting **objects**, not systems of > interacting **classes**. ok> jhd@herold.franken.de (Joachim Durchholz) writes: jhd> I think this is a bit misleading. OO program texts are definitely jhd> systems of classes (or, rather, textual representations of jhd> classes). >>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.edu.au> writes: ok> This is an overgeneralisaton. Not every OO language is class ok> based. [ ... consider Self etc ... ] Well, but then they something like prototype based, as you observe. The observation above is, as per your remark, strictly speaking not general enough; but then just saying "OO module" instead of "class" would give it generality. For whether class or prototype based, an OO program is a collection of (OO) modules, and values at runtime are either instances of a class or clones of a prototype. OO programs (as opposed to their executions) do occasionally contain some instances or clones, but this does not justify the observation that "OO programs are systems of interacting **objects**". While the analysis and design of an OO program may/should be based on some mental image of how it is going to be executed, both activities are really about deciding into which ``encapsulated'' concepts and modules to decompose the solution to a problem, and not into which ``interacting'' objects (even if in some languages OO modules are objects, and in some others objects to interact). ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-09 0:00 ` Piercarlo Grandi @ 1996-11-13 0:00 ` Richard A. O'Keefe 1996-11-27 0:00 ` Piercarlo Grandi 0 siblings, 1 reply; 79+ messages in thread From: Richard A. O'Keefe @ 1996-11-13 0:00 UTC (permalink / raw) piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes: >The observation above is, as per your remark, strictly speaking not >general enough; but then just saying "OO module" instead of "class" >would give it generality. Yes, but it would provide generality by means of obscurity and vagueness. What, for example, is an "OO module"? I am aware of several languages having both objects and modules: Ada 95 (module=package, object=tagged record instance) ISO Pascal Extended with Object-Oriented Extensions to Pascal (module=module, object=object=pointer to extended record) Oberon-2 Common-Lisp/CLOS (module=package, object=class instance) C++ (module=translation unit maybe, or better, namespace; object=record) so the term "OO module" seems to mean something like "module containing OO components". >For whether class or prototype based, an OO program is a collection of >(OO) modules, and values at runtime are either instances of a class or >clones of a prototype. (1) In Self, it's not who you are _cloned from_ that determines your properties, but who _your parents are_. The nearest analogue of a class would be a partial function from parent slot names to objects, e.g. the "class" (parent*=o123, uncle*=o125, locale*=o23) (2) The parents of an object can vary through time. >OO programs (as opposed to their executions) do occasionally contain >some instances or clones, but this does not justify the observation that >"OO programs are systems of interacting **objects**". It seems to me that there may be an equivocation involving the word "program" here. Even for C++, it is true that "the EXECUTION of a program is a system of interacting objects". You are saying "even for a prototype based language, a program is statically composed of classes and methods", but once again, nothing says that an OO language has to be batch compiled. In the static sense which I think you have in mind, no "program" as such need ever exist. >While the analysis and design of an OO program may/should be based on >some mental image of how it is going to be executed, both activities are >really about deciding into which ``encapsulated'' concepts and modules ^^^^^^ >to decompose the solution to a problem, and not into which >``interacting'' objects (even if in some languages OO modules are >objects, and in some others objects to interact). Is the Sun "really" a nuclear reactor or is it "really" just a big ball of hot gas or is it "really" a source of heat and light? I don't think anyone is denying that the "analyse, design static structure, build static structure, light blue touch paper and stand well back" approach is appropriate for a very large number of applications and projects. (I am reading this in comp.lang.ada, after all, and I wouldn't be using Ada if I didn't think that was the right way to do some things.) The point is that it doesn't _have_ to be that way for _all_ applications and projects, and there _are_ languages permitting a different mindset. In particular, I cannot imagine why anyone would want to rule out meta-design, where your program _at run time_ constructs new 'OO modules' (whatever they are) with good interfaces and starts using them. It's not too much to say that that's exactly how the Newton works. -- Mixed Member Proportional---a *great* way to vote! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-13 0:00 ` Richard A. O'Keefe @ 1996-11-27 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-27 0:00 UTC (permalink / raw) >>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.edu.au> writes: ok> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes: piercarl> The observation above is, as per your remark, strictly piercarl> speaking not general enough; but then just saying "OO module" piercarl> instead of "class" would give it generality. ok> Yes, but it would provide generality by means of obscurity and vagueness. ok> What, for example, is an "OO module"? I am aware of several languages ok> having both objects and modules: ok> Ada 95 (module=package, object=tagged record instance) ok> ISO Pascal Extended with Object-Oriented Extensions to Pascal ok> (module=module, object=object=pointer to extended record) ok> Oberon-2 ok> Common-Lisp/CLOS (module=package, object=class instance) ok> C++ (module=translation unit maybe, or better, namespace; object=record) ok> so the term "OO module" seems to mean something like "module containing OO ok> components". Well, I had hoped that it was very clear from the context is that I was using ``OO module'' in the sense of ``module designed according to the OO paradigm''. This encompasses, as I had written, both the concept of class and of prototype (and of actor). piercarl> For whether class or prototype based, an OO program is a piercarl> collection of (OO) modules, and values at runtime are either piercarl> instances of a class or clones of a prototype. ok> (1) In Self, it's not who you are _cloned from_ that determines your ok> properties, but who _your parents are_. Please reread more carefully the above paragraph: I was not talking of the properties of a clone, but its instantiation relationship to ``something''. Most definitely in Self like in other prototype based languages a clone is an instance of its prototype, and not of its parents, just as in class based languages an object is an instance of a class, and not of the parents of that class. ok> The nearest analogue of a class would be a partial function from ok> parent slot names to objects, e.g. the "class" (parent*=o123, ok> uncle*=o125, locale*=o23) I think this point is based on confusing the distinction between delegation and inheritance for reuse of interface and implementation, with the distinction between class and prototype as a template for instantiation. The ``properties'' (operations etc.) of an object depend on the sum of the properties of the class parents in (some) class based languages, and on the sum of properties of the clone parents in (some) prototype languages; however objects are still instances of one specific class and of one specific prototype. ok> (2) The parents of an object can vary through time. This has nothing to do with being class or prototype based; it has something to do with the ability to change ``types'' (metamorphism) at runtime, which is not even unique to Self, or to prototype based OO systems, or to OO systems. piercarl> OO programs (as opposed to their executions) do occasionally piercarl> contain some instances or clones, but this does not justify piercarl> the observation that "OO programs are systems of interacting piercarl> **objects**". ok> It seems to me that there may be an equivocation involving the word ok> "program" here. Even for C++, it is true that ok> "the EXECUTION of a program is a system of interacting objects". How? In what sense? How do objects interact in the execution of a C++ program? Are you sure? When I use some sort of debugger to watch the execution of a C++ program I see threads running procedures in different modules, those procedures call each other, passing objects as arguments; I have never seen those objects interacting. It would be interesting to know what I have been missing. ok> You are saying "even for a prototype based language, a program is ok> statically composed of classes and methods", Not at all: this is presented as a quote, but it is nowhere like what I have said; please reread more carefully what I have actually written: piercarl> For whether class or prototype based, an OO program is a piercarl> collection of (OO) modules, and values at runtime are either piercarl> instances of a class or clones of a prototype. ok> but once again, nothing says that an OO language has to be batch ok> compiled. Nor have I ever written anything even remotely suggesting this. Are you sure you have been reading my article? All I am saying is that an OO program must be composed of modules, such modules may be classes or prototypes (or actors). I have never stated or implied that such modules or prototypes should be defined statically or should be batch compiled. What I am saying is really just something obvious: that programs, and OO programs no more and no less than others, are descriptions of abstractions over their executions; therefore they are composed of ``template'' like entities, e.g. modules, types, procedures, that will be instantiated into objects of various sorts at runtime, but such objects are not described in the program itself. A program, being an exercise in abstraction, does not describe a potentially very large collection of execution objects; it describes abstract entities, templates that give rise to those. Those templates can then be dynamically defined, can be interpreted, compiled, or anything in between; still the program is composed (almost exclusively) of such abstraction/templates, and not of interacting objects. ok> In the static sense which I think you have in mind, This attempt at telepathy unforunately has failed. Please read what I have written instead of trying parapsychology. I have never ever implied any static sense; merely stated the obvious, that programs, whether static or dynamic, are (mostly) composed of abstract entities (modules for example), not of their instances. Both abstrations and instances can be created statically or dynamically; however (by and large) programs are systems of related (I would use ``interacting'') abstractions, like classes or prototypes in the OO case, or procedures, not of instances; viceversa program executions are (by and large) systems of interacting instances (threads, procedure instances, actors, for example), but not abstractions. Still, as I wrote it, I did not rule out static creation of instances or runtime creation of abstractions. ok> no "program" as such need ever exist. Well, actually it must: for _something_ must be well defined at some time to be called a ``program''. People write programs, and they get signed off and released. If we had any sort of General Problem Solver, the issue of writing and releasing programs would not arise; but then OO would be largely useless as well, for OO is an idea on how to maximize reuse in human-written programs. There is no reason to think that maximizing reuse, or even just maximizing it in the OO way, would be the right thing to do if the author of the program were a mechanical instead of a human program synthetizer. Still, at any point in time, even a program synthetizer must define a currently running program, the one being executed. piercarl> While the analysis and design of an OO program may/should be piercarl> based on some mental image of how it is going to be executed, piercarl> both activities are really about deciding into which piercarl> ``encapsulated'' concepts and modules ^^^^^^ piercarl> to decompose the solution to a problem, and not into which piercarl> ``interacting'' objects (even if in some languages OO modules piercarl> are objects, and in some others objects to interact). ok> Is the Sun "really" a nuclear reactor or is it "really" just a big ok> ball of hot gas or is it "really" a source of heat and light? The analogy fails here: for the Sun is a physical entity, and you are just presenting different views (mental constructs) of it, and none may be more appropriate than another. But that an OO program *is* a set of modules is so by _construction_, and that "analysis and design of an OO program [ ... ] are really about deciding into which ``encapsulated'' concepts and modules to decompose the solution to a problem" is not therefore a point of view, but the construction process that produces it. ok> I don't think anyone is denying that the "analyse, design static ok> structure, build static structure, light blue touch paper and stand ok> well back" approach is appropriate for a very large number of ok> applications and projects. (I am reading this in comp.lang.ada, ok> after all, and I wouldn't be using Ada if I didn't think that was ok> the right way to do some things.) Not that I have written any of the sort, but it is an interesting point of view, and is in fact correct, if one looks at programs as produced by humans. At some point, if only because one is the author of a program synthetizer, this is what must be done. ok> The point is that it doesn't _have_ to be that way for _all_ ok> applications and projects, and there _are_ languages permitting a ok> different mindset. Not at all; you are confusing the notions of writing a program, and of writing a program synthetizer. Some languages allow doing runtime synthesis and execution of programs, some don't; but in both cases the program *as delivered by the human* _must_ be statically defined, and in both cases the program, whether its source is human/static or mechanical/dynamic, _must_ be composed of modules, and not their instances. That human generated program _must_ be static is _unavoidable_, for humans don't live inside computers and are not part of its execution environment. (the point about static/dynamic program composition has been raised by you; I had not in any way restricted my argument explicitly or implicitly to statically constructed programs, or to those authored by humans). That programs, whether generated statically by a human or by a synthetizer, or dynamically by a synthetizer, must (mostly) consist of abstractions and not of their instances is also all but necessary, for the essence of the usefulness of a program is that is it is an abstraction over all its possible executions. This applies both to OO and non-OO programs; in the particular case of OO programs, whether they are statically or dynamically authored, by a human or by another program, they must be (mostly) composed of abstractions which are modules, and these modules must respect the OO decomposition paradigm (encapsulation of all and only the procedures that access the representation of a single type) whether these modules are classes, or prototypes, or actors or whatever else. It *is* possible to write OO programs which _are_ indeed systems of interacting objects, for example an actor system program that prints the result of summing 2 and 3, but this is a rather exceptional case because: * objects don't interact, even at execution time, except in actor systems. * writing programs as systems of objects, whether interacting or not, is rather less useful than writing them as systems of related abstractions, for example because in general there will be many less such abstractions than their instances, such being the nature of abstractions. ok> In particular, I cannot imagine why anyone would want to rule out ok> meta-design, Who has ruled this out in this discussion? I am not aware of anbyody having done so. ok> where your program _at run time_ constructs new 'OO modules' ok> (whatever they are) with good interfaces and starts using them. ok> It's not too much to say that that's exactly how the Newton works. That's perfectly OK. But the program that does this _must_, in order to be OO, be decomposed in modules that satisfy the OO decomposition strategy, and so the programs that is generated. Whether the latter, the output of a programs synthetizer _should_ be structured in the OO way, or any other way, or structured at all, is a rather interesting question for which I don't think there are as yet any answers. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim 1996-11-06 0:00 ` Paul_Gover 1996-11-07 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz @ 1996-11-08 0:00 ` Jon S Anthony 1996-11-08 0:00 ` Joachim Durchholz ` (4 subsequent siblings) 7 siblings, 0 replies; 79+ messages in thread From: Jon S Anthony @ 1996-11-08 0:00 UTC (permalink / raw) In article <6KRKVf9k3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes: > alovejoy@concentric.net wrote 06.11.96: > > > Objects are objects, not classes. > > Of course :) > > > OO programs are systems of interacting **objects**, not systems of > > interacting **classes**. > > I think this is a bit misleading. > OO program texts are definitely systems of classes (or, rather, textual > representations of classes). We don't specify a single objects when I see that "all the world is a class" view has clouded your perceptions! :-). Not all OO (languages,systems,programs,etc) are class based. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim ` (2 preceding siblings ...) 1996-11-08 0:00 ` Jon S Anthony @ 1996-11-08 0:00 ` Joachim Durchholz 1996-11-12 0:00 ` Alaric B. Williams 1996-11-13 0:00 ` Richard A. O'Keefe 1996-11-08 0:00 ` Nick Thurn ` (3 subsequent siblings) 7 siblings, 2 replies; 79+ messages in thread From: Joachim Durchholz @ 1996-11-08 0:00 UTC (permalink / raw) alovejoy@concentric.net wrote 08.11.96: > > I think this is a bit misleading. Seems I got mislead my self a bit :) > execution of a program. And in a Self program, classes never exist at all > (not even in the program text). Well, I don't know Self (or any other prototype language), so I'm a bit bewildered about what you say about this statement. Could anybody post a short characterisation of prototype languages? > > We don't specify a single objects when > > writing code for a class; instead, we specify the behaviour of a set of > > objects, of which there may be none, one, or an unlimited number present > > at run-time. > > To the extent that this is true, this is an artifact of using classes as an > abstraction mechanism to specify the behavior of objects. I don't think it is too artificial to define a class, even if it is for a single object. At least not if the class specification isn't longer or more complicated than the specification for the single object. I do see some overhead in that it is necessary to declare an attribute that is instantiated with the constructor of the class. Given the size of class texts, I doubt that this overhead is a problem. > > > Class inheritance is an abstraction mechanism for code sharing. > > > > It is much more. It is a mechanism for specifying similarities, and in > > this respect goes far beyond mere code sharing. > > A class specifies the internal mechanisms of an object. Class inheritance > therefore specifies the commonality of implementation mechanisms. > ... > This is actually what I was trying to get at > in saying that "class inheritance is an abstraction mechanism for code > [implementation mechanism] sharing." Not in all cases. Most OO languages have abstract/virtual/deferred classes that primarily serve to specify external behaviour, not implementation. I definitely agree that inheritance can be used for code sharing, but it is also useful for object classification. > The type/interface hierarchy is an important topic in design, and hence is > an important issue that should be addressed by a design methodology. > ... Agreed. (As with the rest of your post :) -Joachim -- Looking for a new job. Resume available on request. WWW version of resume available under http://www.franken.de/users/herold/jhd/resume/index.html ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-08 0:00 ` Joachim Durchholz @ 1996-11-12 0:00 ` Alaric B. Williams 1996-11-13 0:00 ` Richard A. O'Keefe 1 sibling, 0 replies; 79+ messages in thread From: Alaric B. Williams @ 1996-11-12 0:00 UTC (permalink / raw) jhd@herold.franken.de (Joachim Durchholz) wrote: >alovejoy@concentric.net wrote 08.11.96: >> > I think this is a bit misleading. >Seems I got mislead my self a bit :) >> execution of a program. And in a Self program, classes never exist at all >> (not even in the program text). >Well, I don't know Self (or any other prototype language), so I'm a bit >bewildered about what you say about this statement. >Could anybody post a short characterisation of prototype languages? Basically, instead of creating a class, we instead create a blank object and insert methods into it. Any object of that 'type' is a kind of clone of that prototype object. In Self, this is implemented by parent pointers in objects that refer to the objects they derive from. EG, point objects derive from a prototypical point ("traits Point"). They contain overriden x and y variables, so they have individual identity (otherwise, they'd always refer to the prototypical x and y objects in the prototype point). This is kinda cool for some things! ABW -- "Simply drag your mother in law's cellphone number from the Address Book to the Laser Satellite icon, and the Targeting Wizard will locate her. Then follow the onscreen prompts for gigawattage and dispersion pattern..." (Windows for Early Warning and Defence User's manual P385) Alaric B. Williams Internet : alaric@abwillms.demon.co.uk <A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A> ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-08 0:00 ` Joachim Durchholz 1996-11-12 0:00 ` Alaric B. Williams @ 1996-11-13 0:00 ` Richard A. O'Keefe 1 sibling, 0 replies; 79+ messages in thread From: Richard A. O'Keefe @ 1996-11-13 0:00 UTC (permalink / raw) jhd@herold.franken.de (Joachim Durchholz) writes: >> execution of a program. And in a Self program, classes never exist at all >> (not even in the program text). >Well, I don't know Self (or any other prototype language), so I'm a bit >bewildered about what you say about this statement. >Could anybody post a short characterisation of prototype languages? Here it is in one line: - objects inherit methods and fields from *other objects*. In Self, for example, an object is a collection of named slots, some of which contain methods, some of which contain data, and some of which contain references to other objects called "parents". An object need not have _any_ parents, may have one, or may have more than one. If a slot is needed for an object that doesn't directly contain a slot with that name, the parents are searched. A parent slot may be changed at any time, so "mycar" may reparent itself from "vehicle" to "scrap_metal" at any time... >Not in all cases. Most OO languages have abstract/virtual/deferred classes >that primarily serve to specify external behaviour, not implementation. In the OO languages I am familiar with, nothing prevents an abstract class providing implementations of _some_ of its methods, and this is very often done. >I definitely agree that inheritance can be used for code sharing, but it >is also useful for object classification. The trouble is that there are applications where the way an object should be classified (without changing its identity) varies with time. And even when that doesn't happen, the two hierarchies don't necessarily line up perfectly (which is why Java has both 'interfaces' which refer to `is-a' and 'classes' which refer to `is implemented using parts of'). -- Mixed Member Proportional---a *great* way to vote! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim ` (3 preceding siblings ...) 1996-11-08 0:00 ` Joachim Durchholz @ 1996-11-08 0:00 ` Nick Thurn 1996-11-08 0:00 ` Alan Lovejoy 1996-11-08 0:00 ` Alan Lovejoy ` (2 subsequent siblings) 7 siblings, 1 reply; 79+ messages in thread From: Nick Thurn @ 1996-11-08 0:00 UTC (permalink / raw) alovejoy@concentric.net wrote 06.11.96: > > Class inheritance is an abstraction mechanism for code sharing. > It has > nothing much to do with architecture or design of a program. > This is a dangerous notion! IMHO those who subscribe to this notion should work for "the opposition". :) So what pray tell *is* to do with architecture and design? > Proof: any > program using class inheritance can easily be converted into a completely > equivalent program where all the leaf classes are root classes: one simply > duplicates all the inherited methods in each leaf class. > This is wrong. It is not "simple" unless the translated program doesn't use polymorphis. Where it was used explodes to a mess of conditionals and special cases. Polymorphism moves complexity from class clients to the runtime. Your "proof" is bogus. An equivalent program cannot be mechanically produced by simply copying method implementations as *much* new code is required to deal with the dispatch of those methods. Think of a program with two sets of interacting objects. The OO version has two hierarchys each with a base abstraction that fully describes the behaviour of derived objects. The program must deal with two things only. Remove the polymorphism and what happens? The program must now deal with N things everywhere. The complexity increases exponentially with the number of new objects and all parts of the program are touched by any additional types. Nick (my opinions only) ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-08 0:00 ` Nick Thurn @ 1996-11-08 0:00 ` Alan Lovejoy 1996-11-11 0:00 ` Nick Thurn 0 siblings, 1 reply; 79+ messages in thread From: Alan Lovejoy @ 1996-11-08 0:00 UTC (permalink / raw) Nick Thurn wrote: > > alovejoy@concentric.net wrote 06.11.96: > > > > Class inheritance is an abstraction mechanism for code sharing. > > It has > > nothing much to do with architecture or design of a program. > > > This is a dangerous notion! IMHO those who subscribe to this notion > should work for "the opposition". :) But my statement is merely an obvious and intended consequence of information hiding and object encapsulation. An object is a "black box." You're not supposed to know or care what the internal mechanisms are that give it its externally visible properties and behavior--and that includes what class it may be an instance of, or what behavior it inherits instead of implementing locally. > So what pray tell *is* to do with architecture and design? Architecture is a question of the division of responsibility among the objects and subsystems within a system. It is about the roles that objects play, the relationships among and interactions between objects, and of how objects collaborate to carry out their responsibilities. Design is the process of converting a set of requirements into a specification of the types of objects than can exist and how objects of the specified types will operate as a system to satisfy the requirements. > > > Proof: any > > program using class inheritance can easily be converted into a completely > > equivalent program where all the leaf classes are root classes: one simply > > duplicates all the inherited methods in each leaf class. > > > This is wrong. > > It is not "simple" unless the translated program doesn't use polymorphis. > Where it was used explodes to a mess of conditionals and special cases. > > Polymorphism moves complexity from class clients to the runtime. > Your "proof" is bogus. An equivalent program cannot be mechanically > produced by simply copying method implementations as *much* new code is > required to deal with the dispatch of those methods. > > Think of a program with two sets of interacting objects. The OO version > has two hierarchys each with a base abstraction that fully describes > the behaviour of derived objects. The program must deal with two things > only. > > Remove the polymorphism and what happens? The program must now deal > with N things everywhere. The complexity increases exponentially with > the number of new objects and all parts of the program are touched by > any additional types. You don't understand. You are thinking in terms of some statically-typed language that uses classes as type contraints (such as C++). In a dynamically-typed language such as Smalltalk, it is syntactically legal to send any message to any object. If the object does not understand the message, an error will be reported at run time. In a statically-typed language that uses interfaces instead of classes as type constraints (such as can be done in Java), one just needs to define a hierarchy of interfaces, and then declare each class to be an implementor of the appropriate interface. Doing this gets you an otherwise equivalent program without using any class inheritance at all, and without having to use any additional switch or if statements. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-08 0:00 ` Alan Lovejoy @ 1996-11-11 0:00 ` Nick Thurn 1996-11-11 0:00 ` Paul_Gover 0 siblings, 1 reply; 79+ messages in thread From: Nick Thurn @ 1996-11-11 0:00 UTC (permalink / raw) Alan Lovejoy (alovejoy@concentric.net) wrote: > Nick Thurn wrote: > > > > alovejoy@concentric.net wrote 06.11.96: > > > > > > Class inheritance is an abstraction mechanism for code sharing. > > > It has > > > nothing much to do with architecture or design of a program. > > > [...] > > So what pray tell *is* to do with architecture and design? > > Architecture is a question of the division of responsibility among the > objects and subsystems within a system. It is about the roles that objects > play, the relationships among and interactions between objects, and of how > objects collaborate to carry out their responsibilities. Design is the > process of converting a set of requirements into a specification of the > types of objects than can exist and how objects of the specified types > will operate as a system to satisfy the requirements. > I totally agree! But objects are described by a text (smalltalk or otherwise) as classes that may be related by inheritance, containment or usage. Inheritance is not just code organisation (although it does organise code). I think there is a chicken and egg problem here. Architecture is expressed in code and code is organised by architecture. My issue (and where I think we agree) is that architecture is *more* important than code organisation because: it is more fundamental to correctness of model code will be organised anyway by a "good" model [...] > > You are thinking in terms of some statically-typed > language that uses classes as type contraints (such as C++). > > In a dynamically-typed language such as Smalltalk, it is syntactically legal > to send any message to any object. If the object does not understand the message, > an error will be reported at run time. > You are correct, I am thinking in statically typed terms. This does not invalidate what I said. Sending "any message to any object" still requires the semantics to be understood. The "typelessness" may be useful or may increase complexity. This is a design call and your milage may vary :) Nick (my opinions only) > -- > Alan L. Lovejoy |==============================================| > Smalltalk Consultant | Beware of Geeks bearing GIFs! | > alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-11 0:00 ` Nick Thurn @ 1996-11-11 0:00 ` Paul_Gover 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) David N. Smith 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Anthony Menio 0 siblings, 2 replies; 79+ messages in thread From: Paul_Gover @ 1996-11-11 0:00 UTC (permalink / raw) I think there's a general thread appearing here over the boundary between design and coding, and over what constitutes a program. What happens to the discussion if we introduce another boundary between applications and programs? I can see that an application's design might be expressed as a network of interacting objects, and without such objects there's no application. I can also see that it's possible to design class hierarchies to solve application development problems (for example a matrix class to help develop a linear programming application) which clearly contain executable program code despite having neither objects nor their interactions defined as part of the program. To clarify, we write such a class definition in terms of the indefinite article - "A matrix inverse" - whereas in the application definition we'd write in terms of the definite article - "THE costs matrix. (My apologies to readers whose native language is Russian, which I think has neither definite nor indefinite articles!) If we restrict a development method to applications, I think it's perfectly possible to consider a design which specifies no implementation details. But if we consider a development method for programs, I suggest it should address implementation details such as capacity, performance, reliability, generality. If that's so, can we separate development methods into two groups along this line, (and if so, are the groups non-empty :-)? Does the term "OO" mean the same thing when applied to the different groups? I suggest not: application designs seem to be independant of implementation, so if we use the term to mean inheritance, encapsulation and polymorphism, it's irrelevant; in the application context it's more a synonym for "entity -relationship" (which I'd justify by pointing to Alan's interacting object instances). Conversely in "component" design, the traditional OO attributes are very relevant to the implementation. Perhaps the entity-relationship details now come more as constraints on the design, ie, an input, than a design product. Paul Gover IBM Warwick Development Group Mumbling for myself, not IBM. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Paul_Gover @ 1996-11-11 0:00 ` David N. Smith 1996-11-12 0:00 ` Anthony Menio 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Anthony Menio 1 sibling, 1 reply; 79+ messages in thread From: David N. Smith @ 1996-11-11 0:00 UTC (permalink / raw) In article <3283BB94.2D82@concentric.net> Alan Lovejoy, alovejoy@concentric.net writes: >To me, the "design" of a program is a language-independent abstraction. Implementation >inheritance is a coding issue. It's about how to express the program in a programming >notation with the least amount of code duplication and/or the least amount of >code changes when requirements change. I try to stay out of 'design' discussions for a variety of reasons, partly because they often have little to do with Design, and partly because the design-it-and-throw-over-the-wall school of thought seems to have the same kinds of problems in computing as it has in other fields. Yet, here is Alan saying these things and somehow I can't resist commenting. :-) Many other fields have found that integrating design, engineering, and manufacturing (into an iterative process) leads to better products, cheaper products, and products that are easier to maintain. One doesn't end up with air-conditioners or exhaust manifolds on top of spark plugs, making a simple job into a half-day or more of work. For that matter, Alexander's patterns involve all parts of the job, from materials all the way to living in the building. A building is not just designed then dumped on some construction worker to figure out how to make fit on a lot and which materials to use. Computer languages differ greatly in how they express algorithms. One thinks differently in APL than in FORTRAN or Scheme, or in Smalltalk compared to C. C++ programmers seem to think quite differently than Smalltalk programmers, having lots of ideas like friend functions, type hierarchies, templates, and lots more stuff that I find incomprehensibly unnecessary and totally void of need or interest. My own biases aside, the point is simple: Programmers think differently in different languages. Even Java and C++, two peas in similar pods, foster different thinking patterns. I'm not interested in starting a language war. I'm a widely known Smalltalk bigot (or at least widely know as a Smalltalk bigot :-) and probably warped beyond any chance of a cure. But when I hear my friend Alan make such inflammatory statements, My fingers start to itch. I do not think one can separate design from 'mere' coding, no matter how grungy one thinks coding to be, nor how lofty one's ideas of Design. One designs a fiberglass body (and much of the rest of the car) very differently than a steel body. One designs a stone house in a totally different way than a frame house. One should design a Smalltalk program in a different way than a C++ program since there are fundamental differences in how the languages work and how people think in them when using them well. The design of a program should be an integral part of the design of the implementation of a program which should be an integral part of the coding of a program. This does not mean there is so separation between the parts. Car companies still have designers, design engineers, manufacturing engineers, and assemblers. These people with different points of view need to work together as partners, with the designer cognizant of enough of the details of the target language not to get in too much trouble, and the ultimate programmer cognizant of enough of the high-level design to understand where it all is going. Failing to consider the language at design time can leave issues open that need to be closed. If the designer has learned 'object design' but has never programmed an object, a condition I fear happens all to often, is the design suitable for implementation and maintenance in any language? Please note that I am not saying that it is impossible to implement designs thrown over the wall from a designer who doesn't consider language. I am suggesting that such designs can lead to very poor programs. Since programs are the ultimate product of the whole process, and it is the program that will be used, lived with, maintained, or thrown away, it is the program that matters, not the original design. To the extent that a programmer had to perform heroics to fit a design to a language, the design has failed and the resulting product is the poorer for it. Dave _____________________________________________ David N. Smith IBM T J Watson Research Center, Hawthorne, NY Mailto: dnsmith@watson.ibm.com Home Page: http://www.dnsmith.com/ _____________________________________________ Any opinions or recommendations are those of the author and not of his employer. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) David N. Smith @ 1996-11-12 0:00 ` Anthony Menio 0 siblings, 0 replies; 79+ messages in thread From: Anthony Menio @ 1996-11-12 0:00 UTC (permalink / raw) On 11 Nov 1996, David N. Smith wrote: > The design of a program should be an integral part of the design of the > implementation of a program which should be an integral part of the > coding of a program. This does not mean there is so separation between > the parts. Car companies still have designers, design engineers, > manufacturing engineers, and assemblers. These people with different > points of view need to work together as partners, with the designer > cognizant of enough of the details of the target language not to get in > too much trouble, and the ultimate programmer cognizant of enough of the > high-level design to understand where it all is going. > > Failing to consider the language at design time can leave issues open > that need to be closed. If the designer has learned 'object design' but > has never programmed an object, a condition I fear happens all to often, > is the design suitable for implementation and maintenance in any language? > > Please note that I am not saying that it is impossible to implement > designs thrown over the wall from a designer who doesn't consider > language. I am suggesting that such designs can lead to very poor > programs. Since programs are the ultimate product of the whole process, > and it is the program that will be used, lived with, maintained, or > thrown away, it is the program that matters, not the original design. To > the extent that a programmer had to perform heroics to fit a design to a > language, the design has failed and the resulting product is the poorer > for it. > > Dave System development is really just model building, the deliverable of each subprocess of the design process is simply a model, a description of the system, which the next subprocess takes as it input. Thus these models should be seemless, the next can be built from the previous while maintaining as much consistancy as possible. The whole point of design model is to turn the analysis model into descriptions of the classes of objects identified in light of the given implementation environment as the next phase in the development process is implementation. Thus design must consider the language used, operating system and performance considerations of the environment. However analysis does not, it assumes an ideal environment so its possible to developed this model in a totally language independent manor as you are only concerned with the objects in the system and the behavoiral relations between them. This is obviously an iterative process as well as one where there can be reverse flow. I think this is in agreement with engineering practice and industrialization process in other industries. This as it should be as the key of OO is the ability to reuse the engineering principles applied to physical systems, as we wish software systems to have the same attributes we expect of real world systems. Anthony Menio I.S. Student menio@pegasus.montclair.edu Your power is your ideas, your ideas are products of perception, your perception is the product of your architecture, architecture is everything - me ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-11 0:00 ` Paul_Gover 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) David N. Smith @ 1996-11-11 0:00 ` Anthony Menio 1 sibling, 0 replies; 79+ messages in thread From: Anthony Menio @ 1996-11-11 0:00 UTC (permalink / raw) On 11 Nov Paul Gover > I can see that an application's design might be expressed as > a network of interacting objects, and without such objects there's no > application. I can also see that it's possible to design class hierarchies > to solve application development problems (for example a matrix class to > help develop a linear programming application) which clearly contain > executable program code despite having neither objects nor their interactions > defined as part of the program. > > To clarify, we write such a class definition in terms of the indefinite article - > "A matrix inverse" - whereas in the application definition we'd write in terms of > the definite article - "THE costs matrix. (My apologies to readers whose native > language is Russian, which I think has neither definite nor indefinite articles!) > > If we restrict a development method to applications, I think it's perfectly > possible to consider a design which specifies no implementation details. > But if we consider a development method for programs, I suggest it should > address implementation details such as capacity, performance, reliability, > generality. > > If that's so, can we separate development methods into two groups along this line, > (and if so, are the groups non-empty :-)? Does the term "OO" mean the same thing when > applied to the different groups? I suggest not: application designs seem to be > independant of implementation, so if we use the term to mean inheritance, > encapsulation and polymorphism, it's irrelevant; in the application context it's > more a synonym for "entity -relationship" (which I'd justify by pointing to Alan's > interacting object instances). Conversely in "component" design, the traditional > OO attributes are very relevant to the implementation. Perhaps the > entity-relationship details now come more as constraints on the design, ie, an input, > than a design product. > > Paul Gover > IBM Warwick Development Group > Mumbling for myself, not IBM. > > I think the distinction you are speaking od is the one between the analysis model and the design model. The analysis model is one of the objects which will exist in the system and the interactions between them. These are objects not classes, thus they are definite articals. This model is assumed to take place in an ideal environment. Thus the specifics of the development environment are ignored, ie operating system, language,database system in use etc. The design model describes the classes and class relations which the objects in the previous model will be created from. This model is developed from the previous now in the specific implementation model for the system. The the processes that create these models should be seemless thus the implementation model should be created from and be as consistant as possible with the analysis model. Thus both described the system and both do so in terms of same architecture(an OO) just at different levels of detail. So in essence your talking about the deliverables of two different stages in an OO systems development process rather than two different sets of methods, and the answer is that these both reflect the OO architecture of the system equally. Regardless of the size or complexity of any system thier exists both an analysis model and a design model which will be equally valid descriptions of it. Thus any component you wish to create must have the abilites of an instance of it modeled and then a blue print to create these instances of. Consider the development of a set of components from a physical system lets say a transmission you would be interested in describing the behavoir and attributes of a example of this transmission and its sinteraction with everal instances of types of cars. From this model you would create your blueprint thus your design the type description. Anthony Menio I.S. student menio@pegasus.montclair.edu ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim ` (4 preceding siblings ...) 1996-11-08 0:00 ` Nick Thurn @ 1996-11-08 0:00 ` Alan Lovejoy 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Cesar A. Gonzalez Perez 1996-11-12 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz 7 siblings, 0 replies; 79+ messages in thread From: Alan Lovejoy @ 1996-11-08 0:00 UTC (permalink / raw) Joachim Durchholz wrote: > > alovejoy@concentric.net wrote 06.11.96: > > OO programs are systems of interacting **objects**, not systems of > > interacting **classes**. > > I think this is a bit misleading. > OO program texts are definitely systems of classes (or, rather, textual > representations of classes). In most languages that supposedly have them, "classes" exist only at compile time, not while the program runs. In any case, it is definitely the instances of the classes (the objects) whose interactions constitute the execution of a program. And in a Self program, classes never exist at all (not even in the program text). Programs are not texts. They may be **specified** by texts, but the distinction is important. The purpose of a design methodology is to help design and describe a program, not the text that specifies the program. The ideal methodology would be language independent, and the program would be derivable directly from the design without ever being expressed in a traditional programming language text. Classes are just one way to specify the behavior of an object. They are an abstraction of the common case where there are many objects all of which have the same potential behavior (I'll discuss "potential" behavior later). However, an object is a "black box." Any two objects with the identical behavior and state are functionally equivalent. How it is that there can be two different objects with the identical state and behavior makes no difference. It is an implementation detail that is intentionally hidden by the "black box" of information hiding that encapsulates an object. Perhaps the two objects were created as instances of the same class, but that is not the only possibility, nor is it required. In fact, any such requirement would essentially be a violation of the encapsulation of the object. The point here is that classes are just one possible mechanism for defining the properties of objects. The purpose of a design methodology is to design programs whose behavior meets their requirements. The textual notation used to specify the program, what language it may be written in, what the class inheritance hierarchy may be, and whether the language even has classes should be irrelevant to the methodology. Any methodology that would be helpless in the design of a program to be written in Self (which has objects but not classes) is seriously flawed. > We don't specify a single objects when > writing code for a class; instead, we specify the behaviour of a set of > objects, of which there may be none, one, or an unlimited number present > at run-time. To the extent that this is true, this is an artifact of using classes as an abstraction mechanism to specify the behavior of objects. However, it is not in general true. What a class does not do is to define the role that any of its instances will play. The role is a) the **actual** behavior of an object (that is, what messages it is sent, in which order, with what arguments, by which senders), and b) the semantics of the object, the purpose that that particular object (instance) serves in the program. Obviously, the roles of two different instances of the same class may be very different. And since a class can be used in any number of different program texts, the roles that the instances of a class may play in one program may differ substantially from the roles that instances of the class may play in some other program. A class defines the **potential** behavior and states of its instances. But just because an object can respond to a particular message does not mean it will necessarily ever be asked to do so. This is the difference between potential and actual behavior. It is central to the distinction between type and role. In order to define or specify the role that an object plays, it is essential to be able to deal with the issue of object identity. And in fact, OO languages (as opposed to OO design methodologies) typically permit the programmer to do so. It is just when the issues of object identity and the roles of specific objects become important to the design that users of the run of the mill OO design methodologies are forced to abandon the methodology and go write code. > > The architecture and design of a program is a function of what **objects** > > it contains and how they interact. > > Well, now I have to disagree. An OO program consists of classes, which are > descriptions of the behaviour of object sets. I.e. it is object behaviour > that we describe, not objects themselves (which are a bit irrelevant > anyway, we want the computer to *behave*, not to *be*). At best, the **texts** that specify a program in some programming language contain class definitions--although in some highly reflexive languages such as Smalltalk, classes are objects that exist at run time, but this is not relevant (otherwise, ALL OO languages would be required to have run-time class objects). It is true that program texts define the properties of objects, "and not the objects themselves." However, the ultimate goal of a program is the behavior of the objects, not any particular text that defines that behavior. Whether a program meets its requirements, and satisfies the person(s) who paid for it to be written, can only be determined by the behavior of the program and its objects, not by the form of the text that specifies the program. > > Class inheritance is an abstraction mechanism for code sharing. > > It is much more. It is a mechanism for specifying similarities, and in > this respect goes far beyond mere code sharing. It's true that inheritance relationships express what will be common among sets of objects. However, it is important to distinguish between the external and internal similarities among objects. One important purpose of object encapsulation is to hide the internal dissimilarities between objects, so that those objects that are externally equivalent can be used interchangeably. A class specifies the internal mechanisms of an object. Class inheritance therefore specifies the commonality of implementation mechanisms. However, it is typical that the "type" or "interface" inheritance hierarchy is different than the class (implementation) inheritance hierarchy--especially in dynamically-typed languages. This is actually what I was trying to get at in saying that "class inheritance is an abstraction mechanism for code [implementation mechanism] sharing." The type/interface hierarchy is an important topic in design, and hence is an important issue that should be addressed by a design methodology. However, while implementation inheritance is important for code reuse, change propagation and speed of development, it is at best a peripheral issue for a design methodology. Implementation inheritance should be hidden behind the "black box" of object encapsulation, at least at the design level. Why? One reason is that there are other abstraction mechanisms that can specify sharing of implementation mechanics, such as macro expansion as might be done in C, or dynamic delegation as used in the so-called prototype languages (Self, Cecil, Dylan). A design methodology should not get indigestion just because some other abstraction mechanism than class inheritance is used for this purpose. The other reason is to make the design polymorphic--that is, the design should permit any object that satisfies the required interface to be used, regardless of its internal implementation. The only place in the design where the internal implementation of a "Dictionary" should matter is in the module that specifies the design of a "Dictionary." > I can have exactly the same amount of code sharing with subroutines (that > take routines as parameters in cases where I need dynamic dispatch). This > is available in C, but nobody would regard C equivalent to an OO language! Well, that's because C doesn't have objects. And no one said that inheritance is the only way to share code. > > It has > > nothing much to do with architecture or design of a program. Proof: any > > program using class inheritance can easily be converted into a completely > > equivalent program where all the leaf classes are root classes: one simply > > duplicates all the inherited methods in each leaf class. > > On the same basis, I could declare C to be equivalent to assembler. Proof: > it is always possible to mechanically produce an equivalent assembler > program. (I won't do this :) Whether or not two languages are equivalent is not the issue. The issue is the properties of design methodologies, not the properties of languages. > The mere possibility to reproduce a program in a different way just proves > Turing equivalence, which we aren't too interested in when discussing > software engineering issues. The real issues are readability, > maintainability, and reusability of the code, by a human programmer, and > representation can have a tremendous impact on that. My argument was not that one can code two programs using different languages, algorithms, data structures, notations and object models such that both programs will have the same external inputs and outputs. I think we both agree that this can be done, but that it is irrelevant. My argument was much more specific and constrained: I was making the point that object encapsulation makes implementation inheritance irrelevant to the behavior of a program, and that therefore implementation inheritance is irrelevant to the logical design of a program as it should be expressed in a good design notation. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================| ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim ` (5 preceding siblings ...) 1996-11-08 0:00 ` Alan Lovejoy @ 1996-11-11 0:00 ` Cesar A. Gonzalez Perez 1996-11-12 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz 7 siblings, 0 replies; 79+ messages in thread From: Cesar A. Gonzalez Perez @ 1996-11-11 0:00 UTC (permalink / raw) Dong Oh Kim wrote: > 1. Is everything OK with existing oo development methods? > If not, what are needed? and what stage should be enforced in the > future,i.e,analysis or design,etc...? IMHO, we need more integration between OO methods and other technologies such as components, client/server, document management, time-awareness, databases, or distributed systems. The difference betwwen analysis and design, although attacked by many, makes a lot of sense since analysis "analyzes" the observed reality to form a model of it, while design "designs" a computer-real model from the previuos one. They're much different activities, and both absolutely necessary. > 2. Are you using a specific CASE tool? > If so, what are main advantages and disadvantages? No, we're not using a CASE tool. They're usually too expensive and hard to use. We're using the Fusion method on paper and ad-hoc Access databases. > 3. Did you have any experience of developing s/w systems by specific > OO method? If so, could you do with ease? As I said before, we use the Fusion method and it's great!. > 4. What's really needed to an engineer,who is not accustomed to OOP, to > develop a software by OO paradigm?? Be educated and trained properly, by people who _really_ understand the OO paradigm. Notice that OOP (the P is for Programming, isn't it?) is just a part of the OO way-of-doing, which involves OO analysis and design, OO thinking, etc. (even OO pizzas and shakes, some say). > Your opinion will help many people engaged in this area and better > software development environment... I'd love it does. -- Cesar A. Gonzalez Perez GTArPa/TI, USC Spain ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim ` (6 preceding siblings ...) 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Cesar A. Gonzalez Perez @ 1996-11-12 0:00 ` Joachim Durchholz 1996-11-20 0:00 ` Piercarlo Grandi 7 siblings, 1 reply; 79+ messages in thread From: Joachim Durchholz @ 1996-11-12 0:00 UTC (permalink / raw) alaric@abwillms.demon.co.uk wrote 12.11.96: > >Could anybody post a short characterisation of prototype languages? > > Basically, instead of creating a class, we instead create a blank > object and insert methods into it. Any object of that 'type' is a kind > of clone of that prototype object. Hum, I think this description applies to class-based languages as well. Just say 'class' instead of 'blank prototype object'. When are the methods inserted - at run-time? Then there's a real difference, but in that case I'm asking myself how they make sure no undefined routine is called. I see serious efficiency problems if these checks are done at run-time. Regards, -Joachim -- Looking for a new job. Resume available on request. WWW version of resume available under http://www.franken.de/users/herold/jhd/resume/index.html ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t 1996-11-12 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz @ 1996-11-20 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 79+ messages in thread From: Piercarlo Grandi @ 1996-11-20 0:00 UTC (permalink / raw) >>> "jhd" == Joachim Durchholz <jhd@herold.franken.de> writes: >>>> Could anybody post a short characterisation of prototype languages? >> Basically, instead of creating a class, we instead create a blank >> object and insert methods into it. Any object of that 'type' is a kind >> of clone of that prototype object. jhd> Hum, I think this description applies to class-based languages as jhd> well. Just say 'class' instead of 'blank prototype object'. Not quite -- for one can then change one of those clones and make it into a prototype for a new kind of objects, something which is quite not possible in class based systems. Also note that the prototype need not be ``blank'' at all. Also, if procedures belong _to_ objects instead of encapsulated _in_ classes, it becomes fairly natural to do reuse not quite by defining a class by mixing in it procedures from other classes, but by forwarding operations from one object to another, which need not be its prototype; thus it is fairly natural to use delegation rather than inheritance in prototype systems (even if the 'clone of' relationship can be used as if it were an inheritance like relationship). An example is that if a trait of a prototype is declared irrevocably immutable, there is no need to duplicate it in every clone of that prototype object; it and all its clones can ``share'' that trait. The net effect is that then the implementation starts to resemble very much that of a class based system. jhd> When are the methods inserted - at run-time? Could well be, but not necessarily. jhd> Then there's a real difference, [ ... ] Not quite, for there are systems where classes can also be changed at runtime ^ permalink raw reply [flat|nested] 79+ messages in thread
end of thread, other threads:[~1996-12-08 0:00 UTC | newest] Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-11-06 0:00 Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Dong Oh Kim 1996-11-06 0:00 ` Paul_Gover 1996-11-06 0:00 ` Alan Lovejoy 1996-11-07 0:00 ` Piercarlo Grandi 1996-11-10 0:00 ` drs 1996-11-12 0:00 ` Piercarlo Grandi 1996-11-10 0:00 ` Vlastimil Adamovsky 1996-11-11 0:00 ` Piercarlo Grandi 1996-11-11 0:00 ` Anthony Menio 1996-11-18 0:00 ` Piercarlo Grandi 1996-11-20 0:00 ` Anthony Menio 1996-11-27 0:00 ` Piercarlo Grandi 1996-11-12 0:00 ` Anthony Menio 1996-11-18 0:00 ` Piercarlo Grandi 1996-11-19 0:00 ` Anthony Menio 1996-11-27 0:00 ` Piercarlo Grandi 1996-11-11 0:00 ` Daniel Drasin 1996-11-12 0:00 ` Anthony Menio 1996-11-08 0:00 ` Paul_Gover 1996-11-08 0:00 ` Ell 1996-11-08 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Ell 1996-11-08 0:00 ` Alan Lovejoy [not found] ` <6KZQfjK-3RB@herold.franken.de> 1996-11-10 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Chris 1996-11-10 0:00 ` Vlastimil Adamovsky 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Bill Gooch 1996-11-12 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Ell 1996-11-13 0:00 ` Nick Thurn 1996-11-14 0:00 ` Bill Gooch 1996-11-19 0:00 ` Tim Ottinger 1996-11-12 0:00 ` Jan Steinman 1996-11-12 0:00 ` Alan Lovejoy 1996-11-13 0:00 ` Nick Thurn 1996-11-13 0:00 ` Alan Lovejoy 1996-11-14 0:00 ` Nick Thurn 1996-11-10 0:00 ` vlad 1996-11-12 0:00 ` Robert C. Martin 1996-11-12 0:00 ` Alan Lovejoy 1996-11-14 0:00 ` David N. Smith 1996-11-14 0:00 ` Bill Gooch 1996-11-20 0:00 ` Robert C. Martin 1996-11-20 0:00 ` Michael Malak 1996-11-20 0:00 ` Robert Dewar 1996-11-20 0:00 ` Robert Dewar 1996-11-26 0:00 ` Tucker Taft 1996-12-03 0:00 ` Robert C. Martin 1996-12-08 0:00 ` Tucker Taft 1996-11-06 0:00 ` Jan Steinman 1996-11-07 0:00 ` Paul_Gover 1996-11-12 0:00 ` Robert C. Martin 1996-11-12 0:00 ` Snowball 1996-11-15 0:00 ` Soren Skogstad Nielsen 1996-11-28 0:00 ` Piercarlo Grandi 1996-11-28 0:00 ` Piercarlo Grandi 1996-11-12 0:00 ` Alan Lovejoy 1996-11-06 0:00 ` Snowball 1996-11-13 0:00 ` Peter Pflaum 1996-11-13 0:00 ` David N. Smith 1996-11-07 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz 1996-11-08 0:00 ` Richard A. O'Keefe 1996-11-09 0:00 ` Piercarlo Grandi 1996-11-13 0:00 ` Richard A. O'Keefe 1996-11-27 0:00 ` Piercarlo Grandi 1996-11-08 0:00 ` Jon S Anthony 1996-11-08 0:00 ` Joachim Durchholz 1996-11-12 0:00 ` Alaric B. Williams 1996-11-13 0:00 ` Richard A. O'Keefe 1996-11-08 0:00 ` Nick Thurn 1996-11-08 0:00 ` Alan Lovejoy 1996-11-11 0:00 ` Nick Thurn 1996-11-11 0:00 ` Paul_Gover 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) David N. Smith 1996-11-12 0:00 ` Anthony Menio 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Anthony Menio 1996-11-08 0:00 ` Alan Lovejoy 1996-11-11 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Cesar A. Gonzalez Perez 1996-11-12 0:00 ` Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Joachim Durchholz 1996-11-20 0:00 ` Piercarlo Grandi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox