Derek L. Seitz
43f6c3b6f2
|
||
|---|---|---|
| .vscode | ||
| bin/bankAcctApp | ||
| src/bankAcctApp | ||
| README.md | ||
| bank-account-app.jar | ||
README.md
Banking Application with GUI Frontend in Java
Table of Contents
- Banking Application with GUI Frontend in Java
- Table of Contents
- Introduction
- Scenario:
- Application Architecture & Components
- Functionality & Rationale
- Running Application Screenshots & Demo
- Potential for Scalability & Future Enhancements
- Project Issues & Lessons Learned
Introduction
The Banking Application with GUI Frontend is a four-phase project designed to create a simple yet functional banking application. Users can make deposits and withdrawals from checking and savings accounts, with transactions displayed in real-time.
This project incorporates core object-oriented programming principles, such as inheritance and polymorphism, by utilizing an abstract superclass to manage account types. Encapsulated data ensures sensitive information remains private and secure, while try/catch exception blocks and static methods provide robust input validation.
During the first three phases, the application employs console-based input and output. In Phase IV, the project is enhanced with a graphical user interface (GUI) frontend to improve usability and user experience.
Scenario:
-
Phase I: Creating the Initial Classes
The initial phase of this project provides the capability to manually input data for new bank customers.The application uses a sentinel-controlled loop in the test class to create instances of the Customer class. Static methods from the DataEntry class are used to collect and validate user input before assigning to the Customer class instance variables by way of setter methods. Once all customer data has been collected, validated, and assigned to instantiated variables, the corresponding getter methods are called by the BankAccountApp test class to display the collected data in a formatted report.
-
Phase II: Adding an Abstract Superclass & Input Data Validation
Phase II in the project focuses on adding the capability to create generic bank accounts (e.g., checking and savings), and enhancing the validation of the manually input data. A new class, Account, is added to the application (which will be converted to an abstract superclass in Phase III). Input validation is further enhanced in this phase by adding try/catch blocks for exception handling from improperly formatted or incorrectly entered data.
-
Phase III: Adding & Implementing Subclasses
Expanding on the functionalities of the previous two phases, Phase III adds the capability for creating both checking and savings* accounts for customers. The Account class is converted to an abstract class, and two subclasses are created: CheckingAccount and SavingsAccount. Also, since different withdrawal and deposit rules exist for each account type, the AccountInterface interface will provide abstract methods for transactions and balance checking. Lastly, logic is added to ensure that all transactional and account input is properly validated before being stored by the appropriate subclass.
-
Phase IV: Adding a GUI Frontend
The final phase of the project, Phase IV, creates a graphical user interface (GUI) to replace the console interface. The GUI is created using Swing classes to include JFrames, JPanels, and other GUI components. This GUI uses a combination of BorderLayout, GridBagLayout, and FlowLayout to manage the GUI's layout design.
Application Architecture & Components
The application follows a modular design to provide clearly-defined separation of concerns, as well as to promote code reusability. Each component is designed to handle a specific responsibility, making the application more maintainable and scalable. This approach improves readability, security through encapsulation, and flexibility for future enhancements.
-
DataEntry Class
The DataEntry class provides static methods for collecting user input (such as customer and account information, transactional data) and validating it. In Phases I - III, the test class (BankAcctApp) passe arguments to the DataEntry class when calling a specified method. The method uses those arguments as the user prompt and values the user's input is matched against. The method then compares the input against strict validation rules. If the input is invalid, do-while loops provide an error, prompting the user to correct the input and try again. In Phase IV, with the addition of the GUI, additional validation methods were implemented. While the CLI version's validation methods remained in the DataEntry class, the GUI utilized Regular Expression (Regex) patterns was incorporated, enhancing the validation engine and making it more robust.
-
Customer Class
The Customer class is responsible for securely storing customer information and providing access through getter and setter methods. Private instance variables are populated with data passed by the BankAcctApp or BankAcctAppGUI classes. The class also overrides the inherited toString() method to return a formatted string representation of the customer’s details. This formatted data is used for generating reports in the CLI or displaying information in the GUI.
-
BankAcctApp Class
The BankAcctApp class serves as the application's primary orchestrator. It creates instances of the Customer and Account classes, assigns data to their instance variables, and stores them in an ArrayList for efficient management. This design allows the application to handle multiple customers and accounts dynamically. The class interacts with the Customer and Account classes through setter methods, ensuring encapsulated data integrity while enabling features like report generation and transaction handling.
-
Account Abstract Superclass
In Phases II, the Account class provides the getter and setter methods for storing and retrieving account information. The functionality of this class is enhanced in Phase III, however, when it is converted into an Abstract Class and the CheckingAccount and SavingsAccount subclasses are added. The (now) abstract Account class provides inheritance to the subclasses and serves as a blueprint for shared functionality and structure. It defines common properties and behaviors for all account types, such as account number, balance, and transaction methods, while leaving the implementation of specific behaviors, like withdrawal rules or interest calculations, to the subclasses. This approach ensures code reuse and enforces a consistent structure across all account types.
-
CheckingAccount & Savings Account Subclasses
The CheckingAccount and SavingsAccount subclasses inherit from the Account abstract class and implement specific transaction rules and fees. Both subclasses handle deposits and withdrawals while sharing safeguards to prevent overdrafts and incorrect interest application.
- Transaction Fees: Each subclass charges a fee for every transaction, including deposits and withdrawals. The fees vary based on account type, with CheckingAccount having lower fees to support frequent transactions and SavingsAccount charging higher fees to promote saving.
- Shared Rules: Logic is implemented to prevent overdrafting savings accounts and to ensure no interest is applied to account balances of $0 or less.
These subclasses provide distinct account management features while adhering to shared principles of financial security and error handling.
-
AccountInterface Interface
The AccountInterface serves three key purposes: 1. Enforce encapsulation by defining a consistent interface for interacting with account objects. 2. Promote flexibility by allowing for the addition of new transaction types (e.g., transfers between accounts, fee deductions) and integration with other components. 3. Enhance modularity by providing a standardized set of methods for all account types, improving code reusability." These are discussed in greater detail in the Potential for Scalability & Future Enhancements section.
-
BankAcctAppGUI Class
The BankAcctAppGUI class is responsible for implementing the graphical user interface (GUI) introduced in Phase IV. It utilizes Java's Swing library, incorporating JFrame for the main application window and JPanel for creating distinct sections within the interface. FlowLayout, BorderLayout, and GridBagLayout are implemented to position GUI components in an intuitive manner. The GUI leverages the enhanced data validation engine from the DataEntry class to ensure data integrity and security. This class facilitates user interaction with the application through a more visually appealing and user-friendly interface. More details and screenshots are provided in the Functionality & Rationale and Running Application Screenshots & Demo sections below.