a5646b63c1
* Fix issue #761: ThreadSafeDoubleCheckLocking.java: Instantiating by Reflection call will be successful if you do that firstly * Create leader election module * Create Interface of Instance and MessageManager * Create implementations with token ring algorithm * Change package structure. Create basic message system. * Implement heartbeat and heartbeat invoking message system * Implement election message handler * Add leader message handler * Add main entry point * Add comments * Update README.md * Fix checkstyle issue * Add Unit Tests * Add Unit Tests * Add bully leader selection * Change System.out to log print. Add MIT license in each file. * Add More java doc comments * Add unit test * Add unit tests * Add subclass-sandbox * Add Unit Test * Add Unit Test * Fix Typo * Move dependency into parent pom.xml * Change local valuable reference to be var
layout: pattern
title: Subclass Sandbox
folder: subclass-sandbox
permalink: /patterns/subclass-sandbox/
categories: Other
tags:
- Java
- Difficulty-Beginner
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.
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.