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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Real OO Date: 1996/04/30 Message-ID: #1/1 X-Deja-AN: 152238499 references: organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-30T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >The world of operations and types can be though of as a matrix: > > type 1 type 2 type 3 ... > > op1 x - x > op2 - x - > op3 x x - > ... > >Roughtly speaking, the OO approach organizes by columns, which is often >fine, but the operation organization by rows also often makes sense. I wonder if it would be possible to design a language, or a tool, that is capable of showing both the rows and the columns, depending on which I want to look at right now, or maybe there's some way of expressing both at the same time. Usually, the by-column (OO) organization is better, but as Robert points out, not always. And sometimes, after I've got a bunch of OO-ish code, I find myself searching for all occurrences of a given "method" -- that is, sometimes I want to look at the rows. Look at "Design Pattern", by Gamma et al. There are many design patterns in there where operations are organized by Robert's rows -- in some cases, they advocate creating classes/objects that really represent those rows, collecting all operations of the same kind together, rather than attaching the operations to the classes they operate on. Of course, their examples are all in Smalltalk and C++, so they create "extra" classes/objects to represent these rows -- and conceptually, these objects are not really objects in the normal OO sense. In Ada, some of those design patterns would be written using packages rather than classes. >P.S. spaghetti code doesn't just mean code you don't like. It is a rather >specific term used to described the non-nested chaotic control structures >caused by undisciplined use of gotos or equivalent transfers of control. >I think it is useful to keep this sense. Well, words change their meaning, and get additional meanings. After all, think about an Italian chef admonishing us that "spaghetti" is really a kind of pasta, and the term shouldn't be evilly hijacked to talk about gotos. I've seen the term "spaghetti" used quite a few times to describe messy multiple inheritance patterns. - Bob