第二周学习总结

第二周提出了几个重要的面向对象设计原则(SOLID)，我理解的主要是以下几点：

• 好的设计是使得系统易于扩展，更加强壮，可移植性高，更容易理解和维护，根据这几个原则引出了设计模式的概念。工作中经常会提到框架，但没有细想过框架和应用程序和架构的关系。我认为框架相当于构建应用的一个脚手架，它简化了开发的工作，同时也实现了多种设计模式。框架来调用应用程序代码，代码调用工具，架构师用框架保证自己架构能够落地，同时也用各种工具提高开发效率。

• 课堂上举了一个例子，这段代码就是设计的很糟糕(第一眼看上去就是很多的switch case，if else，按我的经验非常难扩展，很容易写坏)，如果说一个设计导致代码很僵硬脆弱，不可移植难理解，"一改就坏"，重复过多，etc，那么这个设计就是"has a bad smell"

• 第一个原则：ocp(open/closed principle)，对于扩展开放，对于更改关闭。我认为这个原则的意思就是设计程序的时候我们可以扩展它的行为但不需要去修改并且重新编译它的源代码。这个原则可以通过inheritance, composition或者诸如strategy design pattern来体现。

• 依赖反转原则：dependency inversion，很早前学习angular js框架的时候接触过这个概念，作业一里面的例子也可以改进一下，不注入concrete class，注入interface这样适用的范围就更广

• 里氏替换：讲这一节的时候我想起了第一节课老师提出的一个问题。这个原则意思就是子类必须能够在应用场景里面替换掉父类，那么第一节课提出的那个问题就很明显了，因为子类不会抛出一个父类不能处理的error type。java本身也有这样的错漏（stack is not a vector)。lsp要求子类的“契约”不可以比父类更加严格。解决它的方案可以是组合，提取共性到基类。(组合优先)

• 单一职责原则(srp)：一个service做一件事，在有新需求，有变化的时候就能看出哪些职责应该分离出来。这样程序会更健壮，可移植性更高。

• 接口分离(isp)：我认为和前一个原则比他们有共性的地方，就是希望应用能够更加高内聚(cohesive)，前者指出只有一个原因能让类变化，这个原则指出的是如何设计一个接口，认为用户不需要看到他们不用的方法。改进方法可以有适配器模式，多继承，etc。