银行系统界面设计 - 采访[关闭]

Question

我的背景：我是一名应届毕业生，正在寻找软件行业的工作。 问题：我最近接受了一家软件公司的采访，并被要求为一个银行系统绘制 UML 图，该图显示了 2 个帐户，例如储蓄和检查，他们有不同的计算利息的方式。

我的解决方案：我将 Account 类设为抽象类。
像这样： public abstract class Account{ ...... } 此类在其中定义了 2 个方法 deposit() 和withdraw() 对任何帐户类型都是通用的。 另一种方法 CalculateInterest() 是抽象方法。

2个类保存和检查，扩展了account类并实现了Account类。 例如：public class Saving 扩展 Account { ... }

我添加了其他类来完善 UML，例如银行和银行位置，但这并没有让面试官满意，他希望我将整个流程实现为 INTERFACES，我对此不太了解。我尝试提取相同的信息，但它并没有让面试官满意。

这里的人们可以分享的任何信息都将有助于我理解设计以及进一步如何进行面试。
我知道他们有很多设计模式，但是当他提到特定的接口时，我不知道如何处理。

Answer 1

在正常的银行业务流程中，您已经给出了很好的答案。然而，对于复杂的银行业务需求，他们将需要更多的模块化设计，而这正是界面大放异彩的地方。

在您的基本设计中，您会说：

• 所有账户均可入金
• 所有账户都可以提现
• 所有账户均可计算利息

说说你目前的设计，如果要求是：

1. 创建一个只能deposit 的account 类型。不能提现，只能关闭（如限时充值）
2. 创建只能withdraw 的account 类型。说你deposit开account有钱，那你只能withdraw，最后关了
3. 创建一个account 类型，它只能CalculateInterest，但不能deposit 或withdraw。
4. 等等

在您的设计中，您可以继承Account 基类，并为每个不支持的操作（存款等）抛出未实现的异常。但是，（请纠正我）这违反了 LSP 并有运行时异常的风险。

使用基于接口，你需要声明一些接口：

• IAccount（具有余额、用户 ID 等基本属性）
• IDepositable : IAccount
• IWithdrawable : IAccount
• IClosable : IAccount
• ICalculateInterestable : IAccount

那么对于需求，你可以声明一个类：

1. 实现 IDepositable、IClosable、ICalculateInterestable
2. 实现 IWithdrawable、IClosable、ICalculateInterestable
3. 实现 IClosable、ICalculateInterestable

这可能不是最简洁的设计，但应该可以满足大部分银行业务需求。