From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/11 Message-ID: #1/1 X-Deja-AN: 195853639 sender: pcg@osfb.aber.ac.uk references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> organization: Prifysgol Cymru, Aberystwyth newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-11-11T00:00:00+00:00 List-Id: >>> "vlad" == Vlastimil Adamovsky writes: vlad> pcg@aber.ac.uk (Piercarlo Grandi) wrote: >>>>> "alovejoy" == Alan Lovejoy 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?