前言
前面的章节中，我们学习了一些常见的设计模式。可以说设计模式的出现，是为了帮助我们写出更好的代码。比如让代码更具扩展性、容易理解和维护。所以我们在码代码时候，也不用太在意使用什么模式，我们需要做的是，写出容易被理解和维护的代码。这个过程中，有些原则，还是要注意下的。
单一职责原则
单一职责原则中的职责是指“引起变化的原因”。如果一个方法承担过多的职责，那么在需求变迁的过程中，需要改写这个方法的可能性就越大。通常来说，修改代码是件危险的事，特别是当多个需求纠缠在一起时，改写时会有种牵一发动全身的感觉。
当然不是说我们所有的方法都要分离开，有的时候需要合到一起，有时候又需要分开来。像笔套和笔芯要合在一起，而笔和书分开来是合理的。熟练的运用单一职责原则，是需要一定的经验的。
- 优点：降低单个方法的复杂度，有利于代码的复用和维护。
- 缺点：增加代码的编写难度，当我们把职责分解成更小的粒度之后，实际上也增加了职责之间的相互联系。
最少知识原则
最少知识原则是指一个对象应该尽可能少的与其他对象之间发生关系。当一个对象必须引用另外一个对象时，我们可以让对象只暴露必要的接口，让对象之间的联系限制在最小的范围内。
- 优点：降低模块之间的耦合。
- 缺点：可能会创建了大量的第三者对象。
开放封闭原则
开放封闭原则的思想是当需求有改动时，可以使用增加代码的方式，但不允许改动程序的源代码。当然有时候让代码保持完全封闭是不可能的。但是我们可以做的是：
- 将程序的最容易发生变化的部分，抽象出来，然后封装这些变化，需要我们会“算”。
- 在不可避免发生修改时，尽量修改相对容易修改的地方。
