从封装变化的角度看设计模式组件协作

什么是设计模式

​ 要理解设计模式，首先得分明什么是模式。什么是模式？模式即解决一类问题的方法论，简略得来说，就是将解决某类问题的办法演绎总结到实践高度，就造成了模式。

​ 设计模式就是将代码设计教训演绎总结到实践高度而造成的。其目标就在于：1）可重用代码，2）让代码更容易为别人了解，3）保障代码的可靠性。

​ 应用面向对象的语言很容易，然而做到面向对象却很难。更多人用的是面向对象的语言写出结构化的代码，想想本人编写的代码有多少是不必批改源码能够真正实现重用，或者能够实现拿来主义。这是一件很失常的事，我在学习过程当中，老师们总是在说 c 到 c ++ 的面向对象是一种微小的提高，面向对象也是极为难以了解的存在；而在开始的学习过程中，我发现 c ++ 和 c 如同差异也不大，不就是多了一个类和对象吗？但随着愈发深刻的学习使我发现，事实并不是那么简略，老师们举例时总是喜爱用到简略的对象群体，比方：人，再到男人、女人，再到领有具体家庭身份的父亲、母亲、孩子。用这些来阐明类、对象、继承 …… 仿佛都显得面向对象是一件轻而易举的事。

​ 但事实真是如此吗？封装、粒度、依赖关系、灵活性、性能、演变、复用等等，当这些在一个零碎当中交织相连，相互耦合，甚至有些货色还互相冲突时，你会发现自己可能连将零碎对象化都是那么的艰难。

​ 而在解决这些问题的过程当中，也就缓缓造成了一套被重复应用、为少数人通晓、再由人分类编目标代码设计经验总结——设计模式。

设计准则

​ 模式既然作为一套解决方案，天然不可能是没有法则而言的，而其所遵循的外在法则就是设计准则。在学习设计模式的过程当中，不能脱离准则去看设计模式，而是应该透过设计模式去了解设计准则，只有深深地把握了设计准则，能力写出真正的面向对象代码，甚至发明本人的模式。

1. 开闭准则（Open Close Principle）

   ​ 开闭准则的意思是：对扩大凋谢，对批改敞开。在程序须要进行拓展的时候，不要去批改原有的代码。这样是为了使程序的扩展性更好，更加易于保护和降级。而想要达到这样的成果，就须要应用接口和抽象类。

2. 里氏替换准则（Liskov Substitution Principle）

   ​ 里氏替换准则中说，任何基类能够呈现的中央，子类肯定能够呈现。也就是说只有当派生类能够替换掉基类，且软件单位的性能不受到影响时，基类能力真正被复用，而派生类也可能在基类的根底上减少新的行为。里氏代换准则是对开闭准则的补充。实现开闭准则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换准则是对实现抽象化的具体步骤的标准。

3. 依赖倒置准则（Dependence Inversion Principle）

   ​ 依赖倒置准则是开闭准则的根底，具体内容：形象不应该依赖具体，而是具体该当依赖形象；高层模块不应该依赖底层模块，而是高层和底层模块都要依赖形象。因为形象才是稳固的，这个准则想要阐明的就是针对接口编程。

4. 接口拆散准则（Interface Segregation Principle）

   ​ 这个准则的意思是：应用多个隔离的接口，比应用单个接口要好。它还有另外一个意思是：升高类之间的耦合度。这个准则所要求的就是尽量将接口最小化，防止一个接口当中领有太多不相干的性能。

5. 迪米特法令，又称起码晓得准则（Demeter Principle）

   ​ 起码晓得准则是指：如果两个软件实体毋庸间接通信，那么就不该当产生间接的互相调用，能够通过第三方转发该调用。其目标是升高类之间的耦合度，进步模块的绝对独立性。迪米特法令在解决拜访耦合方面有着很大的作用，然而其自身的利用也有着一个很大的毛病，就是对象之间的通信造成性能的损失，这是在应用过程中，须要去折衷思考的。

6. 组合复用准则（Composite Reuse Principle）

   ​ 组合复用准则或者说组合优先准则，也就是在进行性能复用的过程当中，组合往往是比继承更好的抉择。这是因为继承的模式会使得父类的实现细节对子类可见，从而违反了封装的目标。

