Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!hsi!stpstn!cox From: cox@stpstn.UUCP (Brad Cox) Newsgroups: comp.object Subject: Re: The essence of objects... Message-ID: <5404@stpstn.UUCP> Date: 25 Jul 90 21:07:44 GMT References: <1280@media01.UUCP> Reply-To: cox@stpstn.UUCP (Brad Cox) Organization: Stepstone Lines: 77 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: < < In article <1280@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes: < < But I still have problems explaining oops to people who have no < prior experience. When I start talking about inheritance, dynamic < binding they start to gaze and we both feel lost. Why is it so < difficult to explain something which is so advantageous to use and < which feels so right? How do I explain the essence of objects? < < I will give you some of my ideas, with a premise: all we know of OO < programming is OO languages really. I tend to come at this with exactly the opposite premise, that all that mankind really knows about are the tangible objects of everyday experience, and that the programming language community is at least fifty years behind. I'd like to think OO means that we're about to start gaining on them, but the apparent inability of the programming language community to escape its traditional process-centered view of the software universe (Ada, 2167, Cleanroom, C++) and adopt a product-centered universe, based on marketplaces in standard off-the-shelf components (component environments like Smalltalk and Objective-C), makes me fear the reverse. < The second, related, idea is that the principal tool of program design < is decomposition, and that OO programming is that style of programming < where you decompose not by function (FORTRAN), not by datatype and < function (PASCAL), not by module (ADA), but by abstract data type. Mature domains design by decomposition, but implement by *composition*; i.e. they assemble larger solutions from off-the-shelf components; i.e. plumbing systems, bridges, space shuttles. The stockroom of available components are one of the major inputs to the design by decomposition process; the horse, not the cart. < Too bad that many OO practitioners have lost sight of this ultimate < goal, and use fuzzily defined concepts like polymorphism or dynamic < binding or inheritance (which are merely devices) without reference to < such goal. Dynamic binding is very nearly a *synonom* for what I earlier referred to as composition. Binding is a fuzzy concept only so long as we view programming as a decomposition process, rather than a composition process. Binding is that thing on your boots that transforms you + skiis into skier. Dynamic versus static binding is the difference between doing this at the ski resort as opposed to having your parents do it for you at birth. Run-time versus compile-time is hardly a fuzzy distinction. I agree with respect to inheritance. Sometimes I wish it had never been added to implementation languages, and reserved for where it would be far more appropriate, as a specification/testing technology. < On the weakness side, it is apparent that programs are not just < collections of ADTs, but also of "glue" logic, and that the real < semantics of the program belong to this "glue" logic, which usually is < a graph navigator (interpreter). Where the "glue" logic is prevalent on < the data manipulation, maybe then fucntional decomposition is more < appropriate for example. You're talking about what I call "The sucker trap of object-oriented programming", the notion that OOD means make the nouns objects and the verbs methods. It is far better to do what Smalltalk people call "model/view/controller", and as you seem to be suggesting: make passive objects represent the nouns and active objects the verbs (your "glue"). < it is difficult in most OO schemes to express < control abstraction and semantics that straddle ADT boundaries, i.e. < the "glue" navigational code or driver. No, its not difficult at all. See the active/passive object distinction above. The difficulty is only that so many authors (myself included!) have fallen into the sucker trap and their readers with them. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482