Path: utzoo!yunexus!unicus!craig From: craig@unicus.UUCP (Craig D. Hubley) Newsgroups: comp.lang.c++ Subject: Re: Hey Bjarne! Some Questions Message-ID: <2257@unicus.UUCP> Date: 25 Feb 88 00:05:29 GMT Article-I.D.: unicus.2257 Posted: Wed Feb 24 19:05:29 1988 References: <1271@devvax.JPL.NASA.GOV> <7682@alice.UUCP> Reply-To: craig@Unicus.COM (Craig D. Hubley) Organization: Unicus Software Inc., Toronto, Ont. Lines: 133 > > 2) OO Design Tools > > a) Are there any? It seems that it has taken about 15 years > > ... > I don't know of any worthy of the name; and yes I think > structured design is obsolete in the context of C++ > because of (most) structured design deemphasizes types > and lack ways of expressing inheritance. The only `OO Design tool' currently in use that `object people' might recognize as such would be a prototype, written in an O-O language, perhaps on top of a Lisp dialect, that at least `stubs' the functions required, and specifies the inheritance lattice, etc. Modifications to the detailed design specification can then be carried out on this dynamic model rather than the more static compiled implementation, defining the static inheritance lattice only from the stabilized prototype, whose original hacked-up code should always be burned to beyond reconstruction. This is, of course, just rapid prototyping, which is always appropriate to attack ill-defined problems. And the further we go, the more ill-defined the problems seem to get... > > a) Will C++ support multiple inheritance? > > It already does. The only snag is that getting it out of > the lab/AT&T in the form of a new release takes time. I hope it comes soon. There are *some* people that think that object languages without multiple inheritance are nothing but a harmful nuisance that encourages people to hide dependencies under a `modular' structure, since the explicit mechanism is inadequate to express complex relationships. At the very least, a language lacking such tools should allow access to conventional modules (that is, functions) to keep the mess to a minimum. Thankfully, C++ and the various Lisp object languages all do this, though I don't know if Smalltalk does... > > b) Given the existing lack of this capability, how does one > > effect the same concentration of responsibility within > > a project requiring a large number of tools? Carefully, and documenting yourself well... > However, C++ isn't Lisp (and Lisp isn't C++) so you should > not expect MI in the context of C++ to have exactly the > same properties (good and bad) as MI in the context of > a particular Lisp dialect. It might also be worth mentioning > that MI isn't a panacea either. For any MI scheme I can > think of I can concoct a real example that allows me to > say ``See, the dirt is still there!'' What about the MI scheme used in LOOPS, that specifies a fixed order of executing super (that is, inherited) methods, and allows the method to call on its super-methods explicitly, or specify the order in the class description ? The only dirt that I ever found in that was that sometimes a subclass would have to explicitly call on its supers by name, but since it relied heavily on specific inheritances anyway... If a specialized method requires a substantially different order of execution than its unspecialized parent, argument could be made for it being a different method in disguise... all the same, LOOPS could do it, and I would like to know where the dirt was hiding... ? (Aha! There it is, in the LISP!!! ---> (()()(((*)()):-)))(())) > > 4) Complex Algorithms > > > > Object oriented design maps well into problem domains with a large number > > of complex objects, but where the algorithm describing the interactions > > of objects is simple. For example, say you are simulating a football team. > > The players are naturally identified as objects. But what about the game > > plan? This plan is very complex. How is the plan itself broken down into > > objects, given the possibly extensive context dependancies of various > > options within the game plan? "Pass if this and that and the other...." It might be more appropriate to say that it maps easily into such domains, and with more difficulty into those with more complex interactions. But Kay's Maxim `Simple things should be simple. Difficult things should be possible.', still holds. Object languages are, as Bjarne says, no panacea. With that in mind: Perhaps a game plan is an explicit & active context. This is a fertile ground for multiple inheritance. Imagine that each player has his own strengths and weaknesses, but that his `intelligent' methods evaluate the situation based upon methods and variables inherited from the game plan currently used. That is, his `Pass' method calls `HoldOn?' and `WhoTo?', both of which are inherited from the game plan. In this case, GamePlan.HoldOn must consult it's `view of the world' to see if it is desirable that that particular player holds onto the ball. If not, it says `No', and GamePlan.WhoTo provides a list of players, in order of desirability, to whom the ball should be passed. The player then consults his own view of the field to decide who is the most likely candidate for a pass, possibly calling on HoldOn and WhoTo again as the situation changes. Different game plans can be substituted without affecting this procedure, or interposing artificial classes between Player and its subclass Linebacker, for instance. Just a thought. Think about doing it *without* MI, though... > > Note that structured design also falls down on complex context dependancies. > > How does OOD help? > ... > There really isn't that many ways of coping with complexity. Roughly, > you can find a fundamentally simpler way of performing a task or you > can apply a divide and conquer strategy. The former approach ought to > be language independent and any decent language ought to have the > facilities for expressing the simpler solution - if it doesn't it may > become inordinately hard even to think of the simpler solution. I have always thought of Object design as the logical next step after Structured design. In the latter, we specify a hierarchical *functional* relationship, keeping functions and data structures as modular as possible. In the former, we specify a hierarchical relationship for *function AND data*, recognizing their fundamental interconnections and making them explicit, making it *easier* to keep function and data structures as modular as possible, with the added benefit of a more flexible interface that more adequately expresses how people think of problems. A big win, overall. > The latter approach requires ways for expressing locality/modularity > and for expressing dependencies. OOD and OOP can help you IF there > is a way of encapsulating part of a system so that it has a clean > interface (hide the dirt - make it an implementation detail) and > especially IF there is a hierarchial relationship between the concepts > involved. Again, a nice modularized and hierarchically structured Pretty much anything can be *characterized* with a hierarchical structure, whether that structure is functionally meaningful or not is another matter... talk to an anthropologist about this one... > > Comment one and all! > I'll second that. Done (the one, anyway). Craig Hubley, Unicus Corporation, Toronto, Ont. craig@Unicus.COM (Internet) {uunet!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp) mnetor!unicus!craig@uunet.uu.net (dumb arpa)