Talk:Method overriding (programming)

From Wikipedia, the free encyclopedia

These examples are great, but I wonder if it might not be more helpful to the layreader if they were written in some sort of pseudocode (perhaps Wikicode?) instead of Python. Any thoughts?

Personally, I think Python is fine. The examples are highly readable and unlikely to confuse anyone unfamiliar with the language, as long as they are familiar with the concepts assumed by the article (e.g. what interface inheritance is).

My main concern is one that I've had for a while, and which applies to a large number of articles other than this one, which is the choice of subject matter of the examples. I recall when I was learning OOP I saw similar examples to this and my gut reaction was "so what?" The examples were highly abstract, and I didn't see how it would apply to a real program. This is very common though -- OOP examples always seem to model real-world objects. I guess it may have something to do with the paradigm's roots in simulation. I don't think the examples are as good, though, as examples of code that somebody might really use would be. I find talking about GUI code with examples of windows and specialised types of window (e.g. buttons) more useful.

I'm not going to go and rewrite a load of examples without consensus, though. JulesH 19:49, 12 May 2006 (UTC)

[edit] Merge of CallSuper

Not sure if this is the best place to put it, but the current article CallSuper really shouldn't be an article of its own. I'd say it belongs here because it discusses explicity calling overridden methods. It also seems to imply that doing so is a design flaw, although I really have no idea why.

Any comments? JulesH 19:49, 12 May 2006 (UTC)

In response to JulesH, I don't think CallSuper is referring to calling overridden methods in general. It's referring to calling the base class' version of a method from a subclass that has overridden the method. Something like this (Java):

   public void doSomething() {
       super.doSomething();
       doOtherThings();
    }

This could be considered bad design because of the Coupling between the parent and base class. This could cause unexpected results if the base class' doSomething() method were changed in the future. If this happens a lot in the subclasses, perhaps the methods need to be refactored to more elegantly handle the problem (something like Template method pattern).

I don't think this should be merged, since CallSuper is referring to a particular recurring problem in a specific case of method overriding, and is linked from the Anti-pattern page as well. Method overriding (programming) is not about this, but is a general description of the object-oriented paradigm.

DrSkrud 12:30, 8 June 2006 (UTC)

[edit] Terrible Example

The relationship between the derived class and the base class is erroneous. In the example, a Baby supports almost none of the actions of a Person, therefore by this definition a Baby is NOT a Person. Throwing 'not supported' exceptions in virtual methods is a terrible idea. Don't inherit from a class if you are not ONE_OF that class. A virtual method might throw a 'not implemented yet' exception, but in this example Baby simply breaks the IS_A relationship with Person. -FWIW

Where is this code coming from? Based on your description above, it appears Baby is an Abstract Person, which can't be instatiatied. 203.20.153.128 01:10, 3 July 2006 (UTC)

I was referring to the Person/Baby example given in the page. In that example, Baby is a non-abstract class deriving from Person. My opinion is that given the semantics of the example, a Baby is not a person (regular or abstract), therefore it should not derive from it. A better example would be, for instance, Athlete (instead of Baby). -FWIW.