银行系统界面设计 - 面试

Question

我的背景：我是一位刚刚在软件行业找到工作的毕业生。 问题：我最近在接受一家软件公司的采访，并被要求为显示2个账户的银行系统绘制UML图。保存和检查，他们有不同的计算方式。

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

2类保存和检查哪些扩展账户类和实现账户类。 例如：公共类储蓄账户扩展{...}

我添加其他类顶过UML像银行和银行的位置，但这次没面试官感到满意，他希望我能实现整个过程INTERFACES我相当不理解。我尝试提取相同的信息，但它并不高兴采访者。

任何人在这里可以分享的任何信息都会帮助我理解设计和进一步如何接近采访。
我知道他们有很多设计模式，但当他提到特定的接口时，我不确定如何处理这些问题。

Answer 1

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

在您的底座设计，你是sayint说：

• 所有账户可以做存款
• 所有账户可以做撤柜
• 所有账户可以CalculateInterest

说与当前的设计，如果要求如何：

1. 要创建一个类型account即只能deposit。它不能被撤销，只能关闭（如基于时间的存款）
2. 要创建一个account类型的只能withdraw。说你deposit一些钱开account的时候，那么你只能withdraw，并在年底，关闭
3. 要创建一个类型的account只有CalculateInterest，但不deposit或withdraw可以。
4. 等等

在你的设计，你可以继承基Account类，并抛出unimplement例外各不支持的动作（存款等）。但是，（请纠正我）违反LSP和冒着运行时异常的风险。

使用接口为主，需要声明一些接口：

• IAccount（这有基本的财产，如平衡，用户ID等）
• IDepositable：IAccount
• IWithdrawable：IAccount
• 无法关闭：帐号
• ICalculateInterestable：帐号

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

1. 实施IDepositable，IClosable，ICalculateInterestable
2. 实施IWithdrawable，IClosable，ICalculateInterestable
3. 实施IClosable，ICalculateInterestable

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