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: Dmitry A. Kazakov on 7 Mar 2010 10:53 On Sun, 07 Mar 2010 10:15:40 -0500, Daniel T. wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: >> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote: >>> raould <raould(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. 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." > > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Daniel T. on 7 Mar 2010 12:15 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: > On Sun, 07 Mar 2010 10:15:40 -0500, Daniel T. wrote: > > "Dmitry A. Kazakov" <mailbox(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. An OO function's only postcondition guarantee is that it will return in a finite amount of time. If "car.gasPedalPressed()" were an OO function, then there would be *no* guarantee that the car would begin accelerating when the function was called. If the car started accelerating, it would be because the *car* wanted to, not because the caller wanted it to. The ant analogy comes in here. One ant never tells another ant what to do, ants tell others what they have been doing, and each ant takes the information that comes in and decides what to do based on the information.
From: Dmitry A. Kazakov on 7 Mar 2010 12:51 On Sun, 07 Mar 2010 12:15:39 -0500, Daniel T. wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: >> On Sun, 07 Mar 2010 10:15:40 -0500, Daniel T. wrote: >>> "Dmitry A. Kazakov" <mailbox(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. I do not. The proper word is "imperative." The opposite is "declarative." Yes, I don't trust declarative approaches, but neither does OO since most OOPLs are imperative, for a reason of course. > 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. Here you refer to the procedural decomposition. In OO procedures are mere vehicle to define operations of the objects. OO decomposition goes into abstract types and instances of (objects). That does not render procedures non existent. > An OO function's only postcondition guarantee is that it will return in > a finite amount of time. Where is the behavior? > If "car.gasPedalPressed()" were an OO function, then there would be *no* > guarantee that the car would begin accelerating when the function was > called. If the car started accelerating, it would be because the *car* > wanted to, not because the caller wanted it to. How do you determine who wanted it, and why is it relevant? The car that does not accelerate when the pedal is pressed is not broken, it just does not want to accelerate? Come on, it is broken exactly because it does not want to obey orders! > The ant analogy comes in here. One ant never tells another ant what to > do, ants tell others what they have been doing, and each ant takes the > information that comes in and decides what to do based on the > information. These are just vessel words. When an ant leaves a scent trace it tells other ants to follow. You can say that they follow the trace because they feel it, or because they were told to do so. It is just same. There is no physical experiment to show any difference. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Ed on 7 Mar 2010 13:47 On 7 mar, 18:15, "Daniel T." <danie...(a)earthlink.net> wrote: > > An OO function's only postcondition guarantee is that it will return in > a finite amount of time. > Fascinating. Daniel, do you have any links to further reading on this point (my googling's skills have failed me)? Thanks, Ed.
From: Daniel T. on 7 Mar 2010 17:27
Ed <iamfractal(a)hotmail.com> wrote: > On 7 mar, 18:15, "Daniel T." <danie...(a)earthlink.net> wrote: > > > An OO function's only postcondition guarantee is that it will return > > in a finite amount of time. > > Fascinating. > > Daniel, do you have any links to further reading on this point (my > googling's skills have failed me)? As far as I know, the formulation is original to me, I can't give you arguments from authority, only reasoning... The canonical example of object oriented design is the Observer pattern. Think about the pattern and ask yourself, what is the postcondition of Observer's update() method? Once you think about it for a bit, you will realize that the only postcondition to the method is that it returns in a finite amount of time. That's it, and that's all there can be. Object oriented programming isn't about algorithm substitution based on type, that kind of stuff has been around since a + b was able to work with either integers or floating point. Dmitry asked me a couple questions in another reply to this comment, and the answer to all of them is "The Observer Pattern." |