银行系统界面设计-访问

Question

我的背景:我是一名刚毕业的软件行业的毕业生。问:我最近接受了一家软件公司的采访，被要求为一个银行系统绘制UML图，该系统显示两个帐户，例如储蓄和支票，它们有不同的计算利息的方法。

我的解决方案是:我创建了一个Account类，一个抽象类。

像这样:公共抽象类帐户{.}这个类中定义了2种方法另一个方法CalculateInterest()是抽象方法。

两个类的保存和检查，它扩展了帐户类并实现了帐户类。例如:公共类储蓄扩展帐户{.}

我在UML的基础上添加了其他类，比如银行和银行位置，但这并没有让面试官满意，他希望我实现整个过程，因为接口，我对此并不十分了解。我试着提取同样的信息，但面试官并不满意。

这里的人可以分享的任何信息都将帮助我更好地理解设计，以及如何更好地对待面试。

我知道他们有很多设计模式，但当他提到具体的接口时，我不知道该如何处理。

Answer 1

在正常的银行流程中，你已经给出了一个很好的答案。然而，对于复杂的银行业务需求，它们将需要更多的模块化设计，而这正是接口的亮点所在。

在你的基础设计中，你说：

• 所有帐户都可以存款
• 所有帐户都可以取款。
• 全帐户可以CalculateInterest

以您当前的设计为例，如果需求是：

1. 若要创建只能使用account的deposit类型，请执行以下操作。它不能被撤回，只能关闭(例如基于时间的存款)。
2. 若要创建只能使用account的withdraw类型，请执行以下操作。如果你在打开deposit的时候有一些钱，那么你只能打开withdraw，最后关闭它。
3. 若要创建只能account (而不是deposit或withdraw )的类型，请执行以下操作。
4. 诸若此类

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

使用基于接口的方法，您需要声明一些接口：

• IAccount (它具有基本属性，如balance、user id等)
• IDepositable : IAccount
• IWithdrawable : IAccount
• IClosable : IAccount
• ICalculateInterestable : IAccount

然后，对于需求，可以声明一个类：

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

这可能不是最整洁的设计，但应该足以满足大多数银行业务的要求。