[Tutor] Calling method in parent class

[Kent Johnson]

On Tue, May 12, 2009 at 8:44 AM, Jeremiah Dodds
<jeremiah.dodds at gmail.com> wrote:
> On Tue, May 12, 2009 at 12:27 PM, Kent Johnson <kent37 at tds.net> wrote:

>> I don't agree with this at all. It's not at all unusual for a derived
>> class to override a base class method in order to add additional
>> functionality to it, then to call the base class method to complete
>> the implementation. __init__() is the most common example but not the
>> only one. I don't consider this a design flaw at all. Another way to
>> do this is for the base class method to call a hook method that
>> subclasses can define but IMO that is often more trouble than it is
>> worth.
>>
>> I don't see how you would use a decorator to do this.
>
> Can you give an example?

Sure, here are real world examples from my current work project, in C#...

Many classes define
  protected override void Dispose(bool disposing)
and call
  base.Dispose(disposing)
in the implementation. This is a fine example; the derived class has
to implement some extra Dispose() functionality and also must ensure
that the base class Dispose() is called. There are 55 examples of this
in my project so I would have to say it is common :-)

GUI classes with custom painting or resizing behaviour call the base
class method to get the common behaviour, then add their particular
extra bit such as drawing a custom highlight.

I have a class that overrides ToString() (the C# equivalent of
__str__) to provide additional output. It calls base.ToString() to get
the base class representation.

Classes with serialization methods call the base class methods to
serialize base class fields, then serialize their own fields.

etc...

> I've never seen this done, outside of __init__, in
> a way where it wouldn't be clearer if the base class's methodname was just
> named something else, and then have the Parent class's eventually overriden
> method just call the renamed method. Put the common functionality in a
> method that's not overriden.

Sure, you can write

class Base(object):
  def someMethod(self):
    self._someMethodImpl()

  def _someMethodImpl(self):
    # do something

class Derived(Base):
  def someMethod(self):
    self._someMethodImpl()
    # do something else

but I don't see that that gives any advantage over the simpler

class Base(object):
  def someMethod(self):
    # do something

class Derived(Base):
  def someMethod(self):
    Base.someMethod(self)
    # do something else

and if you don't have control over the code for Base (perhaps it is
part of a GUI framework or other third-party code) then you don't have
a choice to use the first option.

> Depending on what you need to do, you can pull out what would normally be in
> the base classes method into a decorator that calls the subclassess method
> and then does what it needs to do. I don't see this too often.

Can you give an example? I still don't see how that would work or why
it would be preferable to simply calling the base class method as in
my second option above.

Kent