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 5 Mar 2010 10:09 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." 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 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 -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: S Perryman on 5 Mar 2010 13:13 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. Regards, Steven Perryman
From: Dmitry A. Kazakov on 5 Mar 2010 14:19 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; 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: raould on 5 Mar 2010 16:50 hi, > 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. ja, this is the thing that i'm struggling with -- i'm assuming (which is probably the crux of my problem?) that to get something i can understand and test and not have producing weird strange bugs later, i have to nail things down a lot in some sense. i'm trying to learn how to unlearn that, to see what alternatives there are, at least ones that aren't full-on stochastic. :-} sincerely.
From: johnzabroski on 5 Mar 2010 18:43
On Mar 3, 6:34 pm, raould <rao...(a)gmail.com> wrote: > hi, > > i'm a long-time programmer with many years of work in OO languages, > but i'm well aware that i have lots to learn still. there are several > things i've been trying to grok which i'm still not clear on; to those > who already understand them they should appear to be basic, > fundamental issues, woe is me. i'd appreciate any thoughts on these, > or on the general topic. > > one aspect of my wondering is: given a programmer starting off with a > poor approach to OO, and they are going to learn to change something > about how they work, what are the knock-on effects? as in, if i change > bad habit A into good habit A', does that require that i > simultaneously fix bad habits X, Y and Z to avoid conflict? how does > one progress bit by bit, or how does one see the whole big picture in > one fell swoop? > > here are a couple of topics on my mind at the moment: > > * 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. > > * how to properly achieve flexibility in oo while not breaking > encapsulation too much: when to separate behaviour from state cf. > abstract/virtual classes; when to allow getters rather than tell-don't- > ask. > > * how to avoid objects having expectations of the state of other > objects and yet have the system progress in a non-overly-emergent > fashion, since i think that is hard for maintenance and debugging. > > thanks. I basically start with this question: What does your bookshelf look like? (What's on it related to programming?) How often do you use your local library to pick up a book on a subject? Do you know how to use inter-library loan to learn about some subject? How do you ensure the book you are reading contains academically correct explanations? Which of those books have you read cover to cover? How do you read them? How often do you read books? What else do you read? You can learn from coworkers, but it is less reliably than learning from experts. Books are also cheaper than paying for classes with an OO expert to train you. Experts publish books and papers to broadcast their mystical guru status to the world at large, and so books are generally much cheaper. I would also be careful when reading stuff like http://www.paulgraham.com/noop.html (mentioned earlier) as how he defines 'OO' appears to be Java, C++, and Objective-C. I am not sure why he woulkd do that; saying your language is not Java or C++ seems like a great way to promote a language. Saying things like "Object- oriented programming is exciting if you have a statically-typed language without lexical closures or macros." seems to misunderstand message sending and receiving in languages like Smalltalk, and how Smalltalk's blocks compare to Lisp macros. Lexical closures have to do with scope safety of higher-order functions, thus ensuring referential transparency. To understand this, I strongly recommend reading Friedman and Wand's Essentials of Programming Languages (EOPL) - get the most recent edition. For Smalltalk, see http://wiki.squeak.org/squeak/689 for many possible books. Since you are an experienced programmer, any of these books should be good for you. I have not read ANY of them, though! I've only read some of the blue book, and that was it! |