7. 繁多职责准则（Single Responsibility Principle）

   ​ 一个类只容许有一个职责，即只有一个导致该类变更的起因。类职责的变动往往就是导致类变动的起因：也就是说如果一个类具备多种职责，就会有多种导致这个类变动的起因，从而导致这个类的保护变得艰难。

​ 设计模式是设计准则在利用体现，设计准则是解决面向对象问题解决办法。在面对拜访耦合的状况下，有针对接口编程、接口拆散、迪米特法令；解决继承耦合问题，有里氏替换准则、优先组合准则；在保障类的内聚时，能够采纳繁多职责准则、集中类的信息与行为。这一系列的准则都是为了一个目标——尽可能的实现开闭。设计模式不是万能的，它是设计准则相互取舍的成绩，而学习设计模式是如何抓住变动和稳固的界限才是设计模式的真谛。

GOF-23 模式分类

​ 从 目标 来看，即模式是用来实现什么工作的；能够划分为创立型、结构型和行为型。创立型模式与对象的创立无关，结构型模式解决类或对象的组合，行为型模式对类和对象怎么调配职责进行形容。

​ 从 范畴 来看，即模式是作用于类还是对象；能够划分为类模式和对象模式。类模式解决类和子类之间的关系，这些关系通过继承建设，是动态的，在编译时刻就确定下来了；对象模式解决对象间的关系，这些关系能够在运行时刻变动，更加具备动态性。

组合之下，就产生了以下六种模式类别：

1. 类创立型模式：将对象的创立工作提早到子类中。
2. 对象创立型模式：将对象的创立延工作早退另一个对象的中。
3. 类结构型模式：应用继承机制来组合类。
4. 对象创立型模式：形容对象的组装模式。
5. 类行为型模式：应用继承形容算法和控制流。
6. 对象行为型模式：形容了一组对象怎么合作实现单个对象所无奈实现的工作。

从封装变动的角度来看

​ GOF（“四人组”）对设计模式的分类更多的是从用处办法进行划分，而当初，咱们心愿从设计模式中变动和稳固构造分隔上来了解所有的设计模式，或者有着不同的播种。

​ 首先要明确的是，取得最大限度复用的关键在于对新需要和已有需要发生变化的预见性，这也就要求零碎设计可能相应地改良。而设计模式能够确保零碎以特定的形式变动，从而防止零碎的从新设计，并且设计模式同样容许系统结构的某个方面的变动独立于其余方面，这样就在肯定水平上增强了零碎的健壮性。

​ 依据封装变动，能够将设计模式划分为：组件合作、繁多职责、对象创立、对象性能、接口隔离、状态变动、数据结构、行为变动以及畛域问题等等。

设计模式之组件合作

​ 古代软件专业分工之后的第一个后果就是“框架与应用程序的划分”，“组件合作”就是通过早期绑定，来实现框架与应用程序之间的松耦合，是二者之间合作时罕用的模式。其典型模式就是模板办法、策略模式和观察者。

模板办法——类行为型模式

1. 用意

​ 定义一个操作中的算法的骨架，并将其中一些步骤的实现提早到子类中。模板办法使得子类能够重定义一个算法的步骤而不会扭转算法的构造。

1. 实例

​ 程序开发库和应用程序之间的调用。假如当初存在一个开发库，其内容是实现对一个文件或信息的操作，操作蕴含：open、read、operation、commit、close。然而呢！只有 open、commit、close 是确定的，其中 read 须要依据具体的 operation 来确定读取形式，所以这两个办法是须要开发人员本人去实现的。

​ 那咱们第一次的实现可能就是这种形式：

// 规范库实现
public class StdLibrary {public void open(String s){System.out.println("open:"+s);
    }
    public void commit(){System.out.println("commit operation!");
    }
    public void close(String s){System.out.println("close:"+s);
    }
}

// 应用程序的实现
public class MyApplication {public void read(String s,String type){System.out.println("应用"+type+"形式 read:"+s);
    }
    public void operation(){System.out.println("operation");
    }
}
// 或者这样实现
public class MyApplication extends StdLibrary{public void read(String s,String type){System.out.println("应用"+type+"形式 read:"+s);
    }
    public void operation(){System.out.println("operation");
    }
}

