Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Robert C. Martin on 16 Jun 2005 18:14 On 15 Jun 2005 11:48:53 -0700, "topmind" <topmind(a)technologist.com> wrote: > > >> >I agree there is a trade-off, but my observation is that change favors >> >case statements most of the time. >> >> That's where we disagree. I think change favors neither approach, and >> that any approach that favors one technique over the other is >> necessarily imbalanced. > >Well, case/if statements are a slightly lower level of abstraction than >polymorphism. Again, I disagree. Indeed, the two are often implemented with the exact same structure: a jump table. Polymorphism is simply indirection with an inverse dependency (i.e. the switch does not know about the cases, but the cases know about the switch) whereas a switch/case statement is indirection with a forward dependency. ----- 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 16 Jun 2005 18:17 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. ----- 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 16 Jun 2005 18:27 On 15 Jun 2005 11:21:20 -0700, "topmind" <topmind(a)technologist.com> wrote: > >Outside of performance testing, since when does testing have to be >lightning fast? In my environment, we run the tests every few minutes. I want to know if the last line of code I wrote broke something unexpectedly. No matter how you look at it, the faster the tests run, the more you can run them; and the more you can run them, the sooner you will find problems. ----- 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 16 Jun 2005 18:35 On 15 Jun 2005 11:21:20 -0700, "topmind" <topmind(a)technologist.com> wrote: >This sounds like a Strategy pattern, It is. >and there are table-oriented and procedural strategy patterns also. None that allow independent deployability. (e.g. I want to ship new pay classifications in new DLLs without changing the central core). >But in my experience such >independence is less common for "business objects". When the business >rules change such that entirely new pay categories appear, it generally >also affects so much other stuff that whole new software needs to be >shipped anyhow, not just individual modules. If a single change to the requirements (like the addition of a new pay category) causes the entire system to change, then the system is poorly designed. That kind of tangled design is *exactly* the kind of bad design that OO helps us avoid. >Business rules are >inherently a big messy graph with a lot of existing or surprise >connections. Design is the activity of making sense of the messy graph and partitioning it into something a bit more rational, developable, and deployable. *That*, in the end, is what software engineering is all about! >"Separation of concerns" is often a pipe dream because the >creators of business rules don't bother to keep things separate. The >price of tea in China *can* affect Bob's little app in Nebraska. This attitude suggests to me that you have never seen a good software design. I have seen many good software designs that have managed to disentangle the skein of interdependencies amongst the business rules, and yield a developable, maintainable, and independently deployable structure. >Another way of saying more or less the same thing is that the >interfaces will need changing almost as often as implementation. My experience is quite the contrary. And the experience of my user who added the RDB back end to FitNesse in just under a day is just one case in point. Frankly, Bryce, I think it would behoove you to study a few good books on software design. To think that software systems *must* be tangled simply because business rules appear to be, is -- giving up. ----- 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 16 Jun 2005 20:06
> Resorting to insults isn't debating it's just childish. I make it a point *not* to shoot first[1]. I suppose the Jesus thing to do would be to completely ignore insults rather than respond in kind. However, I ain't Jesus. [1] If I accidentally insulted you first, I apologize. It was an accident. -T- |