上午

圆老师 建哥带我们先回顾了昨天写的代码，做了一次code diff，找出了下列几个问题。

问题

1. 测试文件中在每一个测试案例中都初始化了类
2. 类中的方法行为不是该类所具有的
3. 代码没有格式化
4. 类名和方法名不适合
5. 每重构一次代码，需要运行一次测试
6. 有重复代码
7. 在一个方法中处理了两件事
8. 有不必要的临时变量

解决办法

1. 在测试文件中加一个setup方法
2. 移动方法到正确的类中
3. 检查代码空行／格式化
4. 类名是名词，方法名用动词
5. 重构一次运行测试
6. 消除重复
7. 分离职责
8. 去除不必要的临时变量

下午

part1

我们过了每个人前一天画的4个概念图，包括Map, Collection, Java面向对象, RESTful API. 话说概念图真的好难画！！！
每个人都找出了一些问题，每个人都有的问题有：

1. 表达不清晰
2. 概念不具体
3. 分类不正确

还好今天只要先完善两个概念图。写完这个就去改图。

part2

圆老师 建哥简单地给我们介绍了三层架构，这是经典的三层架构图：

首先，表现层向业务层发请求，业务层处理逻辑，从数据层拿到数据，然后业务层对数据进行处理，再返回给表现层。

规定：低层不能调用上层，同层可以互相调用，不够数据层和Controller除外。

三层架构的优点有

1. 开发人员可以只关注整个结构中的其中某一层；
2. 可以很容易的用新的实现来替换原有层次的实现；
3. 可以降低层与层之间的依赖；
4. 有利于标准化；
5. 利于各层逻辑的复用；
6. 结构更加的明确；
7. 在后期维护的时候，极大地降低了维护成本和维护时间。

有优点就有缺点，三层架构的缺点有

1. 降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2. 有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3. 增加了开发成本。

很多时候我们讲三层架构都会提到MVC框架，建哥也给我们介绍了MVC。

模型(Model)，用于存储程序中使用到的数据;
视图(View)，用不同的表现形式来呈现数据；
控制器(Controller)，更新模型。

MVC是表现层的设计模式，核心目的是解耦。
MVC与三层架构的对应关系是：

• V(View) 对应表现层
• C(Controller)对应表现层与业务逻辑层之间的Controller
• M(Model)对应表现层与Controller下面所有的东西，包括业务逻辑层和数据层

总结

以上就是圆老师 建哥给我们今天讲的东西，期待明天的RESTful和Spring。
话说RESTful还没讲23333