How Not to Design a Dog.
in [OOP]
|
Prev: Funny Videos
Next: Wow
From: Gabriel Gonzalez on 7 Mar 2007 07:19 On Mar 5, 5:04 am, John Carter <john.car...(a)tait.co.nz> wrote: > So the Dog has been built and a new requirement comes in... > > If you stand on the dogs tail, it must yelp and scrabble away. > > So what does Joe Average Coder do? > > Open up the Tail.cpp, #include "AudioOutput.hpp" > wire Dog to Yelp when the tail has been stood on. > > He then #include's "LegControl.hpp" and begins to try to work out how the > Tail can get the Dog to run... LOL!
From: AndyW on 7 Mar 2007 18:25 On Wed, 07 Mar 2007 14:28:48 +1300, John Carter <john.carter(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." lol. Sometimes getting the tail to wag the dog can be all the customer wanted (although a bit daft imho). Being an OO person (and an odd one at that), my solution is to climb over the fence and look at my own grass from the other side. One realises that all mammals use the same design based on a central nervous system, are warm blooded, have a backbone etc. So for the OO approach I would simply create a mammal with a central nervous system that has a set of pain receptors (input controls) and emotional response unit (output control). The Dog part is merely just a custom wrapper (UI) for that solution where the tail is connected to the output control. So I guess, its really a mammal with a dog mod kit applied :) Ask for a dolphin and you'd likely get the same solution but with the dolphin mod kit. ---------------- AndyW, Mercenary Software Developer
From: Diego on 12 Mar 2007 16:21 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++? how will the tail pass parameters to the brain? how to avoid the brain not becoming a god object? do we have to implement a message system? (or a psychotic SQL from topmind...) sorry, but I always get scared of rule of thumbs... Diego
From: throatslasher on 18 Mar 2007 12:47 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); > how will the tail pass parameters to the brain? how to avoid the brain > not becoming a god object? Ehhhhh......... > do we have to implement a message system? (or a psychotic SQL from > topmind...) > > sorry, but I always get scared of rule of thumbs... Got your thumb right here... > > Diego-
From: Daniel T. on 18 Mar 2007 18:35
In article <1174236477.153296.311770(a)d57g2000hsg.googlegroups.com>, "throatslasher" <implicit_differentiation(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. The tail needs to simply tell any and all who have expressed interest that it is in pain. I think the problem is in your example (a dog.) A better example would be, for instance, a bee hive or ant colony where each object is a bee or ant. A semi-intelligent, semi-autonomous, entity that receives signals from its environment and decides what to do with them, while sending signals to any and all that care to listen. An single dog is not a good metaphor for an OO solution, because each part is not at all autonomous. |