Refactoring Logic: Separating Concerns in a Python Game Architecture

Prerequisites

To follow this walkthrough, you should have a solid grasp of basic Python syntax. Familiarity with Object-Oriented Programming (OOP) concepts like classes, initializers (__init__), and inheritance is essential. You should also understand the concept of Dependency Injection, which we use to provide the game with its interface at runtime.

Key Libraries & Tools

• Python Standard Library: No external installations are required for this refactor.
• enum: Used to define distinct game entities (Rock, Paper, etc.) as symbolic names.
• typing.Protocol: A structural subtyping tool used to define a "blueprint" for our UI, ensuring any interface we build (CLI, GUI) follows a consistent set of methods.
• random: Utilized for the CPU's move selection logic.

Code Walkthrough

1. Defining the UI Protocol

We start by creating a Protocol class. This defines what a UI must do without dictating how it does it. This is the secret sauce for decoupling.

from typing import Protocol, Dict
from enum import Enum

class Entity(Enum):
    ROCK = 1
    PAPER = 2
    SCISSORS = 3
    LIZARD = 4
    SPOCK = 5

class UI(Protocol):
    def read_player_name(self) -> str: ...
    def display_rules(self) -> None: ...
    def pick_player_entity(self) -> Entity: ...
    def pick_cpu_entity(self) -> Entity: ...
    def display_current_round(self, player_name: str, cpu_name: str, player_entity: Entity, cpu_entity: Entity) -> None: ...
    def display_tie(self) -> None: ...
    def display_round_winner(self, winner_name: str, winner_entity: Entity, message: str) -> None: ...
    def display_scores(self, scores: Dict[str, int]) -> None: ...

2. Implementing the CLI

Next, we build a concrete implementation of this protocol for the terminal. We move all print() and input() calls here. Notice how we use a helper function to format the entity choices for the user.

class CLI:
    def read_player_name(self) -> str:
        return input("Enter your name: ").strip()

    def display_rules(self) -> None:
        print("\nRules: Spock smashes Scissors, Scissors cuts Paper, etc.")

    def pick_player_entity(self) -> Entity:
        # Logic to display options and capture choice
        choice = int(input("Enter your move (1-5): "))
        return Entity(choice)

    def display_tie(self) -> None:
        print("It's a tie!")

3. Injecting the UI into the Game Class

Instead of the Game class creating its own scoreboard or printing directly, we pass the UI instance into the initializer. This makes the Game class testable and interface-agnostic.

class Game:
    def __init__(self, player_name: str, ui: UI):
        self.player_name = player_name
        self.ui = ui
        self.cpu_name = "CPU"
        # Logic no longer prints directly; it uses self.ui

    def do_turn(self):
        player_move = self.ui.pick_player_entity()
        cpu_move = self.ui.pick_cpu_entity()
        self.ui.display_current_round(self.player_name, self.cpu_name, player_move, cpu_move)
        # Winner logic follows...

Syntax Notes

• Structural Subtyping: By using typing.Protocol, we don't need to explicitly inherit from a base class. If a class has the required methods, it "satisfies" the protocol.
• Type Hinting: Explicitly defining return types (like -> Entity) helps IDEs catch bugs before you even run the code.
• Static Methods vs. Instance Methods: We moved get_username from a static method in the Game class to an instance method in the UI class because reading input is a behavioral responsibility of the interface, not a utility of the game logic.

Practical Examples

This pattern is standard in professional software development. Consider a banking application: the core logic calculates interest and processes transfers, but it shouldn't care if the request came from a mobile app, a website, or an ATM. By separating the "Business Logic" from the "Delivery Mechanism," you can swap the UI without breaking the math.

Tips & Gotchas

• Law of Demeter: Avoid "reaching through" objects. In the original code, the Game class accessed scoreboard.points_dict directly. This is high coupling. Instead, the Scoreboard should provide a method like add_point(player) so the Game class doesn't need to know how points are stored.
• Initialization Bloat: Keep your __init__ clean. If your initializer is printing rules and starting loops, it's doing too much. Use the initializer only for setting up state and move procedural logic to methods like play() or start().
• Error Handling: When converting user input to an int for the Entity enum, always wrap it in a try-except block to handle non-numeric input gracefully.