Talk:Call super
From Wikipedia, the free encyclopedia
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)
