熟练掌握Java设计模式设计原则

一，设计模式原则

1，单一职责原则

任何的一个类，让它简单一些，职责单一一些，或许是更好的选择。单一职责原则就是对于一个类而言，应该仅有一个可以改变它变化的原因。

这个可以联系到我自己当初使用SWT制作窗体程序的经历，我将窗体中的各个功能部分都放在该窗体的类下实现，然后通过创建该窗体类的对象来调用各个功能方法。这样子写就势必导致我对于每个功能的修改都需要在窗体类中去修改。就如《重构》中写的一个很重要的代码坏味道叫做Long Method。代码过长就极有可能是有坏味道了。Java是面向对象编程，可以认为面向对象设计其实就是希望做到代码的责任分解。所以应该将每个代码的功能逻辑设计单独封装一个类，然后通过在窗体类中通过对象的创建来调用。对于每个功能模块就只有它本身实现的逻辑作为其修改的原因。

举个例子，俄罗斯方块的实现，我们可以把它大范围上理解成页面的类与游戏逻辑的类。游戏需要满足各种环境下的运行，其实我们在不同的环境下游戏的逻辑是不会变的，所以我们只需要修改页面类即可。这就是一个单一职责原则的例子。

2，开放封闭原则

开放封闭原则指的是软件实体（类，模块，函数等）可以拓展，但是不可以修改。

举个《大话设计模式》里面的例子吧，中国的一国两制，不能因为香港，台湾来改变大陆的制度，但是又要追求回归圆满，所以就实行了一国两制的政策。其实可以理解成一国两制是在中国特色社会主义制度上的拓展。

开放封闭原则要代码设计上可以容易拓展，而不是因为一个需求当初的不确定发生了改变然后导致代码推到重来。所以在设计类的时候，就要做到这个类尽量的完美，在封闭的同时，通过继承extends对属性拓展来实现开放，满足面向对象的可维护，可拓展，可复用，灵活性好的特点。

3，依赖倒转原则

针对接口编程，不要针对实现编程。举个例子，电脑主机零件是易拔插，主板生产商只需要针对现在公布的CPU接口，显卡接口，固态接口。。。来生产主板就行了，不需要生产主板的厂商其它的所有零件都能生产，所以零件易拔插易更换。这里将零件想成接口，依赖倒转原则强调高层模块不应该依赖底层的模块，应该去依赖抽象<and接口>（零件坏了不用连带主板一起更换，零件之间的依赖性很低，所以编程中也要求类与类之间的依赖性不高）。

依赖倒转原则的第二点抽象不应该依赖细节，细节依赖抽象<and接口>。还是上面的例子，拿cpu来说，cpu处理速率不断的提高，版本也不断的提高，cpu中的细节处理改变，但是接口不变，所以细节依赖于抽象。做出来的cpu依然易拔插且通用。

里氏代换原则

一个软件的实体如果使用的是父类的话，那么一定也使用于其子类，而且它差别不出父类和子类的区别所在。也就是说在程序中把父类替换成子类，它程序没有发生任何变化。也正是因为如此，上面依赖倒转原则中的抽象，因为子类型的可替换性，所以使得父类的复用性变强，拓展性也变强。

4，迪米特法则

迪米特法则也称为最少知识原则。如果两个类或者多个类之间不必彼此直接通信，那么这两个类就不应当直接相互作用，如果其中一个需要调用某个类的一个方法的话，可以通过第三者来转发这样的调用。

这个法则，用一个自己的例子来说明吧。去公司上班，会有一个入司流程，然后对于你的流程具体分配到了人，在公司OA上可以查看，如果恰巧给你分配的人公出了，你去到他的这个部门找随便找个同事给你办事，他打开OA看到了你的分配人不是他，即使他没事，但是他还是拒绝了你。哈哈，是不是很像自己的“遭遇”。迪米特法则就是强调不是分配到人，而是分配到部门。可以理解成部门为第三方的转发者，让你去找该部门的部门经理，这样子他可以实时的根据情况来安排人给你办理。从某些方面来讲，也是降低了各自成员访问的权限，降低了类与类之间的耦合（联系程度）。