c150871a94
* Updated saga to JUnit 5 * Update fix for CI job in trampoline module * Updated update-method module to JUnit 5 * Upgraded to latest JUnit Jupiter JUnit 4 is not needed when using JUnit-Vintage * Reverted change to access modifier on Trampoline * Cleanup to resolve code smells * Formatting * Formatting * Migrating to JUnit5 and updating some Mockito patterns * Migrating to JUnit5 * Migrating to JUnit5 * Migrating to JUnit 5 * Formatting cleanup * Added missing scope for junit * Fixed tests that were not running previously. Co-authored-by: Subhrodip Mohanta <hello@subho.xyz>
layout, title, folder, permalink, categories, tags
| layout | title | folder | permalink | categories | tags | |
|---|---|---|---|---|---|---|
| pattern | Subclass Sandbox | subclass-sandbox | /patterns/subclass-sandbox/ | Behavioral |
|
Intent
The subclass sandbox pattern describes a basic idea, while not having a lot of detailed mechanics. You will need the pattern when you have several similar subclasses. If you have to make a tiny change, then change the base class, while all subclasses shouldn't have to be touched. So the base class has to be able to provide all of the operations a derived class needs to perform.
Class diagram
Applicability
The Subclass Sandbox pattern is a very simple, common pattern lurking in lots of codebases, even outside of games. If you have a non-virtual protected method laying around, you’re probably already using something like this. Subclass Sandbox is a good fit when:
- You have a base class with a number of derived classes.
- The base class is able to provide all of the operations that a derived class may need to perform.
- There is behavioral overlap in the subclasses and you want to make it easier to share code between them.
- You want to minimize coupling between those derived classes and the rest of the program.