// 这里两种实现形式的代码调用写在一起，就不离开了。public class MyClient {public static void main(String[] args){
        // 形式 1
        String file = "ss.txt";
        StdLibrary lib = new StdLibrary();
        MyApplication app = new MyApplication();
        lib.open(file);
        app.read(file,"STD");
        app.operation();
        lib.commit();
        lib.close(file);

        // 形式 2 
        MyApplication app = new MyApplication();
        app.open(file);
        app.read(file,"STD");
        app.operation();
        app.commit();
        app.close(file);
    }
}

​ 这种实现，无论是形式 1 还是形式 2，对于仅仅是作为利用来说，当然是能够的。其问题次要在什么中央呢？就形式 1 而言，他是必须要使用者理解开发库和应用程序两个类，才可能正确的去利用。

​ 形式 2 相较于形式 1，应用更加的简略些，然而依然有不欠缺的中央，就是调用者，须要晓得各个办法的执行程序，这也是 1 和 2 独特存在的问题。而这刚好就是 Template Method 施展的时候了，一系列操作有着明确的程序，并且有着局部的操作不变，剩下的操作待定。

// 依照 Template Method 构造能够将规范库作出如下批改
public abstract class StdLibrary {public void open(String s){System.out.println("open:"+s);
    }
    public abstract void read(String s, String type);
    public abstract void operation();
    public void commit(){System.out.println("commit operation!");
    }
    public void close(String s){System.out.println("close:"+s);
    }
    public void doOperation(String s,String type){open(s);
        read(s,"STD");
        operation();
        commit();
        close(s);
    }
}

​ 在批改过程中，将原来的类批改成了抽象类，并且新增了两个形象办法和一个 doOperation()。通过应用形象操作定义一个算法中的一些步骤，模板办法确定了它们的先后顺序，但它容许 Library 和 Application 子类扭转这些具体的步骤以满足它们各自的需要，并且还对外暗藏了算法的实现。当然， 如果规范库中的不变办法不能被重定义，那么就应该将其设置为 private 或者 final。

// 批改过后的 Appliaction 和 Client
public class MyApplication extends StdLibrary {
    @Override
    public void read(String s, String type){System.out.println("应用"+type+"形式 read:"+s);
    }
    @Override
    public void operation(){System.out.println("operation");
    }
}
public class MyClient {public static void main(String[] args){
        String file = "ss.txt";
        MyApplication app = new MyApplication();
        app.doOperation(file,"STD");
    }
}

​ 模板办法的应用在类库当中极为常见，尤其是在 c ++ 的类库当中，它是一种根本的代码复用技术。这种实现形式，产生了一种反向的控制结构，或者咱们称之为“好莱坞法令”，即“别找咱们，咱们找你”；换名话说，这种 反向控制结构 就是 父类调用了子类的操作（父类中的 doOperation() 调用了子类实现的 read() 和operation()），因为在平时，咱们的继承代码复用更多的是调用子类调用父类的操作。

1. 构造

2. 参与者

   • AbstractClass（StdLibrary）

     定义形象的原语操作（可变局部）。

     实现一个模板办法（templateMethod()），定义算法的骨架。

   • ConcreteClass（具体的实现类，如 MyApplication）

     实现原语操作以实现算法中与特定子类相干的步骤。

除了以上参与者之外，还能够有 OperatedObject 这样一个参与者即被操作对象。比方对文档的操作，文档又有不同的类型，如 pdf、word、txt 等等；这种状况下，就须要依据不同的文档类型，定制不同的操作，即一个 ConcreteClass 对应一个 OperatedObject，相当于对构造当中由一个特定操作对象，扩大到多个操作对象，并且每个操作对象对应一个模板办法子类。

