85: Design Patterns: Subclass Method.

What is the subclass method design pattern? The subclass method behavioral pattern allows many different subclasses to define their own behavior while reusing common functionality from the base class. This is a simple pattern with a subtle intent and usage. It’s very much the opposite of the template method design pattern. The template method pattern defines a normal method in a base class that sets the overall structure of what the method should do and lets derived classes fill in specific details by overriding protected virtual methods. This subclass method pattern defines a pure virtual method in a base class that derived classes must override. It then provides non-virtual protected methods that offer common and useful functionality for the derived classes to use. You can use this pattern anytime you have many different derived classes that all need to implement unique but related behavior while avoiding code duplication by putting common functionality in helper methods in the base class. Putting the common behavior in one place also helps reduce coupling between each of the derived classes and the rest of the application code. The derived classes are coupled to the base class and it’s the base class that’s then coupled to the rest of the code. If you’d like to read the book that describes this pattern along with diagrams and sample code, then you can find Game Programming Patterns at the Resources page. You can find all my favorite books and resources at this page to help you create better software designs. This pattern also works well with the interpreter design pattern. You can use this subclass method pattern to define major behavior differences and the interpreter design pattern to customize the behavior with data. Listen to the full episode or read the full transcript below. Transcript The basic description says that this pattern allows behavior to be specified in subclasses using operations provided by a base class. We’ve actually finished going through all the patterns in the Gang of Four book. There’s a really good book called Game Programming Patterns by Robert Nystrom that I recommend that documents several more patterns applicable to game development. This design pattern is actually called the subclass sandbox pattern in this book. I normally don’t like renaming patterns because one of the benefits of design patterns is the common vocabulary. Just mention to another developer that you’re using the factory pattern and you’ll be understood without needing to explain further. Some patterns do have alternate names and I’ve mentioned already in episode 77 that I don’t really like the name of the observer pattern. This pattern is another example where I think the name is misleading. Subclass sandbox has a nice ring to it but that’s all. There is no sandbox. At least not in the sense that the term sandbox normally means. If you ever played with a sandbox when you were little under the watchful eye of an adult, then you probably heard many times to keep the sand inside the box. Kids naturally want to fling sand everywhere and adults cringe at the mess they’ll have to clean. In computer terms, a sandbox is a protected area that your code cannot leave. It’s used for maintaining security. And that’s where I think the name becomes misleading. This pattern has nothing to do with security. As with a lot of patterns, there’s nothing magical or special about your code if you follow this pattern. It’s really just a base class and a bunch of derived classes. Simple inheritance. Listen to the episodes 24 through 30 if you want more information about inheritance. The difference is in your intent. When you follow this pattern, it’s because you have a reason and want to establish certain relationships between your base class, derived classes, and the rest of your code. What are those relationships? In many ways, this design pa