Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks) To : comp.programming,comp.object From : Chris Sonnack Date : Tue Jul 12 2005 10:22 pm topmind writes: >> Dependencies are *unavoidable*. The trick is to manage them. > > Exactly. That is why one should manage relationships via > database INSTEAD OF STATIC CODE if possible. If possible and sensible, I agree. In many of the situations we've discussed it's neither. In most situations, it not one or not the other. >> ...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. > > And often invisible to REALITY. In the cases we're considering, this simply isn't so. (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.) > 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. 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"! >> More to the point here, the need to locate and diagnose all >> those case statements when you DO make a change is expensive. > > ONLY if they keep changing in lock-step with each. No, always. You still have to check them to see if they need to be modified (and you have to find them all first). > How is duplicating lists of methods better? Dup is dup. The duplication isn't the problem (and there is *considerably* less, because there are always many more points in the code where you need to dispatch something than there are dispatch destinations). The problem is lots of changes spread though the code as opposed to (even lots of) changes in one place. > But the most important thing is that case lists "degenerate" more > easily. Poly doesn't. "Degenerate"? Do you know what you're talking about, or are you just repeating words you heard somewhere? Please explain--I know all those words, but there's no sense to me in what you just said. > 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. > I count moving code as more expensive than changing stuff in place, > such as the IF criteria. If you count differently, then please > justify it. > > 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. 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. > I am mostly just changing the criteria expressions to change which > instance gets which feature. You are shuffling your poly tree up down > and all around to get the sharing of features at the right level, and > adding new "combo" classes such as > featureOneButNotFeatureTwoUnlessItsThursdayAndTheMoonIsFull... As has been explained **repeatedly** that's simply not how it works. (That might be how someone who doesn't understand OOD could go about it, but that doesn't make it right.) >> 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? > > I disagree that a bank SHOULD add a new "type". That's not the question I asked. I've dropped out of software entirely and am posing a basic business-requirements question: 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? > 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. > * Checks > * Interest (savings) > * CD's > * Credit cards > * Overdraft insurance > * Online banking > > If my math is right, that is 35 potential combinations if we use > "types". If you add a new service, it could instantly double. You're assuming it requires a combinatorial design. It does not. (This has been explained a number of times.) >> All that's happening is that we've added a new concrete realization >> of the "bank account" abstraction. > > "Concrete" because you have cement between your stubborn earns. If that's your best response, you're admitting you've got zip. >> 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. > > Only if you package it together and call it a "thing". No, no, no. A car is a thing. A blade of grass is a thing. A tv show is a thing. A song is a thing. An atom is a thing. Find a dictionary. Look up "thing". That's ALL I mean by "thing". >>> It is you polymorphism zealots... >> >> Mischaracterization. > > Semi-zealot? For the umpteenth time. I use whichever tool is appropriate for the job and don't love or hate any of them. You love databases, tables & sets and hate trees, OO & polymorphism. Who's the zealot? (And FWIW, in my experience, anyone--literally anyone--with that sort of love/hate perspective is almost always wrong. Just plain wrong. It's possible you're the first exception I've encountered in my 50 years on earth, but I rather doubt it. To be honest, at this point, I'm kind of thinking you're a deliberate troll.) >> Your opinion seems ill-informed to me. You don't appear to me to >> understand OOD principles very well. > > Good. Then show me how OOD objectively reduces typical code change I have. You waved your hands, stuck your fingers in your ears and went "Nah, nah, nah, nah, I can't hear you." > "Getting it" needs to be proven on the street, NOT in your > head. Nobody cares if OOD makes your head happier. We want a > real tool, not an opiate. I've been a programmer for 30 years. I've been using OOD for about half that time. It HAS proven itself over and over again. If it hadn't, I wouldn't use it. Period. Let me put it this way. I'm a suspicious cynic (a big part of why I'm not buying your line at all so far). When I first started reading about this new-fangled C++ language and OOP, I figured it was just another fad and who needs that crap. It was *learning* it and *using* it that changed my mind. I was convinced by my personal (and now long-time) experience with it--nothing else. It made my life as a programmer better and easier time and time again. >> 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. > > To some extent you are right. But the difference between the two is > generally: > > 1. Relational tends to use declarative (attribute-driven) > interfaces while OO leans toward behavioral interfaces. I think you're parrotting something you read. Give me an example of what you mean. Show me two cases, one declarative and one behavioral. > 2. Relational requires that each record/object belong to > one and only one entity while object "records" can belong > to zero or many other class groupings. ?!?! What about 1:M relationships in RDBs? And I frequently use a single table for multiple purposes. For example, I might have a table of "communications links" which contain email addresses, phone numbers and web URLs. Object "records"? What are those? Do you mean what are often called the classes (design) or the instances (objects themselves)? > OO has always had a consistency problem. News to me. Give me an example. Not something you plucked off the net. Something you create from whole cloth. Show me you have a clue what you're talking about--I'd really like to believe you. Who knows, maybe you'll teach me a new trick. > 3. Polymorphism generally only works well with one > poly "tree" at a time. Utter nonsense. Many designs do very well by interface inheritance, which allows classes to "wear many cloaks". Consider the MS COM design. There's no implementation inheritance, no "root" class, per se, but all COM objects implement the IUnknown interface. They implement others as needed. It's, IMO, a *very* slick design. >> 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. > > In practice I find that putting code in tables is not necessary and > not helpful, even it it was easy. Code in tables? Where did that come from? I become increasingly curious as to just exactly how you'd implement something like this bank account thing. I'd like to see some db schema and some pseudo-code showing how you handle various sorts of accounts and dispatch against your table data. Or, bluntly, less hand waving and more examples, because I begin to wonder if you're not just another amUSENET troll lonely to keep a conversation going. >>> 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. > > You'll miss all the fireworks :-) Works for me. I've had decades of "fireworks". Shakespeare was right: Sound and Fury signifying nothing. Or at least very little. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .