How Not to Design a Dog.
in [OOP]
|
Prev: Funny Videos
Next: Wow
From: throatslasher on 18 Mar 2007 19:31 On Mar 18, 2:35 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > In article <1174236477.153296.311...(a)d57g2000hsg.googlegroups.com>, > > > > > > "throatslasher" <implicit_differentiat...(a)hotmail.com> wrote: > > On Mar 12, 12:21 pm, "Diego" <jose.di...(a)gmail.com> wrote: > > > On Mar 6, 10:28 pm, John Carter <john.car...(a)tait.co.nz> wrote: > > > > > On Tue, 06 Mar 2007 10:43:40 -0800, Diego wrote: > > > > > On Mar 5, 11:44 am, "Nick Keighley" <nick_keighley_nos...(a)hotmail.com> > > > > > wrote: > > > > > >> "If you asked Marconi's for a cat they'd send you a dog with a mod > > > > >> kit." > > > > >> Royal Navy Petty Officer > > > > > > I am sorry, but I could not figure out what the hell are you talking... > > > > > I take it you work for Marconi then? :-) > > > > > Ok, so here is the long version of what I said, but being long, isn't > > > > nearly as funny. > > > > > I'm riffing off the standard english "Tail wags the Dog" illustration of > > > > control gone wrong to illuminate how "Big Balls of Mud" in software arise. > > > > > The correct answer in designing a Dog, of course, is the tail merely needs > > > > to send an "Ouch!" signal to primary control object (brain) and there > > > > after The Right Thing happens. > > > > > However a common anti-pattern in software is to implement requirements > > > > starting from input event, and since creating new software couplings are > > > > "free", to access the control elements directly from the inputs. ie. In > > > > software, the "Tail" module can trivially access the leg control module > > > > and the "Tail" developer can get himself bogged down trying to write a > > > > "make legs run" routine. > > > > > In hardware and Canines connections (wires / nerves) are expensive so > > > > there is a natural conservatism about creating additional coupling. In > > > > software it's just another #include and a name reference so developers > > > > will often gratuitously create additional coupling, since the cost of > > > > doing so is borne in maintenance not development. > > > > > The correct solution is given by the OOD concepts of Single Responsibility > > > > / Data Ownership / Law of Demeter / Tell Don't Ask. > > > > > So now you know the full story, and next time you see someone hugely > > > > violating the Law of Demeter you can briefly and pungently say, "Your tail > > > > is trying to teach the Dog to run." > > > > sounds fine, but how it will fit in a statically typed OO language, > > > like C++? > > > void Brain::receive_signal(BodyPart source, SignalType signal_type, > > double intensity); > > > Function call would be: brain.receive_signal(tail, pain, intensity); > > Bad, not good. The tail has no business knowing, or caring who the > message receiver will be. You can choose to name the 'brain' variable whatever you wish, and nothing is stopping you from using a more generic type than brain. The question was how this event could be communicated in static type languages. > The tail needs to simply tell any and all who have expressed > interest that it is in pain. Any and all? I believe the moral of the OP is that the tail should be notifying only one client that it is in pain. Would you really design your tail class with the ability to notify many clients of this event?
From: Daniel T. on 19 Mar 2007 09:27 "throatslasher" <implicit_differentiation(a)hotmail.com> wrote: > > Bad, not good. The tail has no business knowing, or caring who the > > message receiver will be. > > You can choose to name the 'brain' variable whatever you wish, and > nothing is stopping you from using a more generic type than brain. > The question was how this event could be communicated in static type > languages. The classic observer pattern is the way to do it. > > The tail needs to simply tell any and all who have expressed > > interest that it is in pain. > > Any and all? I believe the moral of the OP is that the tail should be > notifying only one client that it is in pain. Would you really design > your tail class with the ability to notify many clients of this event? Conceptually, yes. I would not necessarily put in the actual code, but I would leave the possibility open. When the bumble-bee does his honey dance, does he care who watches? Does he control what they do with the information he presents them?
From: Dmitry A. Kazakov on 19 Mar 2007 10:05 On Mon, 19 Mar 2007 13:27:24 GMT, Daniel T. wrote: > When the bumble-bee does his honey dance, does he care who watches? Yes, it is genetically programmed to care. Queens whose bees danced for bee-eaters were unable to pass their genes further. > Does > he control what they do with the information he presents them? Sure there is a feedback. But even if there where none, the very question cannot be answered. Does CPU care about typing? In what sense? It just exists, the same way as the atoms which a bee consists of do. Computational environment /= the program it executes. Neither CPU nor a bee control what they do, but the effect [in our mental models] is such as if they did. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: throatslasher on 19 Mar 2007 11:17 On Mar 19, 5:27 am, "Daniel T." <danie...(a)earthlink.net> wrote: > "throatslasher" <implicit_differentiat...(a)hotmail.com> wrote: > > > Bad, not good. The tail has no business knowing, or caring who the > > > message receiver will be. > > > You can choose to name the 'brain' variable whatever you wish, and > > nothing is stopping you from using a more generic type than brain. > > The question was how this event could be communicated in static type > > languages. > > The classic observer pattern is the way to do it. How is this different from my response, aside from multiple observers? > > > > The tail needs to simply tell any and all who have expressed > > > interest that it is in pain. > > > Any and all? I believe the moral of the OP is that the tail should be > > notifying only one client that it is in pain. Would you really design > > your tail class with the ability to notify many clients of this event? > > Conceptually, yes. I would not necessarily put in the actual code, but I > would leave the possibility open. Then don't tell me my response is "bad, not good." The guy asked a simple question about how something would be done in C++, not what alternative code you might have in your head after writing the real code. You can *always* complicate your design a bit more by leaving another possibility open. > When the bumble-bee does his honey dance, does he care who watches? Does > he control what they do with the information he presents them? I can understand why a bee would have multiple observers; I was talking about a dog's tail.
From: Daniel T. on 19 Mar 2007 11:32
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: > On Mon, 19 Mar 2007 13:27:24 GMT, Daniel T. wrote: > > > When the bumble-bee does his honey dance, does he care who watches? > > Yes, it is genetically programmed to care. Queens whose bees danced for > bee-eaters were unable to pass their genes further. He is genetically programmed to dance, but to care? I think you ascribe too much intelligence there. The point remains though. In an OO environment, objects must be thought of as semi-intelligent and semiautonomous. The dog example brings to mind an unintelligent machine (the tail) being controlled by a "god object" the brain. That sort of centralization is exactly what OO tries to avoid. An OO system should not be thought of as a body with a controller, and appendages. Instead a good OO system should be thought of as a community of workers. |