Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks) To : comp.programming,comp.object From : Chris Sonnack Date : Thu Jul 28 2005 08:09 pm 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. >>> Case lists can and do drift apart over time. >> >> Even so, if they are dispatching on the same sort of thing (like >> a bank account) you still need to examine each and every one of >> them when you make a change regarding bank accounts. > > One could say similar things about polymorphic trees. If you add > a new method, you have to check the whole poly tree to see if it > needs to be added to others or already exists. Which would you rather do: examine a localized, well-defined set of (class) files in a well-defined place or search through an entire code base looking for case statements? > And, you may have to visit multiple nodes to add the same-named > method. A well-defined, local set of class files, verses searching through an entire code base for something ill-defined (one assumes there are many case statements and not all are related to a given process, so each must be examined to see if THIS case statement is one that must be changed). >> 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. > 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. 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. >> 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. > 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). >>> 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. >>> 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!! >> 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. >> 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? >>> 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. ([snipped] the rest as pointless.) -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .