Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks) To : comp.programming,comp.object From : Chris Sonnack Date : Fri Jul 08 2005 02:04 pm topmind writes: >> * 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" Neither is there a precise definition of, say, "what a CEO does" or "what is love". In fact, according to quantum physics, nothing in the universe is precisely defined. You're just going to have to learn to accept that. > 2. That all dependencies are necessarily bad. We've said repeatedly they are not. It's situational and dependant on other constraints. Dependencies are *unavoidable*. The trick is to manage them. >> 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). Yeah, and? As repeatedly explained, the coupling between case statements is *invisible* to the compiler, which is *exactly* why it's bad. It requires *external* means (documentation, programmer memory) to manage. More to the point here, the need to locate and diagnose all those case statements when you DO make a change is expensive. Whereas, if you know the code deals only with abstractions that you haven't changed, your change is restricted to one easily tested area. >> The usual answer is: Very high. > > I disagree. You disagree that, if the bank adds a new type of account, most of the system needs to know about it? How will it process those new accounts? > The real world does not change in a tree-shaped way for the most > part. This really isn't about trees. The model here is of an abstraction, a "bank account" with a number of concrete realizations. It's, IMO, unlikely you'd have more than these two levels, although in some cases you might derive a very specialized account from an existing account type. All that's happening is that we've added a new concrete realization of the "bank account" abstraction. > As I already illustrated with the "checkingAndSavings" example, > polymorphism would result in more code rework, not less. You > lost that one. This isn't about winning or losing. >> 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 Yeah, and? I've been using "thing" deliberately to get away from OOD. When I say "thing" I mean just that, a "thing". A new feature is a thing. A newly permitted combination of existing things is a thing. > It is you polymorphism zealots... Mischaracterization. > 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. Your opinion seems ill-informed to me. You don't appear to me to understand OOD principles very well. In reality, once you get down to cases, both techniques are similar. Late-binding in polymorphism is usually implemented against some sort of table of methods (in some languages a "method" is just an offset into that table, so no lookup required). And using a table with a list of features is sort of a form of polymorphism. The only major differences are that adding a record to a table is probably faster than adding a new class, but needs to be balanced against the additional overhead of the table-based solution. In most cases, dispatching against a formal table is a non-ideal solution for production software, so it needs a big win in some other regard to compete with native solutions. IF changes were often, that could make it a win. IF the system is relatively stable, it probably isn't. >> Don't see that thread here in comp.programming. > > Try comp.object (which this topic has been cloned to.) Not interested. After many years of amUSENET, it's gotten very old, so I only hang out here in comp.programming these days. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .