wiki:DesignPatterns

Design Patterns (in Java)

Overarching Structural Patterns

Command-Based FRC Robot (Event-Driven)

Please see the Command Based Robot Notes for detailed information on how to implement this design pattern.

MVC (Model-View-Controller)

This pattern is concerned with the separation and cohesion of different "departments" of a project.

The model is the data required by the project. The view is the client interface, often a gui (although with respect to a robot, this is more analogous to the actuators and code representations of the mechanisms). The controller is the collection of classes that process and handle the data and make logical decisions.

Generally, these three major divisions of code are separated, both physically (as physical as 0's and 1's can get) and in the interfaces between the three:

  • The model should be protected from arbitrary access and should only be accessed through the controller.
  • The view should generally query for information updates from either the model or the controller.
  • The controller should receive information updates from the model and control the view.

Iterative Control Loop

This is the simplest pattern; it involves a set of instructions/commands being repeated over and over again until a termination command is given.

This entails that inside the loop, there cannot be anything that requires a large amount of processing power or time. Each instruction should be relatively short and not take up not. There should be no while loops, or lengthy for loops.

Arduinos, for example, use this pattern. There is usually some sort of an initialization function, as well as a periodic, or repeated function.

void init() {
  // initialization code
}

void loop() {
  // periodically repeating code
}

Communication-Related Patterns

Chain of Responsibility

This pattern is a method of processing data using multiple classes. Each class is responsible for dealing with a particular type of data or output, and passes along any data it doesn't know how to deal with to the next class(es).

See example:

public class ClawPolicy {
  /* instance variables declared; not shown */

  public void execute() {
    if (modeBtn == AUTOMATED)
      clawAlgorithmPolicy.execute();
    else if (modeBtn == MANUAL)
      clawHandler.execute();
    else
      System.out.println("[ERROR: ClawPolicy] IllegalStateException for the mode button");
  }
}

Observer/Listener Pattern

Singletons

A singleton is a class which can only ever have one instance of it, generally created by the class itself and accessed through a public accessor method.

Reasons for Making a Class a Singleton

  • class contains objects that should not be instantiated more than once
  • instances of the class require a lot of processing power, time, or other machine resources

See the following sections for various methods of implementing a singleton class in the Java programming language:

Singleton from Enum

A singleton can be written as an java enum with one constant: the instance.

public enum DatabaseAccessObject {
  INSTANCE;
  
  private DatabaseModel dm;
  private SQLConnector sqlconnect = new SQLConnector(/* arguments not shown */);

  private DatabaseAccessObject() {
    /* implementation not shown, but will take a long time with a large strain on the machine */
  }

  /* other accessor and modifier methods not shown */
  
}

Then, to access this object:

...
DatabaseAccessObject dao = DatabaseAccessObject.INSTANCE;

dao.find(/* args not shown*/);
...

Private Constructor and Public getInstance()

A singleton can also be made using a static getInstance() method and setting the constructor to private.

public class DAO {
  public static DAO instance = new DAO();

  /**
   * Time consuming and resource intensive constructor.
   */
  private DAO() {
    // implementation not shown
  }

  public static DAO getInstance() {
    return instance;
  }

  /* other methods not shown */
}

Then, to access the object:

...
DAO dao = DAO.getInstance();

dao.<some method>();
...

Input Pattern

Buttons

Please see Button editing tutorial

Abstraction Patterns

Facades

Last modified 6 years ago Last modified on Feb 5, 2015, 8:21:52 PM