代码之道

这个名字有点大。其实就是自己的一些感悟。自己的感悟也可以称为自己的道。

道可道，非常道。所以就随便看看吧。

提到了“道”就要提到“术”。

道是什么呢，就是看代码“美不美”。为什么他美呢，我也说不出来。这个是我自己的“道”。既然道说不出来，那么我们就执行去具体有哪些“术”了，其实“术”并不是目的，只是一种手段而已。

自己的道说不出来，也许是因为自己能力有限，表达有问题，毕竟有那么多NB的人写了这么多东西，我们可以把“道”理解为设计模式的原则。

术呢，就是设计模式，编程规范，好的编程体验等等，其他规定了这些东西就是为了遵循“道”。但是前人制定的“术”可能有局限性。学的时候还是要思想一下他的目的，如果你又更好的方式，替换掉它是完全可以的。“尽信书不如无书。”

下面是设计模式几个原则。之前看过又说4个的，有6个的。反正领会精神就好。

       1.开放-封闭原则——“道”
　　2.单一职责原则——“术”
　　3.依赖倒转原则——“术”
　　4.迪米特法则（也称为最小知识原则）——“术”
　　5.接口隔离原则——“术”
　　6.合成/聚合复用原则——“术”

       7.里氏代换原则——“术”

个人感觉这几个原则里面最没有用的就是第一条了，但是他就是我们写好程序的目的。后面的原则以及其他的一些都是怎么去做到这点。开闭原则感觉也是最没用的，我也知道要写成对需求开放，对修改说不得代码，但是怎么写的。看看后面的原则，然后就是自己在写代码的过程中慢慢的悟吧。

后面就是单一职责原则。我觉得这个就是写代码最重要的原则。

下面说几个设计模式的例子，说明一下设计模式解决了哪些单一的问题。

工厂模式：根据不同的条件去生成不一样的对象。（这就是一件事情，如果没有工厂，那么可以在代码里面添加判断语句，那么它就不是只做一件事情了）

策略模式：把所有的动作通过接口来抽象成一件事情。测试模式也遵循了开闭原则，可以很好地去修改这个类的性质。（如果一个类只做了一件事情，我们可以很好地去替换掉它，从而完成修改。）

但是在开发的时候也需要一个平衡，要不就会出现类和方法的爆炸。允许在一些不会改变的地方出现不那么“单一”的类和方法。但是如果是可能出现修改的地方，一定要留出修改的方式、方法。没有唯一的标准答案。“美”就好了。

•     类的方法通过protected声明。
•     通过调用一个接口来完成一个类里面的方法。一个service方法，里面有一个方法，这个方法可能会存在修改。然后通过声明一个接口和返回值。跟这个service方法的签名一样。这样就可以通过配置来去修改这个类的方法了。（策略模式）
• 减少代码注释：为什么要减少注释呢，因为后来代码逻辑有可能改变，注释程序员有可能怕删掉，就留下来了，然后就造成一坨代码，然后加上毫不相关的注释。类、方法、变量尽量使用有意义的单词，如果你认为一个方法内部需要写注释了，那么你的方法应该就不是只做一件事情了。那么你需要的不是写注释，而是把那块逻辑抽出来，然后起一个有意义名字去作为这个方法的名字。名字不怕长，而怕不清楚。

还有面向对象编程也要说两句，为了更好地描述问题，更好地合作，我们经历了机器语言、汇编语言、高级语言、面向对象语言。面向对象语言有什么好处呢，是更好地让人们去理解问题。

所以我们在处理程序一些细节的时候，如果不知道这个变量、方法应该放在哪个类里面。那么站起来，溜达溜达，想象现实世界里面这个方法到底是谁负责的。

还有现在程序里面有时候会嵌套很多层（这已经不“美”了，我理解不了的都叫做不“美”）。下层的方法应不应该访问上层的对象，在考虑这个问题的时候也是一样的，站起来，溜达溜达，考虑一下现实世界吧。

写的比较乱，但是想表达一个想法，程序员写程序的时候，需要对自己有要求，要写出“美”的代码。“美”只要你认为美就可以了，但是如果能做到让别人也认为美就更好了。如果只是完成任务，那么跟“咸鱼”有什么区别呢。