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: Nilone on 9 Mar 2010 17:22 On Mar 9, 5:21 pm, "Daniel T." <danie...(a)earthlink.net> wrote: > Nilone <rea...(a)gmail.com> wrote: > > On Mar 9, 3:21 am, "Daniel T." <danie...(a)earthlink.net> wrote: > > > > One program is written in an OO style, while another > > > program (written in the same language and performing the same job,) is > > > not. (This kind of of stuff is talked about all the time using Java as > > > an example.) What is the difference between the two programs? > > > > It's not an easy question to answer... > > > This description is much too vague to comment on. If you give > > examples or references, I'll comment on them. > > You know what it is when you see it, but you can't tell me what you are > looking for? You imagine programs and ill-defined classifications such as a distinct OO style, and expect me to explain them? > > Robert Martin once said that OO means using of jump tables. Do you > agree, or at least think he was close? Certainly, jump tables is an important concept and technique in implementating OO systems. > > > Event-driven programming is a well-known architecture with features > > such as inversion of control (e.g. "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.") and unbounded nondeterminism (e.g. "An OO function's only > > postcondition guarantee is that it will return in a finite amount of > > time."). > > > Object-oriented modeling is a separate concept. > > Separate how? http://www.c2.com/cgi/wiki?DefinitionsForOo Try the various pages linked from there as well.
From: S Perryman on 10 Mar 2010 04:58 johnzabroski(a)gmail.com wrote: > On Mar 9, 11:56 am, S Perryman <a...(a)a.net> wrote: SP>Apart from something like meta-typing manipulation, there is no concept SP>of "DoesNotUnderstand message" in strongly-typed prog langs. DK>Or to put it slightly different, there is no type errors in strongly typed DK>languages. So even if DoesNotUnderstand is present, then it does not DK>indicate a type error. The type is OK, it does have the method Foo. It is DK>just so that Foo is contracted to propagate DoesNotUnderstand. >>Exactly. >>The concept of not understanding what to do when invoked, is completely >>different to not providing something to invoke in the first place. >>Nothing more to really say on the topic is there. > DoesNotUnderstand in Smalltalk does not actually mean "not > understanding what to do when invoked". Weakly-typed prog langs use their *runtime dispatch* mechanism as the means of detecting what in a strongly-typed prog lang is a *type error* . Smalltalk is a weakly-typed prog lang. [ snipped the rest as it appears to have no meaning/bearing on strong/ weak typing, or static/dynamic type checking ] Regards, Steven Perryman
From: S Perryman on 10 Mar 2010 05:11 johnzabroski(a)gmail.com wrote: > On Mar 8, 5:04 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: SP>Apart from something like meta-typing manipulation, there is no concept SP>of "DoesNotUnderstand message" in strongly-typed prog langs. >>Or to put it slightly different, there is no type errors in strongly typed >>languages. So even if DoesNotUnderstand is present, then it does not >>indicate a type error. The type is OK, it does have the method Foo. It is >>just so that Foo is contracted to propagate DoesNotUnderstand. > Exactly. > Things considered to be type errors (reduction to the "wrong" type) > are really just the compiler saying the program shouldn't be compiled, > because its behavior is undefined at least insofar as the compiler cares. Wrong. Type errors merely state that according to the rules of the type system, a program is valid, or not. If not, the compiler is instructed not to generate an executable form of the program. The compiler has *no idea whatsoever* of the *behaviour* of a program, irrespective of whether the program has type errors or not. That is the remit of *behavioural logic checking* systems. Which compilers (in general) are not. That is why you get defective programs at runtime, even though there are no type errors in the program. [ stuff snipped, because it appears to have no bearing / meaning on type checking of programs ] Regards, Steven Perryman
From: Nick Keighley on 15 Mar 2010 07:23 On 5 Mar, 19:19, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Fri, 05 Mar 2010 18:13:44 +0000, S Perryman wrote: > > Dmitry A. Kazakov wrote: > > >> On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote: > > >>>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 > >> 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 > > > Social insect colonies are event-driven. > > > There are "broadcast" event channels communicated via pheromones. > > For example : > > > - the signal that a queen exists > > - the signal that the colony is being attacked > > > Social insect colonies are also procedural. > > Maintenance of the colony structure, tending to the queen etc. > > > Both aspects are exhibited in good OO programs. > > Broadcasting is asynchronous 1-n messaging. OOPL rather deploy peer-to-peer > synchronous messaging. The vital advantage of 1-1 synchronous messages > (calls) are: > > 1. you can pass individual parameters. (Ant messages lack parameters > altogether); > > 2. you can have results, this is a key feature that enables programming > free of side effects; since objects have state that can be modified doesn't this, by definition, involve side effects? > 3. you don't have to worry about race conditions; > > 4. objects can be passive, so you can have small things objects, like > numeric ones, which otherwise could not be objects. (there would be too > many of them); > > 5. you have a uniform structure, where there is no dedicated > parameter/result, like message receiver, but all parameters and results can > be considered objects and treated equally; > > 6. you can do static analysis and other nice things much easier. really? -- Nick Keighley
From: Nick Keighley on 15 Mar 2010 07:39
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!" > 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. this is what embedded people call a "bug" :-) > If the car started accelerating, it would be because the *car* > wanted to, not because the caller wanted it to. which is why Toyota had do all those recalls... > 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. a couple of pints of boiling water is all the programming I usually use... ant_colony.relocate nest!() -- Nick Keighley |