Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: topmind on 16 Jun 2005 14:33 Jeff Brooks wrote: > topmind wrote: > > Unfortunately, I don't want to release it public because I want some > > security through obscurity. I might release snippets though. There are > > plenty of existing wiki's implementations anyhow, and my approach does > > not significantly differ than them (although I feel I factored better > > than some of those I looked at). > > So you are not going to support your claims with any evidence as usual. What significant claim did I make? None of my complaints about lack of OO evidence hinges on any claims I have made. I could never be born and you *still* have no solid OO evidence. I am just the messenger pointing out gaps in your evidence. I didn't make the gaps, I only pointed them out. > > If your past posts is any indication of your future behavior you will > continue to complain that the OO people never provide any evidence and > forget that your are guilty of the same thing. Ignoring for the moment the issue of who has the burden of evidence, the above can be translated to: "Because you are an evidence-ahole, we can be evidence-aholes also". At least you are indirectly starting to see your faults. That is a start. > > Jeff Brooks -T-
From: Ilja Preu� on 16 Jun 2005 15:24 Robert C. Martin wrote: > On 14 Jun 2005 13:21:50 -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. I don't even understand how change could favor one implementation over another. After all, it isn't too hard to have a switch statement over operations, or a method that is called for a shape on a Command pattern implementation. Regards, Ilja
From: Ilja Preu� on 16 Jun 2005 15:32 Thomas Gagne wrote: > The intersection above is another rectangle so why return an > intersection when I can return a rectangle? Well, depending on the requirements, it might be simpler - for example, if we need the intersection anyway, and don't care at all about wether an intersection is a rectangle. That's why I think that statements like "OO is good/bad for shapes" is nonsense - you need to know what a system is supposed *to do* to decide wether and how to use an implementation technique like OO. If the application needs to decide wether all rectangles are green, we might actually prefer Prolog... ;) Cheers, Ilja
From: Robert C. Martin on 16 Jun 2005 18:02 On Wed, 15 Jun 2005 19:03:45 GMT, <adaworks(a)sbcglobal.net> wrote: >The Von Neumann model, while useful >in the past, will eventually be regarded with the same regard we now give >to pre-Copernican cosmology. To amplify this point, it is very important that we view ourselves as pre-Copernican. We know little, and our models are wrong, but without those wrong models, progress can't be made. Ptolemy may have been dead wrong with his cosmology, but we owe him a huge debt. We are the Ptolemys if this age. We are probably dead wrong, but future developers will owe us that same debt. ----- 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:11
On Wed, 15 Jun 2005 19:52:11 +0100, Miguel Oliveira e Silva <mos(a)det.ua.pt> wrote: >"Robert C. Martin" wrote: > >> On Tue, 14 Jun 2005 19:01:53 +0100, Miguel Oliveira e Silva >> <mos(a)det.ua.pt> wrote: >> >> >Although both approaches (OO and functional/procedural) are in a >> >sense dual (as you correctly mentioned), the duality is not balanced >> >at all. An ADT need not to know all of its methods possible >> >implementations (it may even not know one!). On the other hand, >> >the "switch" alike method approach needs to know most (if not all) >> >of the possible data types. >> >> Consider a function named "rotate()" that has a switch on shapes. >> What does this function do for circles? Nothing. > >Correct. But that decision required the knowledge (on the part >of the programmer) of the circle's semantics (hence, even the >"rotate" procedure needed to know the new circle's ADT). >how would you do that automatically as happens in the OO >approach? By adding a new function to a hierarchy, and realizing that certain derivatives can live with the defaults in the base class. Indeed, we add a do-nothing 'rotate' method to the Shape hierarchy, and purposely allow the Circle class to inherit it. Same decision made, same knowledge needed to make it. >On the other hand, if a method has enough information >to be implemented in a given class, it need not to know >what will be its possible future descendant classes (as long >as those unknown new classes respect that class's >ADT semantics and method invocation is dynamically >binded, this implementation can be automatically inherited >and reused by all of them). This is the power of OO data type >abstraction. I agree. By the same token in a procedural environment, if a data structure has sufficient data elements, it need not know what new functions may be written against it. *That* is the power of the procedural abstraction. ----- 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 |