设计模式几点原则

《设计模式之禅》笔记：

这里说的抽象指的是：接口类和抽象类。

抽象是对实现的约束，对依赖者而言，也是一种契约，不仅仅约束自己，还同时约束自己与外部的关系，其目的是保证所有的细节不脱离契约的范畴，确保约束双方按照既定的契约共同发展，只要抽象的这根基线在，细节就脱离不了这个圈圈，始终让你的对象做到  言必行 ，行必果。 

1.  单一职责原则：  这个原则的要求是一个接口或类只有一个原因引起变化，也就是说，一个接口或类只有一个职责，她就只负责一件事情。这样的好处是，类的复杂性降低，好维护，同时变更的时候风险降低。

                             在我们平常的开发中，我们一般的写法就是，对相同的业务我们就会直接抽离成一个基础抽象类，而对应的一些功能需要提供的一些方法的话，我们就直接定义一个接口类。 我们不回细化到只有一个原因，我们更多的考虑的是，同一个业务或者是这个功能点需要几个方法，来作为一个整体来考虑对应的接口。 而对于普通类来说，一个类需要尽力的只负责一个功能点。 

2. 里氏替换原则： 所有父类能出现的地方子类都可以出现，并且替换为子类也不会产生任何错误或异常。

                          这个其实就是一个多态的体现。 在我们平常开发中，方法的参数注意设置为基础类或者是接口类，这样的话，在后面不同的子类调用方法的时候，高层这边的封装是不需要改动的。如果添加了一个新的子类也就直接传入就可以了，每一个子类对应的业务也不一样，但是，参数是父类，所以传入的时候，什么都不要改变。如果有一些子类需要有自己独立的一些业务需要的话，对于高层的封装来说，这样的子类的新的方法会抹杀，所以，可以直接扩充父类方法，然后，需要实现的就自己在重写父类方法。

3. 依赖倒置原则：  a.  模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系通过接口或者抽象类产生。

                                b.  接口或者抽象不依赖实现类。

                                c.   实现类依赖接口或者抽象类。－－－－－－－ 定义就是  面向接口编程

               通过抽象来产生依赖，这样更好的让模块和模块之间更加的独立，不会互相影响，实现模块之间的松耦合。

4. 接口隔离原则：  这个说的就是把接口细化，保证接口的纯洁性，让接口尽量的小，可以把一个接口分拆为多个接口这个意思。 但是我们现在在开发中，更多的接口对应的可能                                就是一个功能点或者业务，不会分的很细，但是我们需要注意的是尽量不要出现实现一个接口，会有多余的一些方法出来，又不要实现的代码出现。这样的情                                  况可以直接拆分多个接口来避免。

5. 迪米特法则：     通俗的来说，就是一个类应该对自己需要耦合或调用的类知道的最少，你（被耦合或调用的类）的内部时如何的复杂都和我没关系，那是你的事情，我就知道                                  你提供的这么多的public的方法，我就调用这么多，其他的我一概不关心。

                           一个类公开的public属性和方法越多，修改的时候涉及的面也就越大，变更引起的风险扩散也就越大，所以我们在写代码的时候，需要注意。同时对于提供给外部                           的方法中，不应该涉及业务，而就是怎么调用就可以了。

6. 开闭原则：       对象应该对扩展开发，对修改关闭。

                             接口或抽象类，一但定义下来，就不能轻易修改。

                             如果我们对其中的一个功能点需要加入新的业务需求的时候，我们作为一个维护人员，首先需要考虑的是，能不能直接重写子类方法，或者是重新扩展一个子类                              来实现，作为维护人员，更乐意做的事，直接看懂了基类，然后直接写一个子类或者重写基类方法，而不是看懂大量的原来的代码在来修改。所以我们需要在写                             代码的时候，需要注意后期的维护，我们提供的方法需要子类能有利于重写或者接口更好的进行继承。（方法尽量细化。）