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,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: ell@access2.digex.net (Ell) Subject: Re: What is wrong with OO ? Date: 1996/12/05 Message-ID: <585fep$ero@news3.digex.net>#1/1 X-Deja-AN: 202438722 organization: The Universe followup-to: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-05T00:00:00+00:00 List-Id: Bill Gooch (bill@iconcomp.com) wrote: : Ahmed wrote: : > : > Actually immediat reuse can be acheived to a certain extent with : > the traditional structural methods if they adopted a good design : A key phrase here is "to a certain extent." OO allows : more effective reuse (less redundancy, less copy-and-edit) : than alternatives. : > What I understand from this is that it is not convinient to reuse : > objects of other applications because they are built with different : > perspectives.. : I think "not convenient" is a bit of an understatement - : "very difficult" might typically be more accurate. In my experience, and observations, it is not "cross application" reuse of classes/objects that is a problem as much as it is "cross environment" reuse of classes/objects. Especially wrt physical design reuse. I.e. getting classes/objects to physically work across different environments is difficult indeed. : Two different automobile designs rarely share any : compatible parts (except those which are industry- : standardized, like oil filters), unless the designers : worked together with that goal in mind. : > Every programmer is tackling the same problem using his own perception : > of the problem..his own abstraction.. : Yes, and the alternative is?... Relying on domain experts for fundamental application semantics and as well relying on domain experts to determine implementation necessaries for application use. Relying on domain experts for implementation of Use Cases. : > The concept behind OO is that it deals with peices of software as : > tangible objects exactly as real world works.. Yes! Well not *exactly* as the real world operates, but in a way that utilizes, and is anchored upon "real world" domain abstractions, patterns, and semantics. : Not at all. "How the real world works" is by no means : obvious or well understood ("real world" in itself is : an exceedingly vague term), and you'd need to provide : some definitions of these things, as well as evidence : to support the above assertion. If we grasp, as in you have alluded to in many of your previous posts that development should start with understanding domain abstractions and relationships how is that different from basing project analysis and architecture on "tangible objects exactly as the real world operates". : > however in real world : > every object has a clear behaviour and perception by every body, : Not in the slightest. The perception of object behavior ranges in various cases between being very clear to all to only discernable to a handful. : > while in the OO software each object has a behaviour according to : > the perception of his designer..!! : Sometimes. The designer probably hopes it does. Yes, the pragmatists and empiricists hope that they can do whatever they want to analysis and physical design based on their narrow inclinations. In actuality there is an objective reality (or at the very least objective human conception) behind what goes on in an application and its domain that developers should attempt to model as closely as possible. : > The problem is that many organization avoid moving toword OO because : > the transfter cost to OO ( training programmers / organization change in : > standards / new tools / new analysis and design methods / legacy : > system/ etc. ) are much higher than the benifit of "immediate reuse" : OK - why is this a problem? Because "immediate reuse" should not be the only, or main criteria by which an organization adopts one development paradigm or another (e.g. OO vs. others), as I see it. : > I am not saying that we should move to the traditional structural methods : > No, I have suffered enough from it, I actually like OO because of its : > strong features..But I want to know why it is not moving so fast.. Seems pretty fast to me. From what I read in most literature in the computer field, or area, OO is de rigeur - virtually the only thing being talked about as a development paradigm. That is even in the mainframe world. : Patience is a virtue. Rapid growth and early acceptance : can lead to backlash and equally rapid decline. Excelsior! As quickly as possible! OO has at least nearly 30 years of growth. Elliott