Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks) To : comp.programming,comp.object From : topmind Date : Mon Aug 22 2005 10:32 pm Chris Sonnack wrote: > topmind writes: > > >> (I can't believe I'm actually arguing with someone who thinks > >> lots of case statements to dispatch types are a win--I'd have > >> thought it was blatently obvious they are quite the opposite.) > > > > It is only "blatently obvious" in OO textbooks. The real > > world does not change in a sub-type-wise shape. > > Real world ain't fit the poly books, got it?! > > What I've got is that you don't seem able to respond to the point. > Your surrender is noted. Lists of identical case statements generally don't exist in real code, at least not the code I see (except from some bad coders). Show me some actual code outside of systems software that does this and that cannot be fixed without OOP. Dare ya! > >> The problem is simply that the necessary changes are "out there" > >> in the main code rather than being contained in one place. And > >> in any real production system, there's LOTS of "out there"! > > > > Poly spreads related behavior all over the place. > > No, that's the whole point, it doesn't. It contains it in classes > and allows you to make a given change only once. Bullsh8t! It only favors a very narrow kind of change. > > > Using the worn-out shape example, the "draw" methods are further > > apart than they would be in a case list. > > Wrong. Case statements are spread through the code. You need to > *locate* and *examine* each one to see if it requires a change. > And you need to replicate the same change over and over in each > one you do find. Just like subtyping and filling in the same method names over and over again? How is that less evil? Dup is dup. (One can inherit shared stuff, but a case/if counterpart has similar "defaults" approaches.) It ain't less typing. > > With classes, there is one change per type, and all types are > very easy to locate (and test). > > > Thus, what is it with your "contained in one place" statement? > > Stated (re-stated, actually) above. "Place" can be virtual anyhow in the computer. One can multi-index stuff if need be. And multi-indexing allows more than one orthogonal factor to be used, something trees have difficulty with. A tree-shaped file system is not the only and not the best way to manage code. > > > >> No, always. You still have to check them to see if they need to > >> be modified (and you have to find them all first). > > > > Poly has a different set of possible non-local change impacts, > > as described above. > > One more time: case statements...repeated changes spread all > throughout a code base...difficult to find among the many other > case statements. Class changes...one change to each class... > all concentrated in one set of files...each easily unit tested. Like I said, polymorphism favors a very narrow kind of change. Outside of the pattern it favors, it is MORE rework. > > > > Random changes in variations. One way to think about it is a hypergrid: > > > > http://www.geocities.com/tablizer/struc.htm > > ROFL! To quote: > > "One approach is to convert every IF block into a separate subroutine." > > In other words, to do poorly *exactly* what OO does naturally (and > OO lets you do without the if in the first place). I was studying the different approaches there, I did not necessarily propose that one as the "best". You are quoting out of context. > > > >>> It is more code rework to replace IS-A with HAS-A than to turn > >>> case lists into IF statements,... > >> > >> ?!?! I don't consider these even comparable. I'm still not at all > >> following what you're saying. > > > > You don't know how to change is-a to has-a? > > No, I don't see the connection between "replace IS-A with HAS-A" and > "turn case lists into IF statements". > > Quite honestly, it parses as gibberish to me. Read up on some OO writing. > > > >>> function stuff(...) { > >>> if (criteria_1) {feature_1} > >>> if (criteria_2) {feature_2} > >>> if (criteria_3) {feature_3} > >>> .... > >>> } > >> > >> Lunacy. If you add criteria_4 and feature_4, now you need to find > >> each and every one of these constructs and see if it needs to be > >> modified. > > > > What if we add new functions instead? > > Then you need to duplicate that insane structure above. Yuck!! Perhaps, but I can do it in *one* place. Poly would require visiting potentially every root node on the poly tree. In such case I can add the new requirement in a *single place*. Isn't that what you were bragging about earlier. ONE PLACE dude. One! However, in the real world the "case lists" tend not to match from operation to operation. The one-to-one assocation between dispatching variations and operations often found in OO books is a lie against reality. > > >> Worse, it requires that each occurance of this construct needs to > >> *know* about all criteria and all features. This is the worst kind > >> of software design. > > > > Like I said, they usually drift apart over time. > > Unresponsive to the point. Your surrender is noted. Your word "know" inplies some kind of inharent link. Often the link is weak and tends to drift apart over time. OO poly theory assumes far more regularity of change than what occures in the real world. Poly assumes things change along the grain of a tree taxonomy. Real not. > > > >> That's not the question I asked. [...] > >> > >> If the bank adds a new sort of account (e.g. an account that combines > >> checking and savings), does the rest of the system need to know about > >> it? > >> > >> Put another way, how does the system at large know a given account is > >> checking, savings or checking+savings. How does it know? > > > > Attributes in a database that tells what a given account is. > > And how does the system know to ask about these attributes? > How does it know what to do with them? It tends to be task-specific, and the if/case statements in each task tends not to directly mirror each other. They generally don't change in unison. Some OO fans have claimed they do, but they have never shown real biz code that proves it. It is only a UnicOOrn myth. > > >>> Reality does not necessarily give a flying fluck about "types". > >> > >> Of course it does. I have any number of typed values. Height, gender, > >> weight, hair color, eye color, job title, home location, etc. Each > >> of these has a restricted domain of values. That's a Type. > > > > Whatever you call it, it is not best modeled with polymorphism. > > So reality DOES have types, then? Your surrender is noted. > You are playing language games. Go ahead and model *people* with polymorphism. Do it and you will learn the hard way. It is your own example that will chew at your tree-shaped arse. > > > ([snipped] the rest as pointless.) > > -- > |_ CJSonnack _____________| How's my programming? | -T- .