[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OO should break when broken(was re: the benefits ofimmutability)



At 8:50 AM -0700 9/1/03, James McCartney wrote:
>On Monday, September 1, 2003, at 04:05 AM, Geoffrey Knauth wrote:
>
>>This reminds me of something that bothers me about OO:  the 
>>accumulation of unused stuff.  When I extend Circle to make 
>>Ellipse, I add x-radius and y-radius, but the original radius 
>>instance variable is still there.  Since I'm not going to use 
>>Circle's radius any more, I wish I could just ask it to go away, if 
>>the compiler or runtime could verify it isn't needed by methods I 
>>decide not to override.
>>
>
>If you are in this situation it means that you probably should have 
>had an abstract class which is a common ancestor of these two 
>classes.

I dunno. If you look on OO programming as a form of 
programmer-directed, static genetic programming where the 
programmer's determining the behaviour of child classes rather than 
letting darwininan-weighted random chance determine the behaviour, it 
makes perfect sense to want to obscure or block parent class methods, 
rather than factoring the parent class into multiple classes (which 
can be a pain with no MI, or can lead to the degenerate case where 
you're inheriting from a zillion single-method classes, which makes 
sharing instance data a bit problematic)

Of course, if you don't look at it like that, this makes no sense. :)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk