The design of the "Expense Manager" utilizes object-oriented programming (OOP) principles through the creation and use of multiple classes, each representing distinct concepts within the system. The main classes include `Category`, `DateUtil`, `Expense`, `PEMservice`, `Report`, and `Repository`. Each class uses encapsulation by defining private fields and providing public getter and setter methods to control access to these fields, ensuring data integrity and security . Additionally, the use of constructors in classes such as `Category` and `Expense` allows for instance initialization with specific values . Furthermore, the `Repository` class demonstrates singleton design pattern principles by ensuring a single instance across the application, emphasizing efficient data management . The `Report` class uses method calls to compile financial analysis, which strengthens modular design and encourages code reuse .

Constructors in the Expense Manager application are used throughout to initialize objects with specific attributes. For instance, the `Category` class features constructors that allow for the creation of category instances either with a name or with both a name and a category ID. Similarly, the `Expense` class has constructors to initialize expense records either with or without detailed parameters like category ID, amount, date, and remark . These constructors are vital as they provide a structured way to instantiate objects with predefined default properties or customized settings, ensuring that objects are created with valid initial states. This practice enhances code readability and reliability by standardizing how objects are initialized across the application .

The encapsulation principle in the context of the `Expense` and `Category` classes is implemented by defining private fields for class properties, such as `categoryId`, `amount`, `date`, and `remark` in the `Expense` class, and `categoryId` and `name` in the `Category` class. Then, only allowing access to these properties through public getter and setter methods. This encapsulation ensures that direct access to the fields is restricted, supporting data integrity and security as modifications can only be made through controlled methods . This principle reduces the risk of unintentional data manipulation and enhances code maintainability by confining changes to specific parts of the codebase .

Control flow within the `PEMservice` class is managed through a combination of `while` loops, `switch` statements, and method calls to facilitate user interactions. The `showMenu` method runs an infinite `while(true)` loop that repeatedly presents a menu of options to the user, capturing their input using a `Scanner`. Based on the user's choice, determined by a `switch` statement, different methods such as `addCategory`, `expenseEntry`, and `expenseList` are invoked, each handling a specific function of the application. The control structure ensures that the user can navigate through various functionalities seamlessly and efficiently, while default cases handle invalid inputs by displaying appropriate feedback . This structured approach to control flow is essential for intuitive user navigation and maintaining application stability .

The `Report` class plays a central role in generating financial reports by incorporating comprehensive methods for calculating expense totals over specified periods and categories. It integrates with other parts of the application by accessing data stored in the `Repository` class to retrieve expense records. The methods `calculateMonthlyTotal`, `calculateYearlyTotal`, and `calculateCategoryTotal` systematically process the expenses list to provide detailed insights about spending patterns, segmented by time or category . Moreover, the `Report` class collaborates with the `DateUtil` class to extract and format relevant date components necessary for reporting. This strategic interaction allows the `Report` class to provide critical financial overviews that form the basis for user decision-making and budgeting strategies .

The `DateUtil` class plays a crucial role in the Expense Manager application by handling all date-related operations. It provides methods for parsing date strings into `Date` objects, formatting `Date` objects into strings, and extracting specific date components such as year and month information. This functionality is vital for ensuring expenses are entered with accurate date information and are processed correctly when generating reports, such as calculating monthly and yearly totals . The accuracy and usability of financial data significantly depend on precise date handling, making `DateUtil` integral for managing time-based financial data .

The singleton pattern applied in the `Repository` class effectively ensures that a single consistent instance of data storage is used throughout the Expense Manager application. This guarantees that all components of the application access the same instance of expense and category lists, thereby providing uniform data management and reducing errors related to data inconsistency . The advantage of this approach lies in its simplicity and efficiency, particularly in applications where centralized data management is crucial. However, potential drawbacks include limited scalability and increased complexity in testing, as the tight coupling around a single instance can complicate unit testing and hinder future extensions involving parallel data handling or modularization .

The Expense Manager application handles user inputs and potential errors through several mechanisms. Firstly, it employs the `Scanner` class for capturing console inputs, which are processed within a menu-driven interface provided by the `PEMservice` class. This class includes control flow statements, such as `switch` and `while` loops, to guide user interaction and manage expected actions . In terms of error handling, the application uses `try-catch` blocks, especially in the `DateUtil` class, to manage exceptions that occur during date parsing with `SimpleDateFormat`. When exceptions are caught, the application prompts the user to enter valid inputs, ensuring robust interaction and minimizing runtime errors .

The Expense Manager application supports financial analysis for users primarily through the `Report` class, which offers several functionalities: calculating monthly, yearly, and categorized expense totals. When users input expenses, the data is stored in a `Repository` class, which the `Report` class accesses to generate various financial summaries. These reports help users analyze spending patterns over time, assess their budgeting effectiveness, and identify areas for potential savings. Moreover, the categorization of expenses and visualization of financial data enable users to gain insightful analyses into their expenditure behaviors .

The `Repository` class ensures data consistency across the Expense Manager application by implementing a singleton pattern. This design choice guarantees that only one instance of the repository exists at any given time, which centralizes data management and prevents data discrepancy issues. The singleton repository holds lists of `Expense` and `Category` objects, making sure all operations performed by the application access the same data sources, thus maintaining accurate and consistent data throughout the application. Additionally, having all category and expense data stored in the repository facilitates easy retrieval and modification, which is crucial for report generation and user interactions .