设计模式-原理Or六大原则

设计模式、六大原则、单例模式

开篇前言：
设计模式中体现着开发者的开发思路，理论是一个东西实际开发的过程中又是另外的一个东西。使用设计模式的原因是为了让我们项目中的一些需求更加容易的去进行实现。理论是不变的，人是活的。话说回来，程序还是一个综合性比较强的东西，

思想、模式、套路，一种解决问题的高效策略。
六大原则均遵守（软件编程总原则：高内聚、低耦合）：
（1）单一职责原则：
在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。一个人只做一件事情；
（2）里氏替换原则：
类B继承类A时，除添加新的方法完成新增功外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。（相对于抽象方法而言）继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。尽量少使用virtual、override 关键字
（3）依赖倒置原则：
以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。原本A类与B类直接耦合时，A类必须等B类编码完成后才可以进行编码，因为Mother类依赖于Book类。修改后的程序则可以同时开工，互不影响，因为A与B类一点关系也没有。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。
1.低层模块尽量都要有抽象类或接口，或者两者都有。
2.变量的声明类型尽量是抽象类或接口。使用继承时遵循里氏替换原则。
3.依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
（4）接口隔离原则：
将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
客户端不应该依赖它不需要的接口或者说是一个类对另一个类的依赖应该建立在最小的接口上。
（5）迪米特法则
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
因此，尽量降低类与类之间的耦合。一个对象应该对其他对象保持最少的了解。一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。最少知道原则
（6）开闭原则
一开始这里博主也不是很懂，就像是听了一段废话一样。只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。
而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。
当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。
用抽象构建框架，用实现扩展细节。

总结：要设计模式方便我们的开发，不要让我们方便了设计模式，也就是说在开发的过程中不一定是要用到所有的设计模式、