Marker Methods

In my
previous post,
I talked about abstract methods. In that post, I mentioned that
Smalltalk’s convention for abstract methods is to use ^self
subclassResponsibility in the body of the abstract method.

A method like subclassResponsibility uses a technique that I call
“marker methods.” It may have another name that I’m not familiar
with. I chose the name because I find the idea similar to the
marker interface pattern.

A marker method is a method that does nothing other than possibly
raising an exception, but whose name communicates something about the
code that uses it. Because it is a method and not a comment, it
becomes more accessible for normal code navigation and refactoring
tools. This is especially important in Smalltalk, because the code
searching tools are so much more powerful than the general text
searching tools.

Smalltalk has another such marker method in the base image,
shouldNotImplement. shouldNotImplement is used when a method is
inherited from a base class, but really shouldn’t be sent to the
subclass. In my opinion, using shouldNotImplement indicates an
improper use of inheritance because it violates the
Liskov Substitution Principle.
However, it is sometimes necessary due to other tradeoffs in the
design.

I’ve added other marker methods in my own code. The two most common
are todo: and testDriveThis. I use the former to capture notes
about things I want to come back and clean up. I can search my
Smalltalk image for senders of todo: and find everything I marked
this way.

I use testDriveThis when doing outside-in test-driven development.
As I’m working at the outer layers, I’ll mock or stub out the inner
layers. Because my
DoubleAgents library
requires the mocked or stubbed method to exist, I’ll create the method
I need with a ^self testDriveThis implementation. I can then search
for senders of testDriveThis to figure out where to go next.

Marker methods are very handy for a number of uses, both temporary and
permanent. Feel free to create some of your own if you find a need
for them. As with subclassResponsibility, turning an ad hoc
implementation into a convention that is followed regularly can be
very powerful.