the gulf between bog-standard and actually good OO?
in [OOP]
|
Prev: Call for Paper The International Journal of Computer Science (IJCS)
Next: CFP with Extended Deadline of Mar. 21, 2010: The 2010 International Conference on Computer Graphics and Virtual Reality (CGVR'10), USA, July 2010
From: Daniel T. on 15 Mar 2010 11:38 Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: > On 7 Mar, 17:15, "Daniel T." <danie...(a)earthlink.net> wrote: > > "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > > On Sun, 07 Mar 2010 10:15:40 -0500, Daniel T. wrote: > > > > "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > > > > On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote: > > > > > > > Here is a simple quote that might help. "In OO programs, objects > > > > > > tend to tell other objects what happened, instead of telling > > > > > > them what to do." > > > > > > > Well, I see no difference if action is a simple function of state. > > > > > To tell the object "do X" is same as to tell it "we are in the > > > > > state, where you will do X." > > > > > > The above misses the point. In OO you don't tell the object "we are > > > > in the state where you will do X," you tell the object "we are in > > > > this state"; what the object does with that information is its > > > > business. > > > > > The point is that if the behavior is a simple function of state, then > > > both views are equivalent. In a well-designed program it is so. > > > > > Moreover, I claim that the programs where there is a substantial > > > difference between them are poorly designed. > > > > > It is no matter if you tell the car to accelerate by pushing the gas > > > pedal, or else it accelerates by itself because the pedal is on the > > > car's floor. You can view it either way. The problem is when you are > > > in a Toyota car, which interprets the pedal position in an unexpected > > > (complex) way. Such cars are called back. > > > > Your still thinking procedurally, not in an OO fashion. Let me go a > > little more low level and technical. Hopefully, I won't loose the OP in > > the process. > > > > A procedural function has a specific postcondition that it must fulfill > > in order to be considered correct, the caller is guaranteed that the > > postcondition will hold true and can operate under that assumption. In a > > very real sense, the caller is using the function to *force* the > > postcondition to become true. The caller is in control in this > > situation. Putting such a function in a class doesn't change this basic > > characteristic (container.insert(x) is not an OO function, but a > > procedural one precisely for this reason.) A vast majority of code in > > any program will consist of such procedures. > > even OO programs? This isn't a trick question, I was finding it hard > to express all the functions/methods in my programs in non-imperitive > terms. > > Channel::watch() > when_something_happens_on_socket > raw_msg = socket.get_raw_msg () > msg = make_msg (raw_msg) > message_handler.message_arrived (msg) > > so we've told the message_handler there's a message but we havn't told > him (not should we care) what he does with it. The other fucntions in > the above fragment look rather imperitive "get a message!" "parse a > message!" Programming in an OO style is extremely flexible and not always appropriate. Most of the code in even a Smalltalk program is procedural (do this, then do that.)
From: raould on 8 Apr 2010 18:21 hi, as a follow-up to my original question, i think i'm learning a lot from this artima dicussion: http://www.artima.com/forums/flat.jsp?forum=270&thread=287546. thanks to those on it. sincerely.
From: Nick Keighley on 12 Apr 2010 05:58 On 5 Mar, 16:09, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote: > > raould <rao...(a)gmail.com> wrote: > >> On Mar 4, 1:21 am, Nilone <rea...(a)gmail.com> wrote: > > >>> > * the old hierarchical breakdown of procedures in structured > >>> > programming vs. the peer relationship that should be used in oo. i > >>> > don't even know how to visualize these, it would be great to see a > >>> > small toy code example of the difference. > > >>> The theoretical models will help you visualize. I don't know what > >>> code example would illustrate the issues well. Post something you're > >>> familiar with, and we can discuss and criticize possible designs. > >>> Distrust animal and vehicle based examples. > > >> unfortunately i'm so not understanding the topic yet that i don't even > >> have an example i could post. do you even have a problem domain you'd like to discuss? > >> by visualize i meant have an example of > >> it i can work through in my head. like, i can work through an example > >> of single dispatch java vs. multiple dispatch in my head since i've > >> written that code enough times. > > >> my vague sense of it so far comes from reading Lahman's blog, that it > >> is in particular about control-flow, rather than about, say, type > >> hierarchy. which i can in some ways i think i understand (like, many > >> conditional tests can be re-coded into the object hierarchy, to > >> replace the conditional with polymorphism) but i suspect i'm not fully > >> groking it. > > > Here is a simple quote that might help. "In OO programs, objects tend to > > tell other objects what happened, instead of telling them what to do." > > Well, I see no difference if action is a simple function of state. To tell > the object "do X" is same as to tell it "we are in the state, where you > will do X." consider "a new message has arrived" rather than "process newly arrived message" > There could be a difference in an asynchronous system, or when > participants had some intelligence making their own decisions in same > states, but neither is typical to a well-designed OO program. The design > principles are rather opposite: > > 1. Make it deterministic and testable > 2. Keep objects behaviour simple > > etc. > > > If you want to visualize how objects in a good OO program work, study > > how ants in a colony work together to get things done. Contrary to > > popular opinion, the Queen does not tell each ant what it should do... > > It would be a very bad idea to design a program as an ant colony: > > 1. Ants designed same (worker, fighter, queen), objects are not sounds like worker, fighter etc are classes! > 2. They act stochastically, programs are desired to be predictable > 3. They are wasting a huge amount of resources (computational and time) > 4. They communicate in an extremely inefficient, slow and unreliable way > 5. They lack memory and any ability to learn it simply seems an unhelpful analogy (but then perhaps I'm not a very good OO programmer...). Boss: we'd like you to design a network management system Programmer: ok, now imagine the network was managed by a bunch of ants...
From: Dmitry A. Kazakov on 12 Apr 2010 06:25 On Mon, 12 Apr 2010 02:58:18 -0700 (PDT), Nick Keighley wrote: > On 5 Mar, 16:09, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> It would be a very bad idea to design a program as an ant colony: >> >> 1. Ants designed same (worker, fighter, queen), objects are not > > sounds like worker, fighter etc are classes! > >> 2. They act stochastically, programs are desired to be predictable >> 3. They are wasting a huge amount of resources (computational and time) >> 4. They communicate in an extremely inefficient, slow and unreliable way >> 5. They lack memory and any ability to learn > > it simply seems an unhelpful analogy (but then perhaps I'm not a very > good OO programmer...). > > Boss: we'd like you to design a network management system > Programmer: ok, now imagine the network was managed by a bunch of > ants... My first reaction to that was: heck, that must be the Hex! Guys must be reading too much of Terry Pratchett! (:-)) http://en.wikipedia.org/wiki/Hex_%28Discworld%29 -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Daniel T. on 12 Apr 2010 07:56
Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: > it simply seems an unhelpful analogy (but then perhaps I'm not a very > good OO programmer...). > > Boss: we'd like you to design a network management system > Programmer: ok, now imagine the network was managed by a bunch of > ants... Well it worked for me. I noticed in something I read recently from Alan Kay where he referred to OO systems working more like biological systems. (Such as an Ant colony perhaps?) - I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful). <http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en> OK, he wasn't referring to systems, but cells. I know more about ants than I do cells though, so I think of ants. The point is, there is no boss ant, no ant ever tells another ant what to do. |