1. 适用性

   对于模板办法的个性，其能够利用于下列状况：

   • 一次性实现一个算法的不变局部，并将可变的行为留给子类来实现。
   • 各子类中公共的行为应被提取进去并集中到一个公共父类中，以防止代码反复。重构形式即为首先辨认现有代码中的不同之处，并且将不同之处拆散为新的操作。最初用一个模板办法调用这些新的操作，来替换这些不同的代码。
   • 管制子类的扩大。模板办法只有特定点调用 ”hook” 操作，这样就只容许在这些扩大点进行相应的扩大。
2. 相干模式

   ​ Factory Method 常常被 Template Method 所调用。比方在参与者当中提到的，如果须要操作不同的文件对象，那么在操作的过程中就须要 read() 办法返回不同的文件对象，而这个 read() 办法不正是一个 Factory Method。

   ​ Strategy：Template Method 应用继承来扭转算法的 一部分 ，而 Strategy 应用委托来扭转 整个 算法。

3. 思考

   • 访问控制 在定义模板的时候，除了简略的定义原语操作和算法骨架之外，操作的控制权也是须要思考的。原语操作是能够被重定义的，所以不能设置为 final，还有原语操作是否为其余不相干的类所调用，如果不能则能够设置为 protected 或者 default。模板办法个别是不让子类重定义的，因而就须要设置为 final.
   • 原语操作数量 定义模板办法的一个重要目标就是尽量减少一个子类具体实现该算法时，必须重定义的那些原语操作的数目。因为，须要重定义的操作越多，应用程序就越简短。
   • 命名约定 对于须要重定义的操作能够加上一个特定的前缀以便开发人员辨认它们。
   • hook 操作 hook 操作就是指那些在模板办法中定义的能够重定义的操作，子类在必要的时候能够进行扩大。当然，如果能够应用父类的操作，不扩大也是能够的；因而，在 Template Method 中，应该去指明哪些操作是不能被重定义的、哪些是hook（能够被重定义）以及哪些是形象操作（必须被重定义）。

策略模式——对象行为型模式

1. 思考

   • Strategy 和 Context 之间的通信问题。在 Strategy 和 Contex 接口中，必须使得 ConcreteStrategy 可能无效的拜访它所须要的 Context 中的任何数据，反之亦然。这种实现个别有两种形式：

     ​ 1）让 Context 将数据放在参数中传递给 Strategy——也就是说，将数据间接发送给 Strategy。这能够使得 Strategy 和 Context 之间解耦（印记耦合是能够承受的），但有可能会有一些 Strategy 不须要的数据。

     ​ 2）将 Context 本身作为一个参数传递给 Strategy，该 Strategy 显示的向 Context 申请数据，或者阐明在 Strategy 中保留一个 Context 的援用，这样便不须要再传递其余的数据了。

   • 让 Strategy 成为可选的。换名话说，在有些实现过程中，客户能够在不指定具体策略的状况下应用 Context 实现本人的工作。这是因为，咱们能够为 Context 指定一个默认的 Strategy 的存在，如果有指定 Strategy 就应用客户指定的，如果没有，就应用默认的。

##### 观察者模式——对象行为型模式

1. 用意

   ​ 定义对象间的一种一对多的依赖关系，当一个对象的状态产生扭转时，所有依赖于它的对象都失去告诉并被自动更新。

