Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Owen Jacobson on 27 Jun 2005 02:50 CBFalconer wrote: > Patrick May wrote: > >> topmind wrote: >> >>> Why are you trying to put the burden on me anyhow? >> >> You are the one coming into a venue that is specifically for the >> discussion of OO techniques and making assertions that are at odds with >> the experience of most of the other participants. > > Er - comp.programming has not, to my knowledge, ever tried to limit > discussions to OO techniques. Check your headers: Newsgroups: comp.programming, *comp.object* F'up set, Owen
From: Chris Sonnack on 28 Jun 2005 13:37 topmind writes: > Brush Teeth > ....*.find.toothbrush > ....*.find.toothpaste.tube > ....*.open.toothpaste.tube > ..........o.Put.thumb.and.pointer.finger.on.cap > ..........o.turn.fingers.counter-clockwise. > ....*.clean.teeth > ..........o.put.brush.on.teeth > ..........o.move.back.and.fourth.vigorously > ..........o.repeat.above.step.100.times. > ....*.clean.up > ..........o.rinse.brush > ................+.turn.on.water > ................+.put.head.of.brush.under > ..................running.water.for.30.seconds > ................+.turn.off.water. > ..........o.put.cap.back.on.toothpaste > ..........o.put.all.items.back.in.cabinet > > Most people would produce a fiarly similar hierarchy without even > seeing this one. LOL! You mean to say it is so naturally tree-shaped that most people would naturally produce a tree? -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 28 Jun 2005 13:54 topmind writes: > Copy-and-paste actually *reduces* coupling because it lets things be > independent, for example. Thus, if reducing coupling is always good, > then copy-and-paste is always good. It may appear to reduce coupling, but as has been said, it creates an invisible (to the source) web of coupling that needs to be documented and maintained by the developer. That is, unless, the copied parts have absolutely no need to be in sync with the the originals. For example, if I copy'n'paste a routine from a totally separate program as a form of code reuse, that's fine. But creating identical bits of source that are actually logically coupled is a horrible bad idea. One of the biggest problems developers wrestle with is the "synchronization problem", and it occurs any time you have two (or more) things that need to be kept in sync. A simple example is source and comments. They need to be kept in sync, or you end up with comments that are lies or half-truths. It is far better practice to factor out common functionality. Ideally, you never want duplicate code, ever! -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 28 Jun 2005 19:59 Chris Sonnack wrote: > topmind writes: > > > Brush Teeth > > ....*.find.toothbrush > > ....*.find.toothpaste.tube > > ....*.open.toothpaste.tube > > ..........o.Put.thumb.and.pointer.finger.on.cap > > ..........o.turn.fingers.counter-clockwise. > > ....*.clean.teeth > > ..........o.put.brush.on.teeth > > ..........o.move.back.and.fourth.vigorously > > ..........o.repeat.above.step.100.times. > > ....*.clean.up > > ..........o.rinse.brush > > ................+.turn.on.water > > ................+.put.head.of.brush.under > > ..................running.water.for.30.seconds > > ................+.turn.off.water. > > ..........o.put.cap.back.on.toothpaste > > ..........o.put.all.items.back.in.cabinet > > > > Most people would produce a fiarly similar hierarchy without even > > seeing this one. > > LOL! You mean to say it is so naturally tree-shaped that most people > would naturally produce a tree? > I have agreed that *people* naturally relate to trees. Thus, they tend to produce algorithms that have a tree-shaped division of tasks. It is not that tasks are inherently are tree-shaped, it is that people are more comfortable using trees to describe them. However, on a larger scale algorithms are not pure trees because usually named tasks (subroutines) eventually come in to play as we scale up. Subroutines break the tree because they are cross-branch links. IOW, on a small scale or *informal* discussions (which is what the above is), trees are a decent useful lie. -T-
From: topmind on 28 Jun 2005 20:20
> > > Copy-and-paste actually *reduces* coupling because it lets things be > > independent, for example. Thus, if reducing coupling is always good, > > then copy-and-paste is always good. > > It may appear to reduce coupling, but as has been said, it creates an > invisible (to the source) web of coupling that needs to be documented > and maintained by the developer. Yes, but that is a nebulous form of "coupling". Robert Martin implied that "coupling" was sure-shot metric that by itself would guide decisions. But if the coupling is only in the mind rather than in code, then it loses that status. > > That is, unless, the copied parts have absolutely no need to be in sync > with the the originals. We don't know for sure either way up-front. They may need syncing in the future or they may not. It is a matter of *probability*, something that Robert failed to adaquately address. This is why such "mental coupling" tells us almost nothing about such a decision. > For example, if I copy'n'paste a routine from > a totally separate program as a form of code reuse, that's fine. > > But creating identical bits of source that are actually logically coupled > is a horrible bad idea. One of the biggest problems developers wrestle > with is the "synchronization problem", and it occurs any time you have > two (or more) things that need to be kept in sync. A simple example is > source and comments. They need to be kept in sync, or you end up with > comments that are lies or half-truths. > > It is far better practice to factor out common functionality. Ideally, > you never want duplicate code, ever! > Note that I was not promoting copy-and-paste above. I was only exploring it's relationship to Robert's view of "coupling". -T- |