设计模式—六大原则之（道之禅）

1、模式介绍 

       模式是指从生产经验中和生活经验中经过抽象和升华提炼出来的核心知识体系，也可以看作是解决某一类问题的方法。把解决某类问题的方法总结归纳到理论高度，就是模式。模式是集体智慧的结晶，它概括了相关行业中经验丰富的从业者所应用的所有概念和方法。

       设计模式（Design Pattern）也是一种模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。其作用是可重用代码，让代码更容易被他人理解，保证代码的可靠性。（后续的序列文章就不介绍模式了）

2.1、设计模式的基本要素与分类

     2.1.1、基本要素：

     模式名称：助名词、用一两个词来描述模式的问题、解决方案和效果。

     问题：描述了应该在何时使用模式。

     解决方案：描述了设计的组成成分，它们之间的相互关系及其各自职责和协作方式。 

     效果：描述了模式应用的效果及使用模式应权衡的问题。

     2.1.2、模式分类

     创造型模式：主要描述何时创建对象。

     结构型模式：主要描述如何实现类和对象的组合。

     行为型模式：主要描述类或对象怎样交互及其怎样分配职责。

3、面向对象的设计六大原则

         理解面向对象的主要机制以及面向对象的设计模式，才能更好的领会设计模式的本质和并灵活使用。

4、六大原则之单例模式（因为单纯，所以快乐）

单一职责原则（SRP）：指的是一个类应该仅有一个引起它的变化的原因。         程序设计人员大都清楚应该写出高内聚、低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：职责扩散、就是某个职责被划分为颗粒度更细的多个职责了。就会造成高耦合、代码僵硬化。因此，应该把不同的职责分开到不同类中。

    

        例如：ATM系统的查找用户模块所示初始设计方案（图1）

        

        图1  初始设计方案结构图

       在图1中，AtmData类中的方法说明如下：getConnection()方法用于连接数据库，find()用于查询所有的用户信息，display()用于显示用户金额。

      对其进行重构：

      在图1中，ATMData类承担了太多的职责，既包含与数据库相关的方法，又包含与用户的查找和显示信息相关的方法。如果在其他类中也需要连接数据库或者使用find()方法查询用户信息，则难以实现代码的重用。无论是修改数据库连接方式还是修改图表显示方式都需要修改该类，它不止一个引起它变化的原因，违背了单一职责原则。因此需要对该类进行拆分，使其满足单一职责原则，类ATMData可拆分为如下三个类：

      (1) DbUtil：负责连接数据库，包含数据库连接方法getConnection()；

      (2) AtmDbDAO：负责操作数据库中的Customer表，包含对Customer表的改查等方法，如find()和display()。

    重构后的结构如图2所示：

图2

      单一原则的优点：

             1、降低类的复杂度，明确类的定义。

             2、提高可读性，降低了复杂性，提高了维护性。

             3、降低变更引起的风险，变更是不可减少，如果接口的单一原则做好，一个接口的修改只需修改对应的实现类，对其他接口无影响。这对系统的扩展性，维护性都有非常大的帮助。

      单一原则的缺点：

              1、增加类的编写麻烦。

5、六大原则之依赖倒置（约定之战）

依赖倒置含义（DIP）：是高层模块不应该低层模块，两者都应该依赖其抽象。抽象不应该依赖细节，细节不应该依赖抽象。其实更高的含义就是“面向接口编程—（面向对象设计OOD的精髓之一）”。         这些含义难于理解，解释一下：每个逻辑的实现都是原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子模块的再组装就是高层模块。在Java中，抽象就是指接口和抽象类，两者不能被实现化。细节就是实现类，实现类可以被实例化。

 

       例如：在一个车场（DriveWork）里有奔驰跑车（Benz），奔驰跑车的钥匙（driver()方法），小明想开奔驰跑车。反正老板不在车场，小明当然可以开奔驰了。

         在上图中，小明只能开奔驰，为啥呢？因为车场只有奔驰车。如果车场进一辆车（特斯拉）跑车，小明想开怎么办？开不了，因为车场没有这个车的钥匙。这就带来问题了。

      重构后的结构所示下图：

       重构后，车场有钥匙了，因为结构改变了。一旦有车进场就必须有钥匙随带，这减少了麻烦。而是小明也可以开特斯拉了。

      依赖倒置原则的优点：

              1、接口或抽象类对实现类进行约束，可以减少需求改变引起的麻烦。

             2、设计优良，结构清晰。