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: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public From: Anthony Menio Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/20 Message-ID: #1/1 X-Deja-AN: 197845787 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> content-type: TEXT/PLAIN; charset=US-ASCII organization: Montclair State University mime-version: 1.0 newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai Date: 1996-11-20T00:00:00+00:00 List-Id: On 18 Nov 1996, Piercarlo Grandi wrote: > >>> "menio" == Anthony Menio 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