The addition of transaction history logging would enhance the system's functionality by providing a record of all deposits, withdrawals, and loan applications, which would be essential for audit trails and user transparency. It would allow customers to track their financial activities accurately and help resolve disputes by providing evidence of past transactions. Implementing multiple account support would align the system more closely with real-world banking practices, enabling users to manage more than one account, such as a savings and a checking account, under a single user profile. This feature would improve user convenience and system adaptability, expanding its applicability and user base .

Virtual functions are significant in the Banking Management System's implementation because they facilitate polymorphism, which allows the system to determine at runtime which method to invoke based on the object's actual type. By using a virtual function declared in the base class Account and overridden in subclasses like Savings Account, Checking Account, and Business Account, the system can seamlessly switch between different account-specific operations without modifying client code. This enhances flexibility and code maintainability, as adding new account types requires minimal changes to existing code. Thus, virtual functions enable dynamic method resolution, making the system adaptable to various account-specific needs and behaviors .

The key object-oriented principles applied in the design of the Banking Management System include classes, encapsulation, inheritance, polymorphism, and composition. Classes and encapsulation are used to organize the code by creating specific classes such as Account, Savings Account, Checking Account, and Business Account, where each stores relevant customer details. Inheritance is implemented by having different account types inherit from a base class, Account, which allows the system to apply specific rules for each account type. Polymorphism is facilitated through virtual functions, enabling the correct method to run based on the account type. Composition is demonstrated in the BankSystem class, which contains Account* and LoanApplication* objects, indicating a has-a relationship necessary for managing accounts and loans. These principles together support modularity, code reuse, and extensibility, enhancing the system's robustness and adaptability .

Maintaining stable pointer values using lists was preferred over vectors for the account storage mechanism because lists, specifically doubly linked lists, retain stable pointers throughout operations like insertions and deletions. This stability is crucial in a polymorphic system where objects are accessed through base class pointers. In contrast, vectors, which provide random access, can reallocate memory and thus alter pointer stability during resizing operations. As the system extensively utilizes account and loan operation sequences, stable pointers ensure consistent access to these objects, contributing to system stability and reducing complexity associated with pointer invalidation. The system's design does not require random access, which further aligns lists as a more suitable choice than vectors .

During the development of the Banking Management System, several challenges were encountered. One issue was the login system freezing when entering the wrong password due to a lack of an exit condition in the loop. This was addressed by correctly implementing an exit strategy for erroneous input. Another challenge was accessing private variables like balance from child classes, revealing a misunderstanding that led to the need for protected or setter functions instead. Errors were often due to small mistakes, such as missing header files or incorrect file names, which were resolved through thorough reviews. Initially planned features like hashing passwords for protection and recording transactions had to be scrapped due to time constraints, prioritizing core functionalities such as account and loan management .

The assumption made regarding administrator access is that administrators are trusted users, implying that the system does not implement authentication or login restrictions. This means the system assumes only authorized administrators will access features like loan approval and account management. The potential risks of this assumption include unauthorized access if the system falls into the wrong hands, as there are no safeguards such as authentication protocols to verify user identities. Without an adequate access control mechanism, there's an increased risk of data breaches or misuse of sensitive information, which could undermine the security and integrity of the banking system .

The document justifies the use of a list, specifically a doubly linked list from the C++ library, as the main data structure due to its efficiency in insertion and deletion operations. These operations execute efficiently throughout the list without disturbing other elements, which is vital for applications that frequently alter account or loan sequences. Additionally, the use of the list::sort() method aligns with the system requirements for sorting without manual sorting logic. Moreover, the stability of pointer values in the list helps work with polymorphic base class objects like Account*. The system relies on iteration for display functions and searches, which suits the list better than alternatives like vectors that are more suited for random element access .

The developer considered two main improvements: implementing transaction history logging and multiple account support. Transaction history logging would address limitations by maintaining a record of financial activities, thereby increasing transparency, accountability, and aiding in resolving disputes by providing historical transaction data. Multiple account support would address the system's limitation of allowing only one account per customer by enabling users to hold multiple accounts like savings and checking. This would align the system closer to real-world banking practices and expand its capability to meet diverse user needs, thereby enhancing the system's practicality and appeal to a broader user base .

Merge Sort is considered more suitable than Quick Sort and Bubble Sort within the Banking Management System because it operates effectively without the need for random access, which aligns well with the properties of linked lists. Unlike Quick Sort, Merge Sort can maintain stability, meaning that equal elements retain their order relative to each other, which is desirable for sorting linked list-based structures. Furthermore, Merge Sort offers improved performance over Bubble Sort, especially in terms of efficiency on larger datasets. Its choice is primarily reasoned by the absence of a requirement for random access, thus making it more maintainable and efficient for the system's needs, which involve frequent sorting operations by customer name and balance .

The assumption of "One Account per Customer" simplifies the design of the Banking Management System by reducing complexity in data controls and logical organization. By allowing only a single account per customer, the system avoids complications stemming from managing multiple accounts, such as ensuring correct associations and handling inter-account operations. This simplifies database schema, user interface design, and reduces potential error vectors. However, its limitation lies in not reflecting real-world banking scenarios where customers typically hold multiple accounts. This restricts user needs and system scalability, as customers might need different account types like savings, checking, and business accounts to manage their finances effectively .