Home

Document of lab1

在本次的lab实现中，我们有以下的感想：

---

1、原来代码相关：

• 源代码中getDescription（）方法写在实体类里，因此需要使用大量的if/else语句进行判断之后再进行向下类型转换。我们将description放到父类之中，避免了每次进行的判断。

• 在设计模式上，我们使用了装饰者模式和工厂模式。

• 装饰者模式由源代码提供，实现了在不改变原类文件和使用继承的情况下，动态的扩展一个对象功能。
• 在工厂模式中，我们将整个项目抽象成client，waitress，cook。Main方法中，client将命令（字符串）传给waitress，后者经过分析，将request传给factory。在这里，我们借用了command pattern的思路，由于考虑到设计过度问题，仅将这一模式精简。我们使用 abstract factory来new客户所点的饮料，借此，客户不需要知道如何制作饮料。同时，我们提供了代码的未来扩展：如果coffee和tea可以选择加入的ingredient不同，abstract factory 可以很好地解决这一需求，而不伤害到源代码。并且，Main方法中if语句new一个饮料实例的部分也被封装到对应的工厂中。使用设计模式，我们将代码构建的更符合现实逻辑，同时增加了代码的 extensibility。

• 我们对代码进行了分包，使得源代码的组构更具有逻辑性。

2、进行团队分工时存在一定的问题。

• 此次有一位同学专门进行单元测试，但在实际操作中发现由于该同学对所要测试的代码的不熟悉，导致了效率的低下以及修改上的不方便。实际上在进行单元测试时，发生的错误有:（1）输入错误即会导致系统崩溃（2）if/else判断写错导致价格计算错误。都是容易发现更改的错误，因此由每人自己进行单元测试会是更好的选择。

3、代码重构的重要性。

• 在原有代码的基础上添加入新的功能可能会遭遇困难或者引入代码坏味道，通过代码重构，我们重新整理了类之间的关系，改善了代码的内部结构，使得维护与新功能的加入更加容易。

4、在需求问题的理解上没有早早地达成共识。

• 导致最后做出的产品与需求之间存在差异，所以以后做项目每个需求都要跟客户确认清楚，不能仅凭自己的理解想当然地去做。

5、另外我们考虑，将lab中的类之间的继承关系改为复合是否会是一种更优的设计。这样设计可以使得系统更具有弹性，易于之后的修改。