A BankAccount class that encapsulates balance and exposes deposit and withdraw operations demonstrates which two SOLID principles?

Prepare for the FAST Enterprises IC Interview. Enhance your skills with flashcards and multiple-choice questions. Each question provides hints and detailed explanations. Excel in your interview!

Multiple Choice

A BankAccount class that encapsulates balance and exposes deposit and withdraw operations demonstrates which two SOLID principles?

Explanation:
The situation mainly showcases two ideas: keeping balance management as a single responsibility and using abstractions to decouple that logic from its data storage or side effects. First, by encapsulating the balance and exposing only deposit and withdraw, the class has a focused duty—to manage the account balance. That means changes to how balance is tracked or updated happen in one place, without dragging in unrelated concerns like user interface, persistence details, or business rules elsewhere. That tight focus is the essence of taking on a single responsibility. Second, if the design relies on abstractions for how the balance is stored or how notifications and other side effects are handled, the high-level balance-management code doesn't depend on concrete implementations. Injecting interfaces such as a balance storage or a notifier allows swapping out storage mechanisms or services without modifying the BankAccount class itself. This decoupling is the core idea behind dependency inversion: high-level logic depends on abstractions, not on concrete details. In practice, you’d see the BankAccount class interacting with interfaces (instead of directly coding database access or file writes) and having those implementations supplied from the outside. That combination—focused responsibility for balance management plus dependence on abstractions for supporting details—best fits the described design. Other pairings miss one of these aspects: they don’t tie as directly to the single-responsibility focus, or they rely on specifics of extension or substitution scenarios that aren’t clearly demonstrated by a simple balance-keeping class.

The situation mainly showcases two ideas: keeping balance management as a single responsibility and using abstractions to decouple that logic from its data storage or side effects.

First, by encapsulating the balance and exposing only deposit and withdraw, the class has a focused duty—to manage the account balance. That means changes to how balance is tracked or updated happen in one place, without dragging in unrelated concerns like user interface, persistence details, or business rules elsewhere. That tight focus is the essence of taking on a single responsibility.

Second, if the design relies on abstractions for how the balance is stored or how notifications and other side effects are handled, the high-level balance-management code doesn't depend on concrete implementations. Injecting interfaces such as a balance storage or a notifier allows swapping out storage mechanisms or services without modifying the BankAccount class itself. This decoupling is the core idea behind dependency inversion: high-level logic depends on abstractions, not on concrete details.

In practice, you’d see the BankAccount class interacting with interfaces (instead of directly coding database access or file writes) and having those implementations supplied from the outside. That combination—focused responsibility for balance management plus dependence on abstractions for supporting details—best fits the described design.

Other pairings miss one of these aspects: they don’t tie as directly to the single-responsibility focus, or they rely on specifics of extension or substitution scenarios that aren’t clearly demonstrated by a simple balance-keeping class.

Subscribe

Get the latest from Passetra

You can unsubscribe at any time. Read our privacy policy