Talk:Call super

Explanation about why this is bad

a brief word about exactly _why_ this is a poor design (considering the java example given) is in order.

I don't think it is always bad: for example, if you consider the standard Java example of a BankAccount class, which has as a subclass, a SvaingsAccount. In the BankAccount, no fee is charged for withdrawls, but in the SavingsAccount a fee is charged. HEre you would have a public void withdraw(var _amount) method in the BankAccount class (where var is the chosen number type), which checks that the account has enough money in and if so, withdraws the money, and if not throws an exception. THe SavingsAccount also would have a public void withdraw(var _amount) method, in which the method code is identical excpet for the addition of the fee to the withdrawl amount, and the depositing of the fees into the banks revenue account. thus the withdraw method in the SavingsAccount class would look like:

public class SavingsAccount extends BankAccount
{
   
   ...
   
   public void withdraw(var _amount)
   {
       amount = _amount + fee; //could simply modify the formal parameter here.
       super.withdraw(amount); //invokes the superclass withdraw method
       bank.deposit(fee);      //deposits the fee into the banks revenue account
   }
   
   ...
   

}

Naturally, this is only an example, and does not worry about handling the exception mentioned above. also, var is not a Java primitive type, and was simpyl used because none of the primitves are ideal for banking.

I agree. The article does use the word "Required" to call the base method. Also the suggested solution requires your superclass be abstract. So I think this anti-pattern applies only to this situation where you have an abstract class as a super class. I think this should be mentioned in the article.

Furthermore I do this all the time so I hope its not bad.

---

Besides, this so-called 'anti-pattern' cannot be easily avoided in case when a virtual base class has more than one derived classes in depth:

 class Base
 {
    ...
    virtual bool initialize() //  e.g. lazy initialization
    {
       ...
       return true;
    }
 };

 class Derived1: public Base
 {
    ...
    virtual bool initialize()
    {
       Base::initialize();
       ...
       return true;
    }
 };

 class Derived2: public Derived1
 {
    ...
    virtual bool initialize()
    {
       Derived2::initialize();
       ...
       return true;
    }
 };

Both Derived classes can be instantiated and fully usable; although Derived2 extends Derived1's functionality in some way. There's no way to specify overriding rules in Base class to force initialization (call of initialize()) of all instances of derived classes. Also it would be plain stupid approach to add protected, virtual initX() {} stub in each class, which is meant to be overriden in the derived class, just to avoid calling Base::initialize(); even not forgetting to change initX()'s name in each incarnation! Personally, I don't see a 'Call super' as anti-pattern (it is more like an unavoidable nuisance), at least in C++, although I agree that it is sometimes difficult to tell if base::method() should be called from within Derived::method() or not.

Also presence of base::method() in a derived method is easily understood as _extension_ of behavior rather than _replacement_, which improves code readability.

Audrius u (talk) 14:15, 28 March 2008 (UTC)

Remove This Article

I'm not feeling this article. I don't think this is an anti-pattern. There is also no explanation of why it's bad, just that it's bad. The only cited link is some guy's blog, and he is complaining that the anti-pattern is complicating his testing. I move to remove this article fromst the list of anti-patterns. Clarkcol (talk) 19:15, 11 February 2010 (UTC)

As I'm understanding it, this is definitely bad design and I would consider it an antipattern. The point is that the class design says that "to use this class, you must derive a subclass, override parent::X then call the parent::X back from child::X". But the problem is that there is nothing in the language itself to enforce that the parent function is in fact called back. If on the other hand you use the pure virtual function solution, the language itself enforces the demanded code structure, so the class design cannot be violated.

If it's actually intended for that limited case, then the name is wrong, and it needs to discuss what the idea is relative to what it's not. It's not about call super at all, it's about abstract classes designed to be extended by the call super pattern. Sort of like the difference between exceptions and expection. Insofar as it's meaningful, I vote delete, but would accept a rename. ― Darekun (talk) 00:20, 23 November 2010 (UTC)

Actually, it is necessity in some cases, like propagation of the signal through widgets. The derived widgets re-implements, for example, keyboard event. It reacts only on the specific key, let assume key 'A', and for all other keys calls the ::keyboardEvent() from the superclass. — Preceding unsigned comment added by 195.144.15.195 (talk) 13:49, 24 October 2011 (UTC)

Martin Fowler is a demigod. Show some respect! :D —Preceding unsigned comment added by 144.160.98.31 (talk) 15:29, 15 February 2011 (UTC)

demigod or not, Remove This Article. If you read the only cited reference, it contradicts the premise of the article itself. This is supposedly describing something that is bad practice because, to quote the reference, "... The documentation says something like 'to do your own thing, just subclass the process method. However it's important to remember to start your method with a call to the super-class'" and this is perceived as bad - that there is a convention that must be followed in an API. Then toward the end of the reference a solution is proposed that has precisely this property. In order to override runBare the API documentation would need to state that "its important to call setUp" and thus we have gone in a circle of logic and are worse off than when we started. The code and _convention_ for AlphaTestCase is more complicated than the original problem described in the first paragraph. The "code smell" of AlphaTestCase is far worse than the original supposed problem - its a mess. By the time we get to the bottom of the only cited reference, its very clear that the argument falls apart. The described pattern is necessary and useful in many situations and does not "smell". This article should be removed because its misleading in that it purports to define a bad programming pattern without providing a basis for the claim. Whether the described pattern is good or bad is completely subjective. At minimum suggest revising it to show where it would be needed, and as the reference nicely demonstrates, where there is no alternative. 108.3.156.205 (talk) 06:45, 6 January 2013 (UTC)