设计代码的经验总结

设计模式虽然好，但也并非任何场景都适合，我觉得在设计代码时只要时刻牢记高内聚、低耦合这两个原则，并在编码中实践，写出来的代码必定不会差。

衡量代码优异的标准：拓展性，复用性，维护性；23种设计模式；亦或者面向对象的封装、继承、多态在我看来无非是对高内聚低耦合原则的不同维度的阐述。

下面分别阐述个人的一些理解。

高内聚低耦合这两个原则都是围绕相互间的关联来定义的，内聚指的是将相互间关系密切的代码聚合到一个模块，怎么划分“关系密切”是重点，这就要强调“单一职责”了，用面向对象来解释就是定义一个类，类的属性和行为都是履行这个类的职责定义的，不属于这个类职责的属性和行为就不应该定义在这个类里，如此，类的职责就很明确了，而类里的属性和行为也都是密切相关的，也就符合所谓的高内聚。耦合从字面意思来看，耦可解释为藕断丝连，也就是关系杂乱，合可解释为串联合作，例如给耳机插入电脑合作我们就能通过耳机听音乐了，低耦合即是减少这些关系，用尽可能少的关系来完成联合工作，我觉得这个用迪米特法则来解释比较贴切，即对一个对象的了解越少越好，比如你去菜市场买猪肉，你只需要到猪肉贩那买猪肉即可，还用替猪肉贩操心你这猪肉没了帮他杀猪再进行买卖吗？将这个例子转化为程序例子即是：你得到一个猪肉贩对象，你先调用猪肉贩对象的查询猪肉量的接口，判断有没有足够你想买的猪肉量，如果没有，就调用猪肉贩对象杀头猪的接口，然后再调用买猪肉的接口，搞得人家猪肉贩跟个白痴似的。假设猪肉贩就是个白痴，没猪肉了你调用杀猪接口帮他杀猪，ok，猪肉贩以前都是在肉摊旁杀猪，所以你调用杀猪接口能帮他杀猪，但后来菜市场规定不能再菜市场内杀猪，那样太扰民了，猪肉贩找了个搭档，自己专门在肉摊上卖猪肉，搭档则负责在其他地方杀猪，要新的猪肉就扣个电话叫搭档把杀好的猪送过来，这样就相当于原本杀猪的接口没用了，如果猪肉贩还是你想象的那么白痴，那么新的接口变了的时候，你就要自己去追踪变化和修改变化，这样势必增加了编程的负担，这也是典型的一个耦合严重的例子，买个猪肉还用操那么多心。那怎么降低耦合呢？很简单，首先我们要明确职责，我只是个买主，我只想买猪肉，人家猪肉够不够卖用得着我操心吗？这个问题应该是猪肉贩的职责，杀猪也是人家猪肉贩的职责，我们只需要关心怎么买猪肉的这个接口即可。

如果想将这个接口进一步优化，我们也可以把猪肉贩这个对象设计成超级猪肉贩，即所有的猪肉贩都继承这个超级猪肉贩，这样的话我们的设计就不是和某一猪肉贩强行捆绑在一块了，比如这个猪肉贩猪肉卖完了，市场安排了另一个猪肉贩在这个摊位卖猪肉，你不会因为之前的猪肉贩不在了就买不了猪肉了，这也就是所谓的面向对象的依赖倒置原则，即应该依赖于接口，不依赖于具体的对象。

拓展性我的理解是对于一个模块，我可以很容易的拓展它的功能，不用担心添加新功能会给其他平级功能造成影响。我觉得编码想达到这种成效，结合设计模式的“开闭原则”即可达成，即对拓展开发，对修改关闭。

复用性是指对于一个模块或者一个方法，我不用关心它内部的结构和运作的细节，只需要了解参数的使用即可拿来协作，而关于它的具体定义的理解，有兴趣可以看看我之前写过的这篇《代码复用性的理解》。

维护性我的理解是围绕对代码的可读和易改两个方面的阐述，如果一份代码让人看起来就特别别扭费劲，那么光理解代码就得花不少时间，不好理解的代码改起来也势必要关心备至（也就是操不少心），当然好读懂的代码也有不容易改的，比如全局变量的滥用。