2. 实例

   ​ 观察者模式很常见于图形用户界面当中，比方常见的 Listener。观察者模式能够使得利用数据的类和负责界面示意的类能够各自独立的复用。比方，当界面当中存在一个输出表单，在咱们对表单进行输出的时候，界面上又会显示这样一个数据的柱状图，以些来比照各项数据。其伪码能够形容成下列这种模式：Histogram作为柱状图类只须要负责接收数据并且显示进去，InputForm作为一个输出表单。在这个 过程中，只有 InputForm 中的数据发生变化，就相应的扭转Histogram 的显示。

   ​ 这种实现形式，显著在 InputForm 中产生了一种强耦合，如果浮现图形发生变化，当初不须要显示为一个柱状图而是一个饼状图, 势必又要去批改源码。

   public class Histogram {public void draw(int[]nums){for (int i:nums) {System.out.print(i+" ");
           }
       }
   }
   public class InputForm {private int[] data;
       Histogram histogram;
       public InputForm(Histogram histogram){
           this.histogram = histogram;
           show();}
       public void change(int... data){
           this.data = data;
           show();}
       public void show(){histogram.draw(data);
       }
   }
   public class Client {public static void main(String[] args) {InputForm inputForm = new InputForm(new Histogram());
           inputForm.change(3,4,5);
           inputForm.change(5,12,13);
       }
   }

   ​ 同时，InputForm 和显示图形之间的关系，刚好合乎观察者模式所说的一个对象的状态变动，引起其余对象的更新，同时兼顾思考开闭问题，能够将 Histogram 和PieChart公共个性提取进去，造成一个 Graph 接口。另外，有可能 InputFrom 不只须要显示一种图表，而是须要同时将柱状图和饼状图显示进去，因而在 InputFrom 中定义的是一个 List 的构造来寄存所有的相干显示图形。

   //Observer
   public interface Graph {public void update(Input input);
       public void draw();}
   public class Histogram implements Graph {
       private InputForm inputForm;
       public Histogram(InputForm inputForm){this.inputForm = inputForm;}
       @Override
       public void update(Input inputForm) {if(this.inputForm == inputForm){draw();
           }
       }
        @Override
       public void draw(){System.out.println("柱状图：");
           for (int i: inputForm.getData()) {System.out.println(i+" ");
           }
           System.out.println();}
   }
   public class PieChart implements Graph {
       private InputForm inputForm;
       public PieChart(InputForm inputForm){
           this.inputForm = inputForm;
           this.inputForm.addGraph(this);
           draw();}
       @Override
       public void update(Input inputForm) {if(this.inputForm == inputForm){draw();
           }
       }
       @Override
        @Override
       public void draw(){System.out.println("饼状图：");
           for (int i: inputForm.getData()) {System.out.println(i+" ");
           }
           System.out.println();}
   }
   

   ​ 在理论的利用过程中，既然有输出表单的模式，也有可能以其余的模式输出数据，为了当前的扩大，能够将输出模式形象进去，造成一个 Input 接口，以便后续的扩大。

   //Subject 指标对象
   public interface Input {public void addGraph(Graph graph);
       public void removeGraph(Graph graph);
       public void notifyGraphs();}
   public class InputForm implements Input {private int[] data;
       private List<Graph graphs = new List;
   
       public void change(int...data){
           this.data = data;
           notifyGraphs();}
       public int[] getData() {return data;}
       @Override
       public void addGraph(Graph graph){graphs.add(graph);
       }
       @Override
       public void removeGraph(Graph graph){graphs.remove(graph);
       }
       @Override
       public void notifyGraphs(){for (Graph g:graphs) {g.update(this);
           }
       }
   }

   public class Client {public static void main(String[] args) {InputForm inputForm = new InputForm();
           Histogram h = new Histogram(inputForm);
           PieChart p = new PieChart(inputForm);
           inputForm.change(1,5,6,9,8);
           inputForm.change(2,4,6,8);
       }
   }

3. 构造

4. 参与者

   • Subject（指标，如 Input）

     • 指标须要晓得本人所有的观察者对象。
     • 提供注册和删除观察者对象的接口
   • Observer（观察者，如 Graph）

     为那些在指标发生变化时须要获取告诉的对象定义一个更新接口。

   • ConcreteSubject（具体指标，如 InputForm）

     • 将无关状态（或数据）寄存到各 ConcerteObserver 对象中。
     • 当它的状态产生扭转时，向它的各个观察者发出通知。

   • ConcreteObserver（具体观察者，如 Histogram）

     • 保护一个指向 ConcerteSubject 的援用，或者是无关状态的援用。
     • 实现 Observer 的更新接口以使本身保留的指标状态与指标状态保持一致。

5. 适用性

   在以下任一状况下能够应用观察者模式：

   • 当一个形象模型有两个方面，其中一个方面依赖于另一个方面。将这二者封装在独立的对象中以使它们能够各自独立的扭转和复用。
   • 当对一个对象的扭转须要同时扭转其它对象，而不晓得具体有多少对象有待扭转。
   • 当一个对象必须告诉其它对象，而它又不能假设其它对象是谁。换言之，你不心愿这些对象上紧耦合的。
