SRP（单一职责原则）

何时应该分离职责

并不是所有职责都应该分离

• 如果随着需求的变化两个职责总是同时变化。比如Lajax请求，创建xhr和发送xhr。
• 另一方面无法确定以后会不会分离，现在耦合起来，之后再分离 优点：
• 降低单个类或者对象的复杂度
• 提高复用性
• 有利于单元测试

缺点：

• 增加编写复杂度

最少知识原则

书上说的在我的理解就是封装，其实在我看来封不封装也是需要分情况讨论的，终于理解了那句话，一切在不看应用情形下讨论某个事都是在扯淡。封装也是一种权衡。
我之前编写node的爬虫一直在想封装，最近，写闭包的时候发现，这完全有利于封装。

开放封闭原则

这个按照我的理解就是封装。提高复用性、可维护性。然后他提到一个我不知道的——利用对象多态性，来消除if-else我觉得这是个很好的方法，因为过多的if-else会影响维护。
不过也要注意，只是我在网上看到一个比较有意思的话

但是Java程序员，也包括我在内，很容易把这条路走得过于极端，比如遍地的Factory，比如漫山遍野的配置，比如永远也不会被复用的可复用代码，比如永远也不会被扩展的可扩展代码，还比如从前到后由内到外的分层，一层又一层。相对于这些方面无止境的追求，我们还是专注于要解决的问题，多写一些清晰可用的代码吧。

面向接口编程

我记得我看到的那本书——《javascript设计模式》，很大的篇幅再说怎么用原生的javascript实现接口模式，然后这本书说了一种相对好的方式，用Typescript来实现，他是javascript的超集，然后可以更原生的实现这些静态语言的优势。

总结

我也看了挺多的设计模式相关的书，刚开始看的时候，是觉得很高大上，然后就很迷惑，这东西有用吗？然后到我现在做的东西太小啦，以后做东西做大了就会利用这些设计模式。然后到现在的做好当下，既然现在遇到的工程量很少，复用性需求不大，那就专注在解决问题上，就像我上面写的，解决问题才是王道。