Skip to main content

ā€œRock Paper Scissors OOPā€ by Damian: A project written in OOP

evaristo.cMay 12, 2025About 14 minNode.jsMermaid.jsArticle(s)blogfreecodecamp.orgnodenodejsnode-jsmermaidmermaidjsmermaid-js

ā€œRock Paper Scissors OOPā€ by Damian: A project written in OOP ź“€ė Ø

How to Become an Analytical Programmer ā€“ Solve the ā€œRock, Paper, Scissorsā€ Game 5 Ways Using JavaScript & Mermaid.js
Over the past year, Iā€™ve explored tools and practices that help developers build an analytical mindset. One recurring theme is how experienced programmers often describe understanding code as forming a mental picture ā€“ a conceptual map of the program...
How to Become an Analytical Programmer ā€“ Solve the ā€œRock, Paper, Scissorsā€ Game 5 Ways Using JavaScript & Mermaid.js
Over the past year, Iā€™ve explored tools and practices that help developers build an analytical mindset. One recurring theme is how experienced programmers often describe understanding code as forming a mental picture ā€“ a conceptual map of the program...

Damian has 3 projects on CodePen, all of them made in 2020. One of them is this game. The JavaScript code implements another variation of the "Rock, Paper, Scissors" game but with a more object-oriented approach using classes to manage the game logic, player choices, and statistics.

This is a well-organized, object-oriented version of the "Rock, Paper, Scissors" game with a clean separation of concerns (result calculation, player/computer choice, and game statistics). The use of animations and UI interactions enhances the user experience.

Key features of this project are:

  • Object-oriented design: The code is structured into classes, making it modular, reusable, and easier to maintain.
  • Interactive UI: It dynamically updates the playerā€™s and computerā€™s choices using visual cues (CSS classes) and shows animations for draws.
  • Statistics: The game tracks and updates the number of wins, draws, and losses, which are displayed in real-time.

Analysis of the Project

Quickly discovering the start and end of the workflow

This code seems more complex than what weā€™ve previously examined. But a closer look suggests certain resemblance to the previous ones, at least at a high level of generalization:

  • Again, variables and states are initialized once the project is accessed.
  • One of the variables thatā€™s initialized when the project is accessed is an instance of a class, the Game class. The instance is called newGame.
First Simple SB-Diagram of the RPS game by Damian
First Simple SB-Diagram of the RPS game by Damian

Again, we can see aspects of this workflow that coincide with what we found in the previous projects ā€“ but this time those similarities are more difficult to capture. As in the previous code, the controller pattern is prevalent in this code, but instead of being associated with an anonymous function or a global one, it is now a classā€™s module.

The instantiation of the class runs the constructor which includes the immediate assignment of click event handlers into the interface (just as with the other projects). They use a module of the class, the startGame module, as a callback function.

The (syntactic) approach that Damian chose adds additional complexities to the code in terms of scope definition. You can spot some of the complexities by realizing the need to use the JavaScript bind method in order to keep the this context of the module function the same as the one of the instance when assigned to the event.

class Game {
  constructor() {
    this.optionsImg = document.querySelectorAll('.img');
    this.optionsBtns = document.querySelectorAll('button');

    this.optionsBtns.forEach(option => option.addEventListener('click', 
                                                                this.startGame.bind(this) //see the bind here
                                                                )
                            )

    this.youWins = document.querySelector('.results > .you-win');
    this.draw = document.querySelector('.results > .draw');
    this.PcWins = document.querySelector('.results > .pc-win');

    this.stats = new Stats(0, 0, 0);

    this.render.call(this, this.stats.getStats());
  }
  ...
}

In order to represent that, I used a colored link, indicating that the game instance (through the constructor) is set to be the this context of the module.

Second Simple SB-Diagram of the RPS game by Damian
Second Simple SB-Diagram of the RPS game by Damian

Refinement

By adding the evaluation of the classes, the flow diagram gets more detailed but also more complicated.

Damian defined 4 classes for this project: Result, which was just a static method, Choice, Stats and Game:

The best way to keep the diagram simpler is not to detail all the steps of the functionalities. But since Iā€™m mentioning instances, I also felt the urgency to relate those to the corresponding class. I did it using a different line type and color.

With the diagram above, I tried to highlight some exceptional aspects of the architecture of this code. At some point, a Stats classā€™s instance will be context for the render method of the Game classā€™s instance. I added connections between classes and the workflow to indicate that the classes were used on those steps of the workflow.

OOP Encapsulation

One way to improve the SoC of your project is through encapsulation. Encapsulation is a concept usually related to OOP and itā€™s about keeping data and the methods that work with that data bundled in the same class.

This project shows efforts to achieve encapsulation:

The Stats instance it is the one that will store the data, and the methods are in accordance to its task:

class Stats {
  constructor(wins, draws, loses) {
    this.status = {
      wins: wins,
      draws: draws,
      loses: loses,
    }
  }
  getStats = () => this.status;

  refreshStats(result) {
    switch (result) {
    case "win":
      this.status.wins++;
      break;
    case "draw":
      this.status.draws++;
      break;
    case "lose":
      this.status.loses++;
      break;
    }
  }
}

The Choice instance will be dedicated to the calculation of the choices, and so it contains methods that respond to that task:

class Choice {
  constructor(yourChoice) {
    this.yourChoice = yourChoice;
    this.PCchoice = this.drawPcChoice();
  }

  getYourChoice = () => this.yourChoice;
  getPcChoice = () => this.PCchoice;

  drawPcChoice() {
    const options = ["rock", "paper", "scissors"];
    return options[Math.floor(Math.random() * options.length)];
  }
}

Finalizing the diagram and comparison to previous projects

For the final diagram of the project, I wanted to:

  • Emphasize the importance of the methods in the classes by mentioning them in their corresponding class, and
  • Indicate the apparent importance of the Stats instance in the workflow.

Here the final diagram of this project:

Final SB Diagram of the RPS game by Damian
Final SB Diagram of the RPS game by Damian

What makes this code similar to the previous ones is the following:

  • The order of the steps is very similar
  • A initial step is taken to set variables to initial stages and register an event handler function to the corresponding click events
  • This project is also imperative in its design

This project shares more similarities to the project by Brad Traversy.

  • The design of the event handler is closer to a controller pattern
  • Therefore, modularity and SoC seem to be concepts that guided the design.
  • The processing of the operations are organized according to procedural programming.

Thatā€™s where the similarities stop.

The initialization of the game is through the instantiation of a class:

const newGame = new Game();

Different to all the previous projects, the event handler / controller is now a method of the instantiated class. The method is then registered as event handler of the click events right from the constructor when the class is instantiated.

  • Modularity occurs through calling methods of instantiated classes, instead of (globally declared) functions.
  • By using the OOP paradigm, this project shows a higher level of SoC by adding encapsulation.
  • There are special cases in this code where it was required to bind to the appropriate this context. Examples are the binding of the Game class methods.
MIT Licensed | Copyright Ā© 2022-present Chan Hee Lee
Copyright Ā© 2025 evaristo.c