Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!uc!shamash!tank!gargoyle!ddsw1!olsa99!oct1!proxima!lucio From: lucio@proxima.UUCP (Lucio de Re) Newsgroups: comp.lang.c++ Subject: Re: object-oriented design (was Re: are 'friend's really necessary ??) Message-ID: <1281@proxima.UUCP> Date: 9 Apr 90 22:52:57 GMT References: <169@pollux.kulcs.uucp> <10589@alice.UUCP> <1082@targon.UUCP> <1110@targon.UUCP> <4593@pegasus.ATT.COM> <1114@targon.UUCP> Reply-To: lucio@proxima.UUCP (Lucio de Re) Organization: FLAGSHIP Wide Area Networks - Cape Town Lines: 73 In article <1114@targon.UUCP> ruud@targon.UUCP (Ruud Harmsen) writes: >In article <4593@pegasus.ATT.COM> psrc@pegasus.ATT.COM (Paul S. R. Chisholm) writes: >I wrote: >>> In theory, this is correct. But if in practice, in a particular >>> application 70 to 80 percent *has* to mess with a class A, then you can't >>> do very much limiting. >> >>Exactly right. That's the signature of a poor design. You have to >>*try*, hard, to hide the implementation of your data types. Twenty >>years of programming have taught me that it's worth the effort. Lots >>of other believe it, too. I am one of those believers. Fortunately for us programmers, the reality we have to contend with is seldom of such a nature that abstraction cannot reduce it to the point where classes provide an adequate description. Even Modula 2, without the object oriented abstractions did a formidable job of data hiding and at the same time simplified coding. I appreciate that it is difficult to isolate individual classes at a glance in a great many instances, and I presume no proof is available to demonstrate that a class concept is general enough to cover all instances of programmable tasks (wow, what a mouthful!); I also think that Paul Chisholm used excessively strong terminology in "the signature of a poor design," but his point is valid, better design will produce one or more classes more faithfully modelling the system underscrutiny (I must stop this pompousness, please no flames!). Remember that inheritance, and particularly multiple inheritance, with its greater complexity, ought to extend the power of object oriented design to (hopefully) all programmable instances. It probably doesn't, as there is an infinite amount of complexity out there and (I guess) a finite number of constructs programmers can design, but somebody better versed in mathematical theory than I should attempt a proof in either direction while we programmers continue with our heuristic approach to problem solving. >I really hope you, and the other believers, are right. But I'm not >convinced. I don't think the trouble is in bad design, I think it's >in the nature of things. The world simply isn't simple, cannot be >forced into strict hierarchical models ... I suppose the proof of the pudding ... I contend that (a) you are correct in believing that hierarchies are not sufficient to represent all possible conditions, but (b) the problems that programmers face in (say) 90% of instances have solutions that can be decomposed into hierarchical representations, and (c) that careful analysis and possi- bly a fair amount of thumb-sucking guesswork can bring whatever the initial percentage might be a lot closer to a 100% of all USEFUL applications. My fear, and perhaps it is Paul's fear as well, is that because the object-oriented model is not always immediately obvious, the program- mer may overlook it and use a (currently) more traditional approach. I suggest that when a problem that looks as if it does not lend itself to decomposition into object oriented classes occurs, it should be submitted for scrutiny on this forum. I believe that the field is young enough for all of us to have something to learn from the experiences of others, while at the same time the presenter should weigh the (possible) embarrassment of having the obvious pointed out to him/her (and I do not exclude the possibility that the forum may not succeed in the quest for a suitable representation, to the embarrassment of the forum in its entirity) against the possibility that an elegant solution may simplify immediate programming (unlikely as we all have deadlines to work to), and certainly future maintenance. ---------------------------------------------------------------------- I used to design nuclear reactors and you should see the code that engineers and scientists come up with. Yuuuck! Spaghetti everywhere. -------------------------------------------------- (Kenneth L Moore) - Lucio de Re ...uunet!ddsw1!olsa99!proxima!lucio -------------------------------------------------------- lucio@proxima Disclaimer: He must have been joking!