Path: utzoo!attcan!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.object Subject: Re: Comments on OOP style Message-ID: Date: 11 Feb 90 09:26:36 GMT References: <135300027@p.cs.uiuc.edu> <135300028@p.cs.uiuc.edu> <10527@microsoft.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 29 In-reply-to: jimad@microsoft.UUCP's message of 9 Feb 90 19:51:34 GMT In article <10527@microsoft.UUCP> jimad@microsoft.UUCP (JAMES ADCOCK) writes: In short, one can come up with several different dependency charts depending on what definition of "dependency" one is interested in. And they could all be valid ways of looking at *differing* problems of interdependency. Is it my imagination or is this beginning to sound like the methods one would apply to developing a relational data model? In fact, is this not true with most any OOD methodology as it starts with objects (entities?) to be dealt with, then addresses their "sphere of influence" (attributes), then their interrelationships (public interface), and their internal functionality? Perhaps its time to address the "other" design methodologies and what they lack that OO can provide or how they apply to OO. For instance, someone mentioned how an OO methodology is not a top-down methodology. However, I suspect a lot of people approaching a new application to apply an OO methodology would start by finding the largest objects in the application to talk about. From there, they would break it down into simpler and simpler concepts by identifying the simpler objects that the more complex objects deal with. Is this not a top-down methodology? What makes it not an OO methodology? -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"