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.9 required=5.0 tests=BAYES_00, T_FILL_THIS_FORM_SHORT autolearn=ham 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: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: matthewg@jtec.com.au (Matthew Gream) Subject: Re: What is wrong with OO ? Date: 1996/12/04 Message-ID: <584v8t$fip@pixel.jtec.com.au> X-Deja-AN: 202474461 references: <32A4659D.347A@shef.ac.uk> followup-to: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng organization: Jtec Pty Limited. Sydney, Australia newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-04T00:00:00+00:00 List-Id: Hi Ahmed, On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed (ACQ95AA@shef.ac.uk) wrote: > Object Oriented Technology came with quite promising claims that if > achieved can benefit the software development companies and > organisations millions of pounds. OO is no different from many other technologies. It comes with many promises, and it can fulfill these if used in the right situations in the right way. It is not a panacea, which is not a new or surprising statement. When you consider "Object Oriented Technology", you must also consider Domain Analysis, Architecture, Patterns and other lifecycle goodies which are not inherently Object Oriented, but seem to be a necessary requirement for successful OO benefits. > Some of these claims for instance > 1 - high reusability of objects and frameworks This can be achieved, but it requires discipline, investment and experience. Discpline to work hard towards reusability, and to maintain that reusability (though evolution). Investment in terms of the effort involved to establish generic solutions (generic solutions are generally [:-)] much harder than specific solutions). Experience to make the correct decisions when constructing re-usable items (to have some degree of visibility). > 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. 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. There are also CASE tools, which make evolution and maintenance much easier and achievable (they also keep you focused at a higher level of logic). Having a CASE tool take care of menial details (file organisation, includes, class definitions, method stubs, etc) and take over some of the verification roles (use cases and scenarios) is very important. Though, CASE tools are not inherently an OO thing. There are probably many more items you can mention here as well. > 3 - Easier understanding by the user and Natural transition between the analysis, design, > implementation because they all use tangible perceived objects. The transition is definitely a good thing. Being able to iteratively build software is much more predictable as well. What you've said seems to be much easier to say that to do, from the experience I've seen around me. Getting the right architecture and objects up front requires experience (and therefore, knowledge). It also requires an appropriate balance between the actual system requirements, the system domain and other domains. This requires time and experience. > However the reality is not so bright as claimed..if so, then nobody today thought to develop a > software on the traditional structural methods... > My question is what is wrong with OO ? why it did not achieved its targets yet.? > What are the main obstacles? I would say that it is slowely acheiving its targets and that there are three main inter-related obstacles: time, experience and collaboration. We need more of these to help the overall feedback loop. > 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. > I know that giving a precise answer is very difficult for such a complex question, but I like to > hear the comments of people working at the feild and who suffered from many difficulties.. > I would really appreciate any participation, response or even leading to a good reference , > and would be very grateful if the opinions are supported by some evidences... You want evidence ? I need more experience :-). Please excuse my bias towards architecture in the above as well, I think that architecture and organisation are very important. Architecture is everywhere, from the big to the small (in the software, in the process, in the people, in the organisation, etc). Most of the software problems I have encountered can be traced back to architectural issues of one form or another. Cheers, Matthew. -- Email: Matthew.Gream@Jtec.com.au Phone: (02) 390-0194 Fax: (02) 364-0055 Post: Jtec (R&D) Pty Ltd. Unit 3, 118-122 Bowden St. Meadowbank NSW 2114.