Polymorphism is Anti-Set-Theory (Re: Modularization)
in [OOP]
|
Prev: UML Inheritance: how to specialize an attribute?
Next: OOP is own private Cleveland (Re: OO Books for newbies?)
From: topmind on 11 May 2007 11:26 Phlip wrote: > Ed Kirwan wrote: > > > When engaged in modularization myself (I consider splitting a program into > > name spaces as modularization), I tend to practice the GOF's, "Variance > > encapsulation," which says basically that if you think a part of your > > program will vary, then encapsulate it. (This is a re-statement of the > > earlier Parnasia modularization, "... one begins with a list of difficult > > design decisions or design decisions which are likely to change. Each > > module is then designed to hide such a decision from the others." [2]) > > That technique works at all scales; it's the point of the refactor "replace > conditional with polymorphism". Dangerous advice. Polymorphism hard-wires domain noun taxomies into code, which limits its change-friendliness when the nature of the classification system needs to change. For one, polymorphism cannot easily handle a change from mutually-exclusive options to independent options. The most common textbook is example is subtyping bank accounts into Savings and Checking, and then the bank wants to offer *both* options to each customer. (Customers really want buffets/ smorgies, not forced groups of features.) IF statements handle this change better. Polymophism is anti-set-theory, and being a set-theory fan, I cannot accept such a statement being made without challenge. Use the database to manage domain noun classification assignment, not app code. The app code implements features while the database tracks which domain nouns have which features. This is a form of "separation of concerns" that OO'ers often talk about. They follow their own advice only selectively. -T-
From: JXStern on 15 May 2007 12:57 On 11 May 2007 08:26:53 -0700, topmind <topmind(a)technologist.com> wrote: >Dangerous advice. Polymorphism hard-wires domain noun taxomies into >code, which limits its change-friendliness when the nature of the >classification system needs to change. For one, polymorphism cannot >easily handle a change from mutually-exclusive options to independent >options. The most common textbook is example is subtyping bank >accounts into Savings and Checking, and then the bank wants to offer >*both* options to each customer. (Customers really want buffets/ >smorgies, not forced groups of features.) IF statements handle this >change better. > >Polymophism is anti-set-theory, and being a set-theory fan, I cannot >accept such a statement being made without challenge. Use the database >to manage domain noun classification assignment, not app code. The app >code implements features while the database tracks which domain nouns >have which features. This is a form of "separation of concerns" that >OO'ers often talk about. They follow their own advice only >selectively. Er, I think you're talking about inheritance, not polymorphism. The vtable "polymorphism" of C++ is degenerate, based on inheritance. Try Python. J.
From: topmind on 15 May 2007 17:10 JXStern wrote: > On 11 May 2007 08:26:53 -0700, topmind <topmind(a)technologist.com> > wrote: > > >Dangerous advice. Polymorphism hard-wires domain noun taxomies into > >code, which limits its change-friendliness when the nature of the > >classification system needs to change. For one, polymorphism cannot > >easily handle a change from mutually-exclusive options to independent > >options. The most common textbook is example is subtyping bank > >accounts into Savings and Checking, and then the bank wants to offer > >*both* options to each customer. (Customers really want buffets/ > >smorgies, not forced groups of features.) IF statements handle this > >change better. > > > >Polymophism is anti-set-theory, and being a set-theory fan, I cannot > >accept such a statement being made without challenge. Use the database > >to manage domain noun classification assignment, not app code. The app > >code implements features while the database tracks which domain nouns > >have which features. This is a form of "separation of concerns" that > >OO'ers often talk about. They follow their own advice only > >selectively. > > Er, I think you're talking about inheritance, not polymorphism. > > The vtable "polymorphism" of C++ is degenerate, based on inheritance. > Try Python. > > J. Not really. Polymorphism or specific language features of OOPL's can be *made* to emulate sets or have set-like features, but still it is generally foreign to OOP *philosophy*. (Turing Equivalence again) Plus, much if it is farmed off to the DB, and is not really part of the app code in good P/R. In good P/R, tracking which instance or variation has what feature is done mostly by the DB. The app only implements the features and is generally blind to (or at least not grouped upon) any domain noun taxonomy. This is against basic polymorphism (otherwise there would be no poly to morph). With enough polymorphic indirection, it can start to resemble the same kind of thing, I will agree, but it is easier to do such IMO with the DB instead of app code because the DB is relational and not navigational. -T-
From: JXStern on 16 May 2007 20:07 On 15 May 2007 14:10:39 -0700, topmind <topmind(a)technologist.com> wrote: >> Er, I think you're talking about inheritance, not polymorphism. >> >> The vtable "polymorphism" of C++ is degenerate, based on inheritance. >> Try Python. >> >> J. > >Not really. Polymorphism or specific language features of OOPL's can >be *made* to emulate sets or have set-like features, but still it is >generally foreign to OOP *philosophy*. (Turing Equivalence again) I'm not really addressing your point, I just think you are using the wrong term, what you are criticizing is the relationship of classes resolved along inheritance lines. Your example was subtyping. That's an inheritance thing. Polymorphism of methods cuts across classes, related or not. Except in degenerate languages like C++. Polymorphism doesn't resolve itself, it *ignores* noun taxonomies. Again, except in degenerate blah blah blah. And as far as methods are accessors of properties, properties thus cross classes. Just as the secondary property of "red" may exist independently, if you believe in universals, or only as an attribute for instances of any class. But that wouldn't be anti-set theory, you can have the set of all red objects. The problem internal to OOP is that inheritance breaks encapsulation, that's not a secret, though whether it's a feature or a bug can be debated. J. >Plus, much if it is farmed off to the DB, and is not really part of >the app code in good P/R. In good P/R, tracking which instance or >variation has what feature is done mostly by the DB. The app only >implements the features and is generally blind to (or at least not >grouped upon) any domain noun taxonomy. This is against basic >polymorphism (otherwise there would be no poly to morph). With enough >polymorphic indirection, it can start to resemble the same kind of >thing, I will agree, but it is easier to do such IMO with the DB >instead of app code because the DB is relational and not navigational. > >-T-
From: Daniel T. on 17 May 2007 09:14
On May 11, 11:26 am, topmind <topm...(a)technologist.com> wrote: > Polymorphism hard-wires domain noun taxomies into > code, which limits its change-friendliness when the nature of the > classification system needs to change. I don't see how. Could you prove this assertion? The reason I doubt it is because of the following... Assume that somewhere in the code there is a myObject.doThing(). If I want two classes of objects to be useable in that context, then any of the following will work (Python code used for examples:) class Foo: def doThing(self): pass class Bar: def doThing(self): pass ---- or ---- class Foo: def doThing(self): pass class Bar ( Foo ): pass ---- or ---- class Bar: def doThing(self): pass class Foo ( Bar ): pass ---- or ---- class FooBar: def doThing(self): pass class Foo ( FooBar ): pass class bar ( FooBar ): pass There are a myriad of other ways to structure the code as well and we can switch from one structure to another without modifying the original code that calls "doThing". So I ask, how are the "noun taxonomies" hard-wired into the structure of the code? |