Method Overriding vs Method Calling – Understanding the Commitment

apicompositioninheritanceobject-oriented

From : http://www.artima.com/lejava/articles/designprinciples4.html

Erich Gamma: I still think it's true even after ten years. Inheritance is a cool way to change behavior. But we know that it's brittle, because the subclass can easily make assumptions about the context in which a method it overrides is getting called. There's a tight coupling between the base class and the subclass, because of the implicit context in which the subclass code I plug in will be called. Composition has a nicer property. The coupling is reduced by just having some smaller things you plug into something bigger, and the bigger object just calls the smaller object back. From an API point of view defining that a method can be overridden is a stronger commitment than defining that a method can be called.

I don't understand what he means. Could anyone please explain it?

Best Answer

A commitment is something that reduces your future options. Publishing a method implies that users will call it, therefore you can't remove this method without breaking compatibility. If you'd kept it private, they couldn't (directly) call it, and you could some day refactor it away without problems. Therefore, publishing a method is a stronger commitment than not publishing it. Publishing an overridable method is an even stronger commitment. Your users can call it, and they can create new classes where the method doesn't do what you think it does!

For instance, if you publish a clean-up method, you can ensure that resources are properly deallocated as long as users remember to call this method as the last thing they do. But if the method is overridable, someone might override it in a subclass and not call super. As a result, a third user might use that class and cause a resource leak even though they dutifully called cleanup() at the end! This means that you can no longer guarantee the semantics of your code, which is a very bad thing.

Essentially, you can no longer rely on any code running in user-overridable methods, because some middleman might override it away. This means that you have to implement your clean-up routine entirely in private methods, with no help from the user. Therefore it's usually a good idea to publish only final elements unless they are explicitly intended for overriding by API users.

Related Solutions

API Error Handling – Ensuring a Method is Called Only Once

The first thing to do is to write a flag to disk before you start the transaction to indicate that this month's transaction has been attempted. That way you never accidentally call the API twice.

In the case of any kind of error, you need to make sure the system notifies a human (e.g. send an email) who can verify the transaction status and offers them a way to manually reprocess the transaction.

After a few months you'll discover either (a) The humans are bored of being contacted and you need to redesign the system (e.g find a way to automate the check/retry via the API) or (b) The system is running smoothly and everyone's happy. Hopefully (b).

Python – Can a Method That Must Be Overridden Be Private?

Pythonically speaking, you should utilize the Abstract Base Class module to implement this functionality.

Example:

from abc import ABCMeta, abstractmethod

class MyBaseClass(object):

    __metaclass__ = ABCMeta

    @abstractmethod
    def f(self, *args):
        #"Public" method (accessible from outside of class instance)
        pass


    @abstractmethod
    def _f(self, *args):
        #"Private" method (should only be accessed from with instance)
        pass

Then this is what happens when you attempt to instantiate a subclass of MyBaseClass without overriding _f():

>>> my_base_class = MyBaseClass()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class MyBaseClass with abstract methods _f
>>> class B(MyBaseClass):
...     pass
... 
>>> b = B()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class B with abstract methods _f
>>> class B(MyBaseClass):
...     def _f(self):
...             print "foo"
... 
>>> b=B()
>>> b._f()
foo
>>>

Note that there are no programmatically "private" methods in Python. That being said, a single underscore before the name (_f()) is used to signify that the method should only be accessed internally.

Best Answer

Related Solutions

API Error Handling – Ensuring a Method is Called Only Once

Python – Can a Method That Must Be Overridden Be Private?

Related Topic