Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Robert C. Martin on 17 Jun 2005 12:25 On 16 Jun 2005 17:36:36 -0700, "topmind" <topmind(a)technologist.com> wrote: > > >Robert C. Martin wrote: >> On 15 Jun 2005 15:56:32 -0700, "topmind" <topmind(a)technologist.com> >> wrote: >> >> > TREES ARE A CRUTCH >> >> Trees are a red herring. They aren't the issue. There was a time in >> the late '80s when OO enthusiasts were very hopeful about inheritance >> hierarchies. That feeling passed in the early '90s. The last nail >> was driven into it's coffin by the Design Patterns book. >> > >But as I mentioned and described, non-tree OO is really messy. No, it's really clean. >It is like Goto's reborn. No, it's like having a tool that allows me to strongly decouple. >Instead of behavioral pointers (gotos), it has >structural pointers. I can't parse this. Interfaces are simply tables of pointers to functions, with a lot of discipline imposed upon them. >And, see how ugly the Visitor pattern is? No, I rather like the Visitor. I think it's an elegant solution to a very tricky problem. >Even >some GOF (pattern) fans are otherwise embarrassed by it. Some people are democrats, and others are republicans. Who can explain why? People who don't like Visitor are just wrong, IMHO. It's like people who don't like multiple inheritance, or OO, or hammers, or table saws. Tools are tools. We use them when appropriate, and don't when not. To point a finger at the tool and say "BAD" is just silly. >Visitor is two >trees caught in a Trek transporter convergence accident. Nice visual, but an uninformed comparison. ----- Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 "The aim of science is not to open the door to infinite wisdom, but to set a limit to infinite error." -- Bertolt Brecht, Life of Galileo
From: Robert C. Martin on 17 Jun 2005 12:28 On 16 Jun 2005 11:14:42 -0700, "topmind" <topmind(a)technologist.com> wrote: > >> >> >I am having difficulty finding coherent requirements or code samples >> >for a dosage system. How about we focus on stuff that polymorphs in >> >that example. What are the polymorphic types or classes? >> >> The requirements are reasonably well stated in overview form in the >> first article. By the second or third article there is a very >> concrete requirement specified in detail as an acceptance test. >> >> If you follow the example through the columns, you'll find a number of >> polymorphic entities. Perhaps the first you'll find are the test >> cases themselves. They derive from the JUnit framework. Next, you'll >> find that the acceptance test fixtures are based on a polymorphic >> framework (FIT). Within the application you find a polymorphic >> gateway to the database, and (Manufacturing) which is a mock object >> that masquerades as another system. You find that the messages show >> hints of polymorphism, and may become fully fledged polymorphic >> entities in a later iteration. >> >> Bit by bit, as the application evolves, more and more polymorphism >> creeps in. The application does not start with a lot of polymorphism. >> Rather, polymorphism gets added over time in order to keep the >> application flexible and decoupled. >> > >I was hoping for something that everyone can easily study, not *just* >you and me. Thus, if I use your example, I would have to consolidate it >and clean it up the doc for presenation, removing the story-like flow. >I don't want to be a P.I.T.A. but it seems that is your obligation, not >mine. Excuses, excuses, excuses. I've given you many different options. There's always some reason why you don't like them. Either it's in a book that you don't want to pay for, or check out of the library, or it's in a language you don't understand, or it's in a set of articles, or... When you decide to do a little homework to back up your position, we can continue this discussion. ----- Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 "The aim of science is not to open the door to infinite wisdom, but to set a limit to infinite error." -- Bertolt Brecht, Life of Galileo
From: topmind on 17 Jun 2005 13:33 Robert C. Martin wrote: > On 16 Jun 2005 17:28:53 -0700, "topmind" <topmind(a)technologist.com> > wrote: > > >Well, I won't speak for all possible changes here, but case statements > >appear to handle removal of mutual exclusitivity more easily. For > >example, if a person's bank account by decree can now be both checking > >and savings: > > > >// *** BEFORE *** > >sub calcFees(account) { // pass in a record set > > fees = 0 > > select on account.accountType { > > case "checking" {fees = foo * checkCount} > > case "savings" {fees = bar * amt} > > } > > .... > > return fees > >} > > > >// *** AFTER *** > >sub calcFees(account) { > > fees = 0 // init > > if (account.hasChecking) {fees += foo * checkCount} > > if (account.hasSavings) {fees += bar * amt} > > .... > > return fees > >} > > > > > >A polymorphic approach would be a lot more rework and shuffling. > > Why do you think so? > > public class CheckingSavingsAccount implements Account { > SavingsAccount sa; > CheckingAccount ca; > ... > decimal calcFees() { > return sa.calcFees() + ca.calcFees(); > } > > Since I haven't changed either the code for SavingAccount, nor the > code for CheckingAccount, I can still have both, and *also* have a > CheckingSavingsAccount. > > To say this another way, I have added the requirement for combining > the two accounts, without changing the existing code. > On a small scale making a combo class works, but turns into a potential *combinatorial explosion* as more factors are involved. Two items: A B AB Three items: A B C AB AC ABC BC Four items would take too much space. It is almost exponential growth. (Reader excercise: what is the mathematical equation for the number of combinations?) If there are only a few factors, then either approach (case or classes) is simple, so that is not what we are discussing. It is bigger more complex things. As you can see, you are hard-wiring classification systems into code. Code is a sh8tty classification management system and combo classes is poor normalization and over-coupling. For example, if you remove a category, you have to find and remove all the combo classes with that item in it. > > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: topmind on 17 Jun 2005 13:52 > >> > >> > TREES ARE A CRUTCH > >> > >> Trees are a red herring. They aren't the issue. There was a time in > >> the late '80s when OO enthusiasts were very hopeful about inheritance > >> hierarchies. That feeling passed in the early '90s. The last nail > >> was driven into it's coffin by the Design Patterns book. > >> > > > >But as I mentioned and described, non-tree OO is really messy. > > No, it's really clean. > > >It is like Goto's reborn. > > No, it's like having a tool that allows me to strongly decouple. Coupling is not always bad. There are non-OO ways to decouple everything, but a big bag of atoms is hard to work with. We couple things so that we can work on things as a group instead of independent atoms. Suitcases couple our stuff so that we don't have to carry them independently, fumbling them all over the airport floor. Polymorphism couples one to mutual exclusitivity, so there! The relational way of "coupling" is to provide references to related things. If you don't want to use a given set of references, you don't have to. Thus, any grouping or "coupling" is as-needed but not forced. > > >Instead of behavioral pointers (gotos), it has > >structural pointers. > > I can't parse this. Interfaces are simply tables of pointers to > functions, with a lot of discipline imposed upon them. Relational is discipline on tables, OO is a 60's style navigational mess that lacks discipline. > > >And, see how ugly the Visitor pattern is? > > No, I rather like the Visitor. I think it's an elegant solution to a > very tricky problem. You have a strange notion of "elegant". A table-oriented solution allows one to show the mappings every which way till sunday: how you like it grouped, how I like it grouped, how your dog likes it grouped, etc. It is separation of meaning from presentation so that presentation can be *customized* to personal preference or a specific need. Visitor hard-wires (COUPLES!) one to a limited, fixed presentation, and that is part of why it is evil. > > >Even > >some GOF (pattern) fans are otherwise embarrassed by it. > > Some people are democrats, and others are republicans. Who can > explain why? People who don't like Visitor are just wrong, IMHO. Can you objectively prove this? > It's like people who don't like multiple inheritance, or OO, or > hammers, or table saws. Tools are tools. We use them when > appropriate, and don't when not. To point a finger at the tool and > say "BAD" is just silly. > > >Visitor is two > >trees caught in a Trek transporter convergence accident. > > Nice visual, but an uninformed comparison. > Beam Visitor and navigational messes the hell off my planet! > > ----- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T-
From: Robert C. Martin on 17 Jun 2005 15:37
On 17 Jun 2005 10:33:18 -0700, "topmind" <topmind(a)technologist.com> wrote: >On a small scale making a combo class works, but turns into a potential >*combinatorial explosion* as more factors are involved. It was *your* example, after all. > >Two items: > > A > B > AB > >Three items: > > A > B > C > AB > AC > ABC > BC > >Four items would take too much space. It is almost exponential growth. >(Reader excercise: what is the mathematical equation for the number of >combinations?) (2^n)-1. >If there are only a few factors, then either approach (case or classes) >is simple, so that is not what we are discussing. Actually, since it was your example, we *were* discussing it. But if you'd like to change the rules right now, that's fine. >It is bigger more complex things. Fine, let's discuss the bigger, more complex, things. Here's the polymorphic solution for the more complex case: public class CompositeAccount { public ArrayList<Account> components; public decimal calcFee() { decimal fee = 0; foreach Account a in components fee += a.calcFee; return fee; } } Notice the lack of the exponential explosion? What does the procedural version look like? decimal fee = 0; if (isTypeA(account)) fee += calcFeeForTypeA(account); if (isTypeB(account)) fee += calcFeeForTypeB(account); if (isTypeC(account)) fee += calcFeeForTypeC(account); . . . Hmmm. >As you can see, you are hard-wiring classification systems into code. >Code is a sh8tty classification management system and combo classes is >poor normalization and over-coupling. For example, if you remove a >category, you have to find and remove all the combo classes with that >item in it. > >> >> >> ----- >> Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com > >-T- ----- Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 "The aim of science is not to open the door to infinite wisdom, but to set a limit to infinite error." -- Bertolt Brecht, Life of Galileo |