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: raould on 3 Mar 2010 18:34 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.
From: Nilone on 4 Mar 2010 04:21 On Mar 4, 1:34 am, 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. If there is anyone for whom the whole field of OO is so clean and simple, I'd pay for a consultation. I've seen many of the well-known theorists state that it is complex. > > 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? Knock-on effects? I don't know. To see the big picture, study the theoretical models - specifically, the actor model (Hewitt), entity- relationship model (Chen), object-relational model (Halpin) and relational model (Date). Add some systems theory for flavour. > > 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. 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. > > * 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. Sounds like object calisthenetics. Also look at http://www.paulgraham.com/noop.html. On smaller projects, refactoring is much more efficient than overanalysing. A large project can be broken into smaller ones via analysis and design. > > * 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. Good question. The most important technique is to design, evaluate and refactor the design before you start coding. You can look into design patterns and read some software architecture books, they all tend to focus on this topic. Nilone
From: Anton Sharov on 4 Mar 2010 11:35 On Mar 4, 12:21 pm, Nilone <rea...(a)gmail.com> wrote: > On Mar 4, 1:34 am, raould <rao...(a)gmail.com> wrote: > > > hi, > > If there is anyone for whom the whole field of OO is so clean and > simple, I'd pay for a consultation. I've seen many of the well-known > theorists state that it is complex. Bertrand Meyer is good enough in OO. I prefer reading his books, like object-oriented software constructions.
From: raould on 4 Mar 2010 17:57 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. sincerely.
From: Daniel T. on 5 Mar 2010 09:46
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." 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... http://blog.ted.com/2008/01/deborah_gordon.php |