面向对象、设计原则、编程规范、重构技巧

读王争《设计模式之美》有感，进行一些理论知识总结

1. 编写高质量代码有哪些手段？
   
2. 代码的评价标准有哪些？
   可扩展性、可复用性、可读性、可维护性、灵活性、简洁性、可测试性…可维护性、可读性、可扩展性是提到最多的几个标准。
3. 面向对象思想
   面向对象四大特性：封装、继承、多态、抽象。之前对四大特性的理解比较浅，只知道其定义，但不知其意义，知其然不知其所以然。在《设计模式之美》专栏中，我逐渐对其意义有了理解。
   封装：封装是将一系列具有属性进行聚合，聚合成类/结构体。对这个类，为外部提供有限的必要的接口进行操作，同时用不同的权限控制语法进行权限范围限制。如Java中的public，protected，private等；go中的大小写等。封装能达到信息隐藏或者数据访问保护的目的，保证数据不被随意修改，提高代码可维护性。
   继承：一种is-a的关系，主要能提高代码的复用性。
   多态：子类可以替换父类，多个不同的子类继承自同一个父类，同时子类也重写父类方法，不同的类型特性；多态的前提是继承，接口类、duck-typing都是多态的一种编程机制。多态可提高代码的复用性和可扩展性。
   抽象：抽象就是讲如何隐藏方法的具体实现，让使用者只需要关心方法提供了哪些功能，不需要知道这些功能是如何实现的。抽象可以通过接口类或者抽象类来实现。抽象存在的意义，一方面是修改实现不需要改变定义；另一方面，它也是处理复杂系统的有效手段，能有效地过滤掉不必要关注的信息。
4. 基于接口而非实现编程
   基于接口而非实现编程，能够隐藏不稳定的实现细节，暴露稳定的接口。上游系统依赖稳定的接口，而不依赖不稳定的实现，当实现发生变化的时候，上游代码基本不需要变动，可以以此来降低耦合度，提高扩展性。越抽象、越顶层、越脱离具体某一实现的设计，越能提高代码的灵活性，越能应对未来的需求变化。好的代码设计，不仅能应对当下的需求，而且在将来需求发生变化的时候，仍然能够在不破坏原有代码设计的情况下灵活应对。
5. 设计原则
   1. 单一职责原则SRP
      单一职责原则原则描述的一个类只负责完成一个功能或者一个职责。避免设计大而全的类，将不相关的功能耦合到一起，提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，判断类是否职责单一的点：
      1. 类中的代码行数、函数或者属性过多；
      2. 类依赖的其他类过多或者依赖类的其他类过多；
      3. 私有方法过多；
      4. 比较难给类起一个合适的名字；
      5. 类中大量的方法都是集中操作类中的某几个属性。
   2. 开闭原则OCP
      对扩展开放，对修改关闭。 添加一个功能时，应该在已有基础的代码上，进行扩展，而不是修改已有代码。开闭原则可以理解为：以最小修改代码的代价完成新功能的开发，而不是完全杜绝修改。
   3. 里氏替换原则LSP
      子类对象能完全的替换父类对象出现的地方。并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数的原有“约定”。这里的“约定”包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。里氏替换原则和多态类似，但多态是一种代码实现思路，里氏替换原则是设计原则
6. 接口隔离原则
   客户端不应该强迫依赖它不需要的接口。讲的就是接口实现的功能要尽量单一。接口隔离原则侧重于接口的设计，单一职责原则面向的是类、模块等。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一
   
7. 依赖倒置原则DIP
   控制反转：在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。
   依赖注入：我们不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或“注入”）给类来使用。解耦的一种手段
   依赖反转原则：高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不需要依赖具体实现细节，具体实现细节依赖抽象。
   6. 迪米特法则
   迪米特法则的描述为：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。
8. KISS、YAGNI原则
   Keep It Sample and Stupid。尽量保持简单。KISS 原则是保持代码可读和可维护的重要手段。
   You Ain’t Gonna Need It。不要去设计当前用不到的功能；不要去编写当前用不到的代码。不要做过度设计
9. DRY原则
   Dont repeate youself。不要写重复的代码。实现逻辑重复，但代码功能语义不重复的代码，不违反DRY原则。实现逻辑不重复，但代码功能语义重复的代码违反DRY原则。。我们可以不写可复用的代码，但一定不能写重复的代码。