6. 相干模式

   ​ Mediator（中介者模式）：通过封装简单的更新语义，能够应用一个 ChangeManager 来充当指标和观察者之间的中介。在指标的状态变动过程中，有些状态变动可能只是两头长期变动，而还未到最终后果，但这可能引起观察者的更新，这种频繁的更新造成的就是通信代价和性能损失。因而，采纳一个 ChangeManager 能够更好去治理更新操作。

   ​ Singleton（单例模式）：ChangeManager 能够应用 Singleton 模式来保障它是惟一的并且是可全局拜访的。

7. 思考

   • 指标与观察者之间的映射。一个指标对象跟踪它应告诉的观察者的最简略办法是显式地在指标当中保留对它们的援用，但当指标过多而观察者少时，这样存储的构造可能代价过高。其一个解决办法就是用工夫换空间，用一个关联查找机制（例如一个 hash 表的模式）来保护指标到观察者的映射。这样没有观察者的指标天然不会产生存储上的开销，然而因为关联机制的存在，就相当于在拜访观察者的过程中多了一个步骤，就减少了拜访观察者的开销。
   • 一个指标能够有很多观察者，一个观察者也同样能够察看很多指标。这种状况下，就须要多观察者的 update 接口作出肯定的扭转，使得观察者可能晓得是那个指标对象发来告诉。
   • 谁来触发更新。一是在对指标状态值进行设定时，主动去调用告诉信息。这样客户就不须要去调用Notify()，毛病就在于多个间断的操作就会产生间断的更新，造成效率低下。二是客户本人抉择适合的状况上来调用Notify()，这种触发形式长处在于客户能够在操作实现指标对象之后，一次性更新，防止了两头无用的更新。毛病在于一旦客户可能没有调用告诉，就容易出错。
   • 如何保障发出通知前指标的状态本身是统一的。确保发出通知前指标状态统一这很重要，因为观察者在更新状态时，须要查问指标的以后状态。这就须要在代码序列中，保障告诉是在指标状态批改实现之后进行的，这时就能够采纳 Template Method 来固定操作的程序。

小结

​ 在这篇文章当中，没有依照 GOF 对设计模式的分类来对设计模式进行形容，而是在实例的根底上，使用重构的技巧：从动态到动静、从早绑定到晚绑定、从继承到组合、从编译时依赖到运行时依赖、从紧耦合到松耦合。通过这样一种形式来了解设计模式，寻找设计模式中的稳固与变动。

​ 在下面提到的三种模式中，它们对象间的绑定关系，都是动静的，能够变动的，通过这样的形式来实现合作对象之间的松耦合，这也是“组件合作”一个特点。

​ 还有就是对于耦合的了解，有的时候耦合是不可避免的，耦合的接受程度是相对而言的，这取决于咱们在实现过程当中对变动的封装和稳固的形象折衷，这也是咱们学习设计模式的目标，就是如何利用设计模式来实现这样一种取舍。

​ 对设计模式细节形容过程，体现的是我在学习设计模式过程中的一种思路。学习一个设计模式，首先要理解它是要干什么的。而后从一个例子登程，去了解它，思考它的一个实现过程。再而后，演绎它的构造，这个构造不仅仅是类图，还包含类图中的各个协作者是须要实现什么的性能、提供什么样的接口、要保留哪些数据以及各各协作者之间是如何合作的，或者说是依赖关系是怎么的。最初，再思考与其余模式的搭配，思考模式的实现细节。

这里呢，临时只写出了三种模式，后续的过程中，将会一一地介绍其余的模式。

最初，最近很多小伙伴找我要Linux 学习路线图，于是我依据本人的教训，利用业余时间熬夜肝了一个月，整顿了一份电子书。无论你是面试还是自我晋升，置信都会对你有帮忙！

收费送给大家，只求大家金指给我点个赞！

电子书 | Linux 开发学习路线图

也心愿有小伙伴能退出我，把这份电子书做得更完满！

有播种？心愿老铁们来个三连击，给更多的人看到这篇文章

举荐浏览：

• 干货 | 程序员进阶架构师必备资源免费送
• 神器 | 反对搜寻的资源网站