This commit refactors the task tracker application to adhere to the
Single Responsibility Principle (SRP). The original single-file or
less structured code has been broken down into four distinct classes,
each with a single, well-defined responsibility:

- Task.java: Represents the Task data model, encapsulating task
  description and completion status. Its sole responsibility is to
  hold task information.

- Task_Tracker.java: Manages the collection of Task objects. Its
  responsibilities are purely related to business logic: adding tasks,
  marking tasks as complete, and providing access to task data.
  Console output has been removed from this class.

- TaskConsoleView.java: Handles all console-based user interface
  interactions related to output. This includes displaying the menu,
  rendering the task list, and showing informational messages or prompts.

- TaskTrackerApp.java: Serves as the application's entry point and
  controller. It manages the main application loop, handles user input
  (via Scanner), and orchestrates the interactions between the
  TaskTracker (model) and TaskConsoleView (view).

This separation improves code modularity, enhances testability for each
component, and increases maintainability by ensuring that changes to
one aspect (e.g., UI presentation) are less likely to impact other
unrelated aspects (e.g., task management logic).

Decompose the monolithic 'reservation.java' class into multiple,
more focused classes to adhere to the Single Responsibility Principle (SRP).
This refactoring aims to improve modularity, testability, and
maintainability of the codebase.

Key changes include:

-   **Feat: Introduce Passenger entity class**
    Created `Passenger.java` to encapsulate all data related to a single
    passenger (e.g., number, name, age, phone, ticket class). This
    replaces the multiple parallel arrays previously used.

-   **Feat: Implement TicketService for business logic**
    Created `TicketService.java` to handle all core business logic
    concerning ticket operations. This includes:
    - Ticket booking and availability checks.
    - Ticket cancellation and refund calculations.
    - Passenger search functionality.
    - Management of ticket counts per class.

-   **Feat: Develop ConsoleUI for user interaction**
    Created `ConsoleUI.java` to manage all console-based input and output.
    This class is now solely responsible for:
    - Displaying menus and application headings.
    - Gathering user input for various operations.
    - Presenting information, results, and error messages to the user.

-   **Feat: Create ReservationApplication for orchestration**
    Introduced `ReservationApplication.java` to act as the main
    application driver. It initializes and coordinates the `ConsoleUI`
    and `TicketService` components, and manages the main application loop
    and control flow.

-   **Refactor: Remove original 'reservation.java' class**
    The responsibilities of the old `reservation.java` class have been
    distributed among the new classes, making it obsolete.

This restructuring leads to a more organized codebase where each class
has a clear and single purpose, making future development and
maintenance significantly easier.

This commit refactors the Patience Solitaire game to better align
with the Single Responsibility Principle (SRP). The primary goal was
to separate core game logic from user interface concerns, leading to
a more modular, testable, and maintainable codebase.

Key changes include:

1.  **`PatienceGame` Class (Game Engine):**
    * Removed all direct console input (`Scanner`) and output (`System.out.println`).
    * Methods performing game actions (e.g., `moveCard`, `drawCard`, `moveUncoveredCardToSuit`) now return boolean status or appropriate values instead of printing messages.
    * The `playGame()` game loop and `displayGameState()` methods were removed.
    * Added getter methods to allow external classes (like the UI) to access game state information.
    * The `main()` method was removed.
    * Refined card movement logic (e.g., `canMoveCardToLane`, `moveMultipleCards`) to rely on return values and internal state checks.

2.  **`GameConsoleUI` Class (New - Console User Interface):**
    * Created to handle all console-based user interactions.
    * Manages the main game loop (`start()` method).
    * Contains `Scanner` for user input and uses `System.out.println` for all output.
    * Implements `displayGameState()` to render the game board and status.
    * Parses user commands and invokes corresponding methods on the `PatienceGame` instance.
    * Handles displaying error or success messages based on return values from `PatienceGame`.
    * Includes logic for `initializeLaneCards()` to correctly set up the tableau with face-up/face-down cards at the start.

3.  **`Application` Class (New - Entry Point):**
    * Created to serve as the main entry point for the application.
    * Its `main()` method initializes `PatienceGame` and `GameConsoleUI` instances and starts the game.

4.  **`Card` Class:**
    * Added a `faceUp` boolean property and associated `isFaceUp()`, `setFaceUp()` methods to represent card visibility in Solitaire.
    * Enhanced `toString()` to display cards differently based on their `faceUp` status (e.g., "[XX]" for face-down).
    * Reviewed and ensured methods like `isOneValueHigher` and `isOppositeColor` correctly support game rules.

Benefits of this refactoring:
-   **Improved Modularity:** Game logic is now independent of its presentation.
-   **Enhanced Testability:** `PatienceGame` can be unit-tested without UI dependencies.
-   **Increased Maintainability:** Changes to UI do not affect game logic, and vice-versa.
-   **Flexibility:** Easier to introduce new UIs (e.g., GUI, web) in the future by creating new UI classes that interact with the existing `PatienceGame` engine.

Separated concerns into multiple classes to adhere to the Single
Responsibility Principle:

- UserData: New DTO to hold user input.
- UserInputHandler: Handles all console input operations and
  basic input validation.
- CalorieCalculator: (Formerly CalorieCalculationService) Now solely
  responsible for BMR and daily calorie needs calculations.
  Contains all business logic for these computations.
- ResultDisplay: Manages formatting and display of calculation
  results to the console.
- MainApp: Orchestrates the application flow, coordinating between
  the input, calculation, and display components.

This refactoring improves modularity, testability, and maintainability
of the codebase. The original CalorieCalculator class, which previously
handled multiple responsibilities (UI, validation, calculation), has
had its calculation logic extracted into the new, focused
CalorieCalculator class, and its other responsibilities moved to
UserInputHandler, ResultDisplay, and MainApp.

Decompose monolithic Game class into multiple specialized classes
to adhere to the Single Responsibility Principle. This improves
modularity, testability, and maintainability.

Changes include:

-   **GameWindow.java**: New class to manage the main JFrame, application
    setup, and includes the `main` method. Replaces GUI setup aspects
    of the original Game class.

-   **GameManager.java**: New class responsible for all game logic,
    state management (score, game over, entity states), game loop timers,
    and collision detection. Extracts core game mechanics from the
    original Game class.

-   **GamePanel.java**: Refactored from `DrawPanel`. Now solely responsible
    for rendering all game elements (dinosaur, cacti, environment,
    UI text) based on data from GameManager. Drawing methods moved
    here from the original Game class.

-   **Dinosaur.java**: New entity class to manage the state and behavior
    (e.g., jump logic) of the player's dinosaur.

-   **Cactus.java**: New entity class (replaces inner class `MyGraph`) to
    manage the state and properties of cactus obstacles.

-   **InputHandler.java**: New class dedicated to processing keyboard inputs
    and translating them into game actions for GameManager. Replaces
    KeyListener implementation in the original Game class and input
    action in DrawPanel.

-   Removed direct drawing, game logic, and input handling responsibilities
    from the original Game class structure. The `Game.unit` constant
    is temporarily kept but should ideally move to a Constants class or
    relevant configuration.

This refactoring makes each component of the game more focused,
easier to understand, test in isolation, and modify without
impacting unrelated parts of the system.