设计模式的设计原则

为什么需要设计模式？
我的理解设计模式就是一种针对某种问题的套路，是一套被反复使用，多数人所知晓的，经过分类编目的，代码设计经验的总结。

1.开闭原则

1.1 定义：

    一个软件实体应当对扩展开放，对修改关闭，即软件实体应尽量在不修改原有代码下进行扩展。
    软件实体：指一个软件模板，一个由多个类组成的局部结构或一个独立的类。

1.2 个人理解

    就是对于一个程序来说，举个例子

  if(type==1){
     //语句
  }eles if(type==2){
    //语句
  }else if(type==3){
  //语句
  }

对于这个代码来说，type的值就限制在[1，2，3]，如果我们后面还想要type==4，那我们就需要去在这段代码去更改，但这样就会违背开闭原则。这个原则是用来约束或者改进代码业务，对于一个很复杂的项目来说，如果添加一个功能，需要去找很多其他的源码去修改，不是很麻烦吗

1.3 一般解决

    对于解决这种问题，一般使用抽象类去拓展业务，让抽象类作为中转站去添加，这样就只需要添加而不需要修改

2. 里氏代换原则

2.1 定义

    所有引用基（父）类的地方必须能够透明的使用其子类。

2.2 个人理解

    前提：一个方法可以使用父类对象，结果：这个方法也可以使用其子类对象。反过来，则不行。

注意项：

• 子类的所有的方法都必须在父类去声明，或者子类全部实现父类中所声明的方法，而一般为了保证程序的可拓展性，一般由父类去定义（抽象类）
• 一般在使用这个原则时，尽量把父类设计为抽象类或者接口，让子类去实现或者继承父类，并去实现父类的方法，使用实例时就用子类，这样就很方便去添加子类和拓张功能。
• 在java语言中，在编译阶段，java程序会检查一个程序是否符合里氏代换原则，这是一个与实现无关地，纯粹就是语法上的检测，但是这种很有限就是了

2.3 例子

    就如同普通和vip都有发送邮箱这个功能，就将其提取处理，然后让子类拓展

3. 依赖倒转原则

3.1 定义

    抽象不应该依赖细节，细节应该依赖抽象，针对接口编程。

3.2 个人理解

    就是高层模块（业务逻辑）不应该依赖于底层模块（具体实现），而是通过抽象类或者接口依赖，而具体实现类依赖于抽象类。，就是在代码传递参数时或者关联关系中，尽量引用高层次的抽象类，然后把具体类可以写在配置中。

3.3 例子

    首先对于这样一个功能模块，我么如果去添加新的拓展就会很麻烦，如word

但是，如果我们把这么这些拓展功能抽象出来，然后在使用时，使用抽象类，在配置文件中配置相应的类就行了。

4. 接口隔离原则

4.1 定义

    使用多个专门的接口,而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口
    当一个接口过大时,我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需要知道与相关的方法

4.2 个人理解

    大概念:接口理解成一个类型提供的所有方法特征的集合→理解成角色→一个接口代表一个角色→隔离
    小概念：特定语言的接口,Isp思想就是将接口尽量独立出来,为用户提供尽量小的单一接口,而大接口中仅放不同小接口。

4.3 例子

    如同这个一般，各种功能都挤在一路去了，对于某些功能不需要的在里面

    就需要我们去根据功能去分开接口，这样就不会挤在一起了。

5. 合成复用原则

5.1 定义

    尽量使用对象组合，而不是继承来达到复用的目的。

5.2 个人理解

    尽量考虑组合而非继承,除非严格遵循里氏代换原则,但是继承则会暴露父类(基类)细节给子类导致封装性被破坏、同时继承而来的灵活度不够，是静态,不是动态。同时在发生变化时，组合对于其他类的影响较小。
方式：比较简单,从继承变成式关联,用依赖注入或者setter注入注入子类对象就行

5.3 例子

    对于这样一个例子，如果要拓展功能的话，添加一个新的数据库种类的话，那么，DAO类代码也会改变。它的方法继承于父类。

不过如果改为关联关系的话，DBUtil的功能就可以让子类通过依赖注入去扩展。

6. 迪米特法制

6.1 定义

    一个软件实体应当尽量少地于其他实体类发生相互作用。
    如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩
展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深
度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系

6.2 个人理解

对象的朋友定义：

• 当前对象本身(this)；
• 以参数形式传入到当前对象方法中的对象，
• 当前对象的成员对象；
• 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友，
• 当前对象所创建的对象。

    任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。在应用迪米
特法则时，一个对象只能与直接朋友发生交互，不要与“陌生人”发生直接交互，这样做可以降低系统
的耦合度，一个对象的改变不会给太多其他对象带来影响
    也就是尽量就是对象与对象之间的联系。

6.3 例子

    对于这样的一个ui组件联系的话，它们之间联系很复杂，改一个可能改全部

但我们用一个统一的联系类去管理的话，就减少了它们之间的相互影响。