Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks) To : comp.programming,comp.object From : topmind Date : Fri Jul 08 2005 09:33 am Chris Sonnack wrote: > topmind writes: > > >>>> As A and B are coupled, changes to A require changes to B. > >>>> > >>>> The more decoupled they are, the less changes ripple thru > >>>> the system. > >>> > >>> Okay, but how does polymorphism allegedly > >>> avoid this for ALL possible changes? > >> > >> No one I've heard has alleged this. > > > > Well, I don't know what the heck you are alleging. > > What several people have now stated repeatedly is... > > * Coupling creates dependancies between separate parts of the system. > * Dependancies increase the difficulty of maintanence. > ~~~ > * Therefore, coupling is to be *avoided*, subject to other constraints. > > What part of that is problematic for you? 1. Precise definition of "coupling" 2. That all dependencies are necessarily bad. Factoring increases dependencies by referencing similar things instead of copying them, but factoring is generally not considered bad. > > > > Even in the worse-case OO textbook "duplicate case/switch list" > > scenarios, a change to case list A does not necessarily "require" > > a change to case list B. List B may not care about the new option. > > > In general, the duplicate selects do require knowing about the new > type. Consider your bank account example. If the bank adds a new > account type, what are the odds that most--if not all--the rest of > the system needs to know about it? Case list A is blind to case list B in code. The code does not know or care how the bank changes before anything actually happens. They are *not* objectively coupled. The compiler/interpreter will never make a pointer or look-up between case list A and B (barring odd internal optimization tricks). > > The usual answer is: Very high. I disagree. The real world does not change in a tree-shaped way for the most part. You can force things into a tree shape, but it creates a mess over the long run. As I already illustrated with the "checkingAndSavings" example, polymorphism would result in more code rework, not less. You lost that one. > > > Now you may allege that it is most likely that changes to case > > list A will result in a change to case list B, but that is not > > "requires". That is a statement of probability. > > Obviously. IME (and obviously in the E of others), adding a new > "thing" to the system *usually* implies that the system needs to > know about it (otherwise, why bother adding it?). Thing != Type > > > "Requires" is a 100% probability. > > You're getting lost in word games. If the rest of the system is > going to process the new "thing", it's "required" to know about > it. There's no "probability" involved in the "requirement", it's > a consequence of the change. Who said all changes are new "things"? Changes are often new features, or newly permitted combinations of existing features. It is you polymorphism zealots who always see everything as a "thing", not the real world. > > Whether a change requires the system to know about the new "thing" > is a different matter--one related to design and the exact nature > of the change. But, again, IME, the *probability* of adding a > new thing is that the system does need to know about it. > > Polymorphism just provides a mechanism that *can* decouple how the > system treats "things". Through p/m, the system can be designed > to deal with "generic things", and this allows you to add new things > IF their interface matches a generic thing. Sets can do the same thing, often in a more flexible way. Different instances/records will have a different set of features not bound to any tree. Sets allow one to "reference" dispatched behavior instead of hard-wire them into code via locations in the polymorphic tree. It is easier to change references than to move code, and that is why polymorphism results in more code rework. I don't want to have to move my house to change which broker I can talk to. My experience tells me that sets are the right/safer way to do it and philosophers studying classification systems and A. Stepanov generally agree. You have been sucked in by simplistic polymorphism doctrine. > > > (BTW, there is some coupling and change pattern > > discussion also happening in the "OOP/OOD Design" > > topic.) > > Don't see that thread here in comp.programming. Try comp.object (which this topic has been cloned to.) > > -- > |_ CJSonnack _____________| How's my programming? | -T- .