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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public From: Tim Ottinger Subject: Re: What is wrong with OO ? Date: 1996/12/05 Message-ID: <32A6CF52.590@dave-world.net> X-Deja-AN: 202494119 references: <32A4659D.347A@shef.ac.uk> <584v8t$fip@pixel.jtec.com.au> content-type: text/plain; charset=us-ascii mime-version: 1.0 reply-to: tottinge@dave-world.net newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-12-05T00:00:00+00:00 List-Id: Matthew Gream wrote (And all in all, a thoughtful posting): [in response to question:] > > 2 - Resilience to change, i.e. low software maintenance and evolution cost > > How flexible is the software? This has a lot to do with architecture: > "if you don't get the architecture right up front, you may as well pack > up and go home" [quote made by a fellow engineer]. The architecture in > many ways predicts what will happen to the software over its > lifecycle. If you don't get this right, you will need to change the > architecture: this is usually not a trivial task. This is not exclusively > an OO issue though. By the way, while this is "essentially" right, there are plenty of cases where people did not build the correct architecture the first time out. In fact, many of us will tell you that it's nigh impossible to build it right the first time out if the software project is interesting enough. The iterative incremental model ain't perfect, but using short cycles and daring to revisit can cover an awful lot of design sins. If you commit to an architecture, then you're probably stuck. I propose the motto "design by distrust!". If the work is suitably isolated from the physical and business requirements, then you can reliably insulate yourself from those things you don't believe will be invariant, even if you don't know which direction they'll go in. Of course, this *is* your next point, but I wanted to stress that it's not a top-down thing, and the process is not completely unforgiving. Otherwise, we'd be better off outside of OO for large projects. The architecture thing, even the business model, can be essentially right and correctably wrong, and sometimes it's a close to perfection as you'll get. Especially early on in a project. > OO includes inheritence. This promotes generalisation -- factoring out > commonalities -- which reduces dependencies. Reduction in dependencies > makes maintenance and evolution more predictable and cheaper. It is > perhaps predictability that is more important than anything, better to > correctly assess that all the costs are high up front, before starting, > rather than finding out later. Design by distrust! Estimate by distrust! > > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ? > > or is it the deficiency in the development tools used like C++ or Smalltalk ? > > or is it the steep difference in thinking between the traditional and OO schools ? > > or is it related with the difficulty of object classification ? > > or is it because of vast legacy systems done using the traditional methods ? > > or is a combination of many other factors...? > > All of these would seem to be problems from my, limited, experience. The > thinking "mindset" is perhaps one of the most important. To begin with, I don't accept the idea that there is a "problem". I'll talk about that in a second. Secondly, I think that the difference in thinking between OO and structured is a matter of breaking mental habits, not the deep and nearly incrossible chasm people make it out to be. We have people who jump from COBOL to C++ and OO in one great leap. We have a number of people who came from procedural 4GLs to OO. It happens very frequently, maybe every week or every day all over the world with thousands and thousands of people. A lot of the "problem" is with organizations. If they've been successful to any degree with other methods (including brute force) then they are unlikely to "mess with the formula" by going into OO. A lot of people still use Fortranm, COBOL, RPG, etc., successfully - untouched by the Client/Server revolution, CASE, even RDBMS. No person or company is obliged to stay "technically current", and so many will not. And they might do fine at it. The fact of the matter is that OO is a change in management and project planning as much as anything else, and a lot of managers aren't too keen on having their world ripped out from under them. That's just an education thing. It'll come in time, but the focus on managing OO is fairly recent in the scheme of things. There's an underlying myth of the question which was originally asked. "If method A is good, then why does anybody do anything else", or "If some people don't use A, then it must not be very good". If I asked "If software is a good career, then why do some people still raise crops?" you might laugh. Software is not for every- body. For that matter, you know that managers and financial people make more money than programmers, so whats wrong with you that you don't go into management instead? Well, maybe programming is fine for you. Maybe that money benefit isn't all that important to you. Does that mean that managers *don't* make more money? Likewise OO. It's not a winner-take-all battle with the rest of the DP world. It doesn't have to be popular, and it doesn't have to be used exclusively by all software companies in order to work. It's just a set of mental tools you can use if you want the benefits it can provide. Some people are gung-ho, some are skeptical, some don't care. And they have that right. -- Tim ******************************************************************** In some sense, all of life is design. The way we pick our friends, the way we plant a garden, and the way we choose software is all design. Sometimes we do things by habit, other times by carefully weighing the pros and cons, and sometimes we make experiments. -- Ralph Johnson --