51工具盒子# （一）前言 {#一-前言}
最近发现一件事情，自己写的代码和公司里工作5到10年的前辈写的代码虽然功能一样，但是他们的代码更规范，更优雅。比如有时候我会给一个需求写一个方法，但是有些人就可以好几个需求通过同一个方法实现。因此有了今天这个疑问，怎样才能写出规范的好代码？
# （二）什么样的代码是好的代码 {#二-什么样的代码是好的代码}
我们在写程序的过程中，除了要实现功能之外，还需要考虑：
1.代码重用性（相同功能的代码，不用多次编写）
2.可读性（便于其他程序员阅读与理解）
3.可扩展性（需要新增功能时可以很方便的维护）
4.可靠性（新功能的加入不会对已有的功能造成影响）
5.高内聚 、低耦合
而为了实现上面这些目的，我们需要遵循一些原则，因此，设计模式出现了。
# （三）设计模式的原则 {#三-设计模式的原则}
设计模式的原则，就是指在编写程序时应该遵守的原则，设计模式的原则也是各种设计模式设计的依据。
设计模式常用的原则有以下七种：
1.单一职责原则
2.接口隔离原则
3.依赖倒转原则
4.里式替换原则
5.开闭原则
6.迪米特法则
7.合成复用原则
接下来我将对以上七种设计模式进行介绍。
# （四）单一职责原则 {#四-单一职责原则}
单一职责原则顾名思义就是每个类只负责一项原则，很好理解，如果一个类中负责了两个甚至更多的职责，当其中一个职责的需求发生变更而要改变时，可能造成其他职责的执行错误。
单一职责原则的注意事项和原则：
-
降低类的复杂度，一个类只负责一项职责
-
提高类的可读性，可维护性
-
降低变更引起的风险
-
通常情况下，我们都应该遵守单一职责原则，除非该类的逻辑足够简单，才可以在代码中违反单一职责原则。
# （五）接口隔离原则 {#五-接口隔离原则}
接口隔离原则的意思是表明客户端不应该被强迫实现一些他们不会使用的接口，应该把胖接口（指一个接口中有大量不会使用的方法的接口）中的方法分组，然后用多个接口替代它，每个接口服务于一个子模块。简单地说，就是使用多个专门的接口比使用单个接口要好很多。
# （六）依赖倒转原则 {#六-依赖倒转原则}
依赖倒转原则的含义有下面三点：
1、高层模块不应该依赖低层模块，两者都应该依赖其抽象
2、抽象不应该依赖细节
3、细节应该依赖抽象
光看三点含义会很难理解，但是从设计理念层面就会好理解很多，依赖倒转原则的设计理念是：以接口和抽象为基础的系统会比以细节为基础的系统稳定很多。因此我们设计一个系统时，应该先设计接口和抽象类 ，然后通过具体的实现类去实现细节功能。
因此依赖倒转原则的核心是面向接口编程。
# （七）里式替换原则 {#七-里式替换原则}
里式替换原则主要为了解决继承会导致的一些问题。
继承作为面向对象的三个基本特性之一，在给程序带来便利的同时也增加了一些潜在的风险。比如子类B和子类C同时继承父类A，如果父类A需要修改，必须要考虑所有的子类，否则就可能导致子类的方法出现故障。
里式替换原则的定义为：继承必须确保超类所拥有的性质在子类中仍然成立。
通俗来讲，就是子类可以扩展父类的功能，但不能改变父类原有的功能。
在实际编程中，我们遵循里式原则的方式就是子类尽量不要去重写父类的方法，通过依赖、聚合、组合等关系代替。
# （八）开闭原则 {#八-开闭原则}
开闭原则的核心是一个应用，应该对扩展开放，对修改关闭。
简单来讲，如果一个需求变更了，尽量通过扩展的方式去实现，而不是去修改原来的代码。而在代码中具体实现的话就是合理利用接口和抽象类，扩展时只需要继承抽象类或实现接口而不用去修改原来的代码。
开闭原则是编程中最基础和重要的原则。
# （九）迪米特法则 {#九-迪米特法则}
迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。
通过迪米特法则，可以实现代码之间的低耦合。我们在写代码时，尽量减少每个类不必要的依赖，陌生的类不要作为成员变量出现在类里（这里陌生的类是值没有在方法参数或者请求参数中出现的类）。
但是迪米特法则并非要求类之间完全没有依赖！
# （十）合成复用原则 {#十-合成复用原则}
合成复用原则的核心是尽量使用合成（聚合）的方法，而不是使用继承。
举个例子：如果A类想要用B类的某个方法，通过继承是肯定可以实现的。但是继承的话就会导致A和B的耦合性增强，这个时候就可以通过合成的方式，在A类中引用B类，来降低耦合性。
# （十一）总结 {#十一-总结}
即使将上面的七种原则全部理解清楚，想要真的在编码时完全按照原则来还是很难，这是一个长期的过程，而我们能做的是尽量在赶工的同时留意代码质量，逐步将设计模式等准则应用在代码中。
我是鱼仔，我们下期再见！
