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.