大话设计模式-----(四)迪米特法则、外观模式、建造者模式

迪米特法则

就是说如果两个类不必彼此直接通信。那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三方转发这个调用

强调了类之间的松耦合，类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对与欧关系的类造成波及。

外观模式

例子就是说买股票，如果我们自己投资的话，需要学习的知识很多，也很容易配。就是我们自己直接去创建实现子类。
但是我们可以利用买基金，就是说基金帮我们统一管理。我们只需将钱给基金就行了。然后创建基金的实例调用基金的方法即可。减轻客户端的压力。

各种股票

class SubSystemOne{
    public void MethodOne(){
        System.out.println("子系统方法1");
    }
}

class SubSystemTwo{
    public void MethodTwo(){
        System.out.println("子系统方法2");
    }
}
class SubSystemThree{
    public void MethodThree(){
        System.out.println("子系统方法3");
    }
}
class SubSystemFour{
    public void MethodFour(){
        System.out.println("子系统方法4");
    }
}

外观类

//外观类

class Facade{
    SubSystemOne one;
    SubSystemTwo two;
    SubSystemThree three;
    SubSystemFour four;
    //构造方法初始化
    public Facade(){
        one = new SubSystemOne();
        two = new SubSystemTwo();
        three = new SubSystemThree();
        four = new SubSystemFour();

    }
    public void MethodA(){
        System.out.println("\n方法组A----");
        one.MethodOne();
        two.MethodTwo();
    }
    public void MethodB(){
        System.out.println("\n方法组B----");
        three.MethodThree();
        four.MethodFour();
    }


}

客户端

    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.MethodA();
        facade.MethodB();

    }

比如MVC 层与层之间建立外观模式。在开发阶段子系统往往因为不断的重构演化而变的越来越复杂。这时增加一个外观类来管理这些类。就是提供了一个简单的管理接口。无论外面怎么变。里面怎么变，使用外观类管理接口就好了。实现了依赖倒转和迪米特法则~

很是常用。

建造者模式

例子

先创建一产品。这个产品额，是抽象的。有一些具体部件需要后面实例添加。有构造部件过程和显示过程

//具体产品类
class Product{
    List<String> partsList = new ArrayList<String>();
    public void Add(String part){
        partsList.add(part);

    }
    public void Show(){
        System.out.println("\n产品  创建----");
        for (String part :partsList){
            System.out.println(part);
        }
    }

}

所有产品都有固定的流程生产，不同的是流程的细节不同。那么把具体流程抽象出来

//定义个Builder类。

abstract class Builder{
    public abstract void BuildPartA();
    public abstract void BuildPartB();
    public abstract Product GetResult();

}

这个产品有两个种类。创建两个子类。继承Builder类。规范实现方法。

//具体建造类
class ConcreteBuilder1 extends Builder{
    Product product = new Product();
    @Override
    public void BuildPartA() {
    product.partsList.add("部件A");

    }

    @Override
    public void BuildPartB() {
        product.partsList.add("部件B");
    }

    @Override
    public Product GetResult() {
        return product;
    }


} 
//具体建造类2
class ConcreteBuilder2 extends Builder{
    Product product = new Product();
    @Override
    public void BuildPartA() {
    product.partsList.add("部件X");

    }

    @Override
    public void BuildPartB() {
        product.partsList.add("部件Y");
    }

    @Override
    public Product GetResult() {
        return product;
    }


} 

对于整个产品的构建方法的调用流程是固定的。如果给客户端的话容易出错。那么就创建个指挥者，指挥如何创建每个产品。针对的是产品父类抽象编程。只针对抽象父类的方法调用。不用关心具体的子类细节

//Director类  指挥者类

class Director{
    public void Construct(Builder builder){
        //指挥建造过程，所有的都是这样。针对他的父类抽象编程
        builder.BuildPartA();
        builder.BuildPartB();
    }


}

在客户端只需创建一个指挥者。传入抽象父类对象，利用多态创建子类。
指挥者指挥建造者实现创建出来的是产品定义个产品类接收建造者返回的产品。
然后就可以用返回的产品调用展示方法。

public static void main(String[] args) {
        Director director = new Director();
        Builder b1 = new ConcreteBuilder1();
        Builder b2 = new ConcreteBuilder2();
        director.Construct(b1);
        Product product1 = b1.GetResult();
        product1.Show();
        director.Construct(b2);
        Product product2 = b2.GetResult();
        product2.Show();
    }

建造者模式是在当前创建复杂对象的算法应该独立于该对象的组成部分以及他们的装配方法时适用的模式。

恩，莫名的喜欢这个建造者模式

自己的话说 就是 一个玩具的生成过程。
把一个玩具的所有基本的普遍的抽象出来定义一个类。所有子产品都要遵循这个标准。每个子产品的组装流程不能让员工自己去实现。都统一交给指挥者。指挥者的组成流程是针对抽象的那个玩具的。不在乎是什么玩具。
我想要个奥特曼。那么就创建个奥特曼的实例化。定义为玩具。
告诉指挥者。指挥者调用玩具的组装方法。完成奥特曼的组装。但是是建造者干的。指挥者只是负责固定组装流程调用。建造者返回你一个奥特曼。你打开包装。
啊，奥特曼。

理解的还不是很深入。希望以后写代码的时候用上。加深印象。