Refactoring Game Logic: From Messy Classes to Pythonic Patterns

Prerequisites

To follow this tutorial, you should have a solid grasp of Python 3.10 or later. Familiarity with Object-Oriented Programming (OOP) concepts, specifically classes and inheritance, is essential. You should also understand basic Data Structures like dictionaries and tuples, and have a surface-level understanding of Dependency Injection.

Key Libraries & Tools

• Dataclasses: A standard library module that reduces boilerplate by automatically generating special methods like __init__ and __repr__.
• Enums: Provides support for enumeration types, allowing for clearer and more type-safe constant definitions.
• Random: Used for generating CPU moves through the random.choice method.
• Typing: Utilized for providing hints like Optional to clarify function return types.

Refactoring the Rules Engine

The original code used a bulky Rules class to determine winners. We can simplify this by replacing the class with a constant dictionary and a single function. By mapping a tuple of moves to a verb (e.g., "crushes" or "vaporizes"), we eliminate redundant data storage.

RULES = {
    (Entity.ROCK, Entity.SCISSORS): "crushes",
    (Entity.SPOCK, Entity.ROCK): "vaporizes",
    # ... other rules
}

def get_winner(e1: Entity, e2: Entity) -> tuple[Entity | None, str]:
    if e1 == e2:
        return None, "It's a tie"
    if (e1, e2) in RULES:
        return e1, f"{e1} {RULES[(e1, e2)]} {e2}"
    # Logic for reverse check here

This functional approach moves the "tie" responsibility out of the main game loop and into the rule logic where it belongs. It also allows the use of modern Python type hinting (like | for union types) instead of importing Union or Tuple from the typing module.

Implementing Dataclasses and Dependency Injection

The Game class initializer was previously overloaded with setup logic. By converting it to a Dataclasses, we define the state clearly and use Dependency Injection to pass in the Scoreboard and UI objects. This makes the code easier to test since we can now inject "mock" versions of these objects.

from dataclasses import dataclass

@dataclass
class Game:
    scoreboard: Scoreboard
    ui: UI
    player_name: str
    cpu_name: str = "CPU"

    def play(self, max_rounds: int = 5):
        # Logic moved from __init__ to here
        self.scoreboard.register_player(self.player_name)
        self.scoreboard.register_player(self.cpu_name)

Adhering to the Law of Demeter

To avoid "reaching through" objects—such as the Game class directly modifying scoreboard.points—we implement helper methods. A win_round method in the Scoreboard class hides the implementation details of how scores are stored. Similarly, adding a to_display method to the Scoreboard ensures that the Game class doesn't need to know the internal structure of the points dictionary to show results.

Syntax Notes: String-Based Enums

While Auto integers are common in Enums, they are brittle if the order changes or if data is persisted in a database. Switching to string-based values provides more control over the output and improves readability when debugging.

class Entity(str, Enum):
    ROCK = "Rock"
    PAPER = "Paper"
    
    def __str__(self):
        return self.value

Tips & Gotchas

• The Underscore Pattern: When iterating through a loop where the index isn't needed (like a round counter), use _ to signal to other developers that the variable is intentionally unused.
• Input Validation: When converting string Enums back to list indices for user selection, always subtract one from the user's input to align with zero-based indexing.
• Coupling Balance: While moving the display logic into the Scoreboard avoids a Law of Demeter violation, it introduces a slight coupling between the Scoreboard and the UI protocol. This is usually an acceptable trade-off for cleaner high-level logic.