Talk:Call super

This is done quite commonly and I'm not sure if it's such a bad thing. I can see how it can cause problems, especially if you are subclassing classes that you haven't written yourself or maybe even don't have access to the source for. In that case, it may be hard for you to know whether or not you have to call the overridden method.

However, in a class hierarchy that is all written by the same team of developers I don't really see an issue with requiring a call to the overridden method, as long as this requirement is properly documented.

It is possible that it depends on your view of classes and objects and the encapsulation boundary. If you think in terms of class encapsulation (i.e. the encapsulation boundary is around the class) it makes little sense to require calling an overridden method in another class. However, if you think in terms of object encapsulation, the superclass' data and behavior is an intrinsic part of the final object and it doesn't really seem like a bad thing to have to call another one of your own methods. -- Janina Voigt

Additionally, I don't think the Template method could be used if you have a class hierarchy deeper than two levels. Take for example a class BoxView which has a draw method that draws a box. If it's only going to ever have classes at a depth of one below it, the Template method could potentially be used. However if it has a subclass GridView which draws a grid inside the box (thus needing to call the BoxView's draw method), and GridView in turn has a subclass BattleshipView which draws ships on top of the grid, the Template method wouldn't work (you'd need a different method for each level in the inheritance hierarchy). Another example would be in languages where memory management is done manually. Each class will likely have some kind of release method which will need to call the release method on its superclass. Again, the inheritance hierarchy could be arbitrarily large. Constructors are similar. Some languages hide the details (eg implicitly calling the superclass's method and having the constructor named differently for each class) but it's essentially still the same. --Stephen Fitchett 08:13, 22 July 2009 (UTC)

While it is true that problems may manifest if a programmer subclasses and does not call the super constructor I do not think this is an issue. A programmer can also override methods poorly and introduce errors but we accept that risk. What makes this case special? If the class is documented and the documentation is followed then there won't be a problem. TL:DR - Sure it introduces a point of failure but for the utility it provides it is worth it. --AlexGee 21:57, 23 July 2009 (UTC)

I would say that Call Super is something you should be concerned about if you do not subscribe to DBC, if you do, it is a natural solution. The alternative is to have the superclass provide an abstract method that is called by a concrete method in the same abstract superclass. This seems nasty and more prone to failure as one might try to override a superclass' concrete method without realising the functionality it provides. --Matthew Harward 02:40, 26 August 2009 (UTC)

As Janina said there is only a problem when data is class encapsulated as ‘setup operations are internal to the superclass’. One solution could be to not have the data class encapsulated, have it object encapsulated if the language allows. Then on the other hand JUnit wouldn’t be such a neat framework if it didn’t use class encapsulation. --BenMcDonald 03:54, 26 August 2009 (UTC)