I am writing Java code to simulate a supply chain. The supply chain can be simulated in either an intermediate stocking or a cross-docking configuration. So, I wrote two simulator objects IstockSimulator and XdockSimulator. Since the two objects share certain behaviors (e.g. making shipments, demand arriving), I wrote an abstract simulator object AbstractSimulator which is a parent class of the two simulator objects.

The abstract simulator object has a method runSimulation() which takes an input parameter of class SimulationParameters. Up till now, the simulation parameters only contains fields that are common to both simulator objects, such as randomSeed, simulationStartPeriod and simulationEndPeriod. However, I now want to include fields that are specific to the type of simulation that is being run, i.e. an IstockSimulationParameters class for an intermediate stocking simulation, and a XdockSimulationParameters class for a cross-docking simulation.

My current idea is take the method runSimulation() out of the AbstractSimulator class, but to put a runSimulation(IstockSimulationParameters) method in the IstockSimulator class, and a runSimulation(XdockSimulationParameters) method in the IstockSimulator class. I am worried however, that this approach will lead to code duplication.

What should I do?


Currently, the AbstractSimulator class defines the runSimulation method which calls other abstract methods that are only defined by the concrete child classes.

public abstract class AbstractSimulator {
    public void runSimulation(SimulationParameters params) {
        int startPeriod = params.startPeriod;
        int endPeriod = params.endPeriod;
        for (int t = startPeriod; t < endPeriod; ++t) {
    protected abstract void submitReports(int t);
    protected abstract void makeShipments(int t);

One of the differences between the IstockSimulator and the XdockSimulator is that in an intermediate stocking configuration, tier 3 facilities submit reports to tier 2 facilities, while in a cross-docking configuration, tier 3 facilities submit reports to tier 1 facilities. Thus the IstockSimulator and the XdockSimulator have their own implementations of the methods submitReports and makeShipments.

What worked for me

Thank you for your answers. Inspired by your answers, and after sleeping it over, I came up with my own answer based on refactoring. See below.

  • What programming language?
    – user22815
    Jun 5, 2014 at 21:29
  • Edited to include detail that I am programming in Java. Jun 5, 2014 at 21:41
  • 1
    I guess your real question is how to enforce type checking on the concrete classes' runSimulation() methods?
    – miraculixx
    Jun 5, 2014 at 21:58
  • Indeed, I would like the concrete classes to perform type checking. Jun 6, 2014 at 13:35
  • What did you end up doing?
    – Alex
    Sep 1, 2015 at 14:31

3 Answers 3


I am worried however, that this approach will lead to code duplication.

yes, it might.

What should I do?

I suggest using generics. Like so

public abstract class AbstractSimulation<T extends SimulationParameters> {
    public void runSimulation(T parameters) {
        // common functionality
public class SimulationParameters {
   // common parameters
public class StockSimulationParameter extends SimulationParameters {
   // specific parameters
public class StockSimulation extends AbstractSimulation<StockSimulationParameter> {
    public void runSimulation(StockSimulationParameter parameters) {

// the same for XDockSimluation and XDocSimulationParameters
(... omitted for brevity ...) 

If you do this, StockSimulation.runSimulation() will only accept StockSimulationParameters instances, but not SimulationParameters:

StockSimulation stocksim = new StockSimulation();
// not OK
SimulationParamters simparamCommon = new SimulationParamters();
// OK
StockSimulationParameter simparam = new StockSimulationParameter(); 

The runSimulation() method has to be defined in the concrete classes because it uses different parameters, so it follows that it behaves differently. If you have common functionality, I would put the runSimulation() method in the concrete class with no parameters. Any common functionality like utility/helper methods can go in the abstract class. The constructor, which is already implementation-specific, accepts the parameters.

Creating a new object for each simulation, using the constructor to pass in parameters, has two benefits. First, it sidesteps the interface issue. Second, it solidifies the idea that a simulation should only be run once (it may have internal state for example, so it might not be reentrant anyway).

If you change the design this becomes the strategy pattern:

public interface SimulationParameters { ... }

public interface Simulation<T extends SimulationParamters> {
  SimulationResult runSimulation();

public class StockSimulation implements Simulation<StockParameters> {
  public StockSimulation (StockParameters p) { ... }

public class DockSimulation implements Simulation<DockParameters> {
  public DockSimulation (DockParameters d) { ... }

Then you use it like this:

Simulation s1 = new StockSimulation(new StockParameters());
Simulation s2 = new DockSimulation(new DockParameters());

You could then pass this off to an Executor or whatever else to run it, possibly in parallel. That is one of the advantages of this approach, it is very flexible.

This may avoid code duplication, and it definitely avoids polluting the interface which is I believe the real concern in your last paragraph.

Code Duplication

To avoid code duplication in the runSimulation() method, I would consider the approach of using composition to encapsulate each atomic step of a simulation in its own child object.

public interface SimulationComponent {
  void runStep(SimulationState state, ...);

Then, in your simulation class, you could have simulation components:

public class StockSimulation implements Simulation<StockParameters> {

  private final List<SimulationComponent> components;

  public StockSimulation (StockParameters p) {
    List<SimulationComponent> c = new LinkedList<>();
    c.add(new SimulationComponentImpl1());
    c.add(new SimulationComponentImpl2());
    c.add(new SimulationComponentImpl3());
    components = Collections.unmodifiableList(c);

  public SimulationResult runSimulation() {
    SimulationState state = ...;
    for (SimulationComponent c : components) {
    return state.getResult();

Without detailed information about how the simulation works I cannot say for sure exactly how this code should work, but I believe this is the correct general approach.

  • ok you've put one angle of the question in code, but how would you reduce code duplication?
    – miraculixx
    Jun 5, 2014 at 22:06
  • Break your simulation behaviour into modular classes. Share these between the two simulations and their base as appropriate. Composition > Inheritance.
    – Mr Cochese
    Jun 5, 2014 at 23:14
  • Without more information about the internals I cannot say for sure if code duplication is a concern. However, if the parameters are different for each simulation, that tells me that the execution has to be different as well. How much different, I do not know: but using other objects to compose behavior is the correct approach as @MrCochese says. You may even be able to use a decorator pattern to compose an object chain that makes the simulation "go." I will edit my answer to address this.
    – user22815
    Jun 6, 2014 at 12:37

Inspired by your answers, and after sleeping it over, I came up with a different and elegant solution which involves refactoring the code.

I define a class SupplyChain which contains information about the supply chain topology, the lead times for shipments, etc. I define two different simulator classes IstockSimulator and XdockSimulator. The replenishment policy and the simulation parameters (initial conditions) are given to the IstockSimulator at the time of its creation. Similarly for the XdockSimulator. Thus there is only one runSimulation method that takes in an input parameter of SimulationParameters.

This is what it looks like in Java code.

SupplyChain supplyChain = // create new supply chain
SimulationParameters simulationParameters = // define simulation parameters
IstockSimulator isim = new IstockSimulator(supplyChain,
    istockPolicies, istockInitialConditions);
XdockSimulator xsim = new XdockSimulator(supplyChain,
    xdockPolicies, xdockInitialConditions);

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.