关于java:每天5分钟行为型模式二

迭代器模式

一听这名字就很相熟，对于 java 程序员来说，遍历汇合还是比拟常见的操作。不必关怀类型，就可能拜访数据，用的就是迭代器模式。

Aggregate(形象容器)： 应该由所有类实现的抽象类，并且科研由迭代器遍历。相似 Collection 接口

Iterator(形象迭代器)： 定义遍历容器对象的操作以及返回对象的操作

Concrete Aggregate(具体容器)

Concrete Iterator(具体迭代器)

迭代器 UML：

Aggregate：

public interface Aggregate {MyIterator createIterator();
}

Iterator：

public interface MyIterator {Object next();
    boolean hasNext();}

Concrete Aggregate:

其中这个具体的容器外部有个外部类ConCreateIterator

public class ConcreteAggregate implements Aggregate{private String[] values;

    public ConcreteAggregate(String[] values) {this.values = values;}

    @Override
    public MyIterator createIterator() {return new ConcreteIterator();
    }
    
    
    // 外部类，具体的迭代器类
    private class ConcreteIterator implements MyIterator {
        private int position;

        @Override
        public Object next() {if (this.hasNext()) {return values[position++];
            }
            return null;
        }

        @Override
        public boolean hasNext() {return position < values.length;}
    }
}

Client：

public class Client {public static void main(String[] args) {String[] arr = {"h", "e", "l", "l", "o"};
        ConcreteAggregate strarr = new ConcreteAggregate(arr);
        for (MyIterator it = strarr.createIterator(); it.hasNext();) {System.out.println(it.next());
        }
    }
}

观察者模式

观察者模式定义对象间的一种一对多依赖关系，使得每当一个对象状态产生扭转时，其相干依赖对象皆失去告诉并被自动更新。

Subject(主题)： 通常由类实现的可察看的接口。个别有增加、删除观察者，以及揭示观察者更新

Concrete Subject(具体主题)： 实现了主题接口，并且告诉观察者们更新

Observer(观察者)： 观察者的接口，个别都会有一个 update 办法

Concrete Observer

观察者 UML：

Observer：

public interface Observer {void update(String message);
}

Concrete Observer：

public class ConcreteObserver implements Observer {
    @Override
    public void update(String message) {System.out.println("订阅的公众号有新的音讯：" + message);
    }
}

Subject：

public interface Subject {List<Observer> subscribers = new ArrayList<>();
    void attach(Observer observer);
    void detach(Observer observer);

    void notifySubscribers(String message);
}

Concrete Subject：

public class ConcreteSubjectDesignPattern implements Subject {
    @Override
    public void attach(Observer observer) {subscribers.add(observer);
        System.out.println("新增一位用户关注");
    }

    @Override
    public void detach(Observer observer) {subscribers.add(observer);
        System.out.println("一位用户勾销关注");
    }

    @Override
    public void notifySubscribers(String message) {for (Observer subscriber : subscribers) {subscriber.update(message);
        }
    }
    
    // 这个办法不是通用的，每个具体的主题可能有不同的办法
    public void deliver(String message) {notifySubscribers(message);
    }
}

中介者模式

中介者模式又称调解模式，在咱们现实生活中也会又很多中介者的存在，房屋中介者，合同中介者，在 java 中的中介者模式又会是什么样子的呢。

当初有个这样的需要，moba 类竞技游戏一般来说有五个地位，打野，法术输入，物理输入，辅助，坦克。为了简便呢，就拿三个地位来看。

法师本人能够耗费，然而也会申请声援，打野呢，除了打野怪之外也要去 gank，辅助要给大家占视线，同时也要回城补状态。

中介者 UML

一般模式

Apc 类:

public class Apc {public void poke() {System.out.println("法师耗费");
    }
    
    // 申请声援，须要打野和辅助帮忙
    public void help() {Jungle jungle = new Jungle();
        Support support = new Support();
        System.out.println("法师申请声援");
        jungle.daye();
        support.vision();}
}

Jungle 类：

public class Jungle {public void daye() {System.out.println("打野打野");
    }
    
    // 打野要 gank 了，法师和辅助要跟着一起配合
    public void gank() {Apc apc = new Apc();
        Support support = new Support();
        System.out.println("打野开始抓人：");
        apc.poke();
        support.vision();}
}

Support 类：

public class Support {public void vision() {System.out.println("辅助占视线");
    }

    // 辅助先回城补状态了，你们先猥琐发育
    public void back() {Apc apc = new Apc();
        Jungle jungle = new Jungle();
        System.out.println("辅助临时回城了：");
        apc.poke();
        jungle.daye();}

}

Client 类：

之前用测试方法，感觉不是特地好，所以当前还是加个 client 类给各位小伙伴看。

public class Client {public static void main(String[] args) {Apc apc = new Apc();
        Jungle jungle = new Jungle();
        Support support = new Support();

        apc.help();
        
        
        jungle.gank();
        support.back();}
}

的确能够像咱们设想的一样，各职位相互合作，然而每次须要单干之前都须要 new 一下其它对象，这样其实是很不利于松耦合的，各个类之间都互相练习在一起， 牵一发而动全身。为了升高耦合度，中介者模式就呈现了。

中介者模式

当然需要还是下面的需要，只不过多了几个类，形象中介者，具体中介者，形象共事类，具体共事类

Mediator： 形象中定义了参与者的交互方式

Concrete Mediator

Colleague： 这是一个抽象类或接口用于定义须要调解的参与者如何进行交互

Concrete Colleague

AbstractMediator 类：

public abstract class AbstractMediator {public abstract void help();

    public abstract void gank();

    public abstract void back();}

Mediator 类：

public class Mediator extends AbstractMediator {
    // 具体中介者类要晓得本人给谁进行中介调解
    Apc apc;
    Jungle jungle;
    Support support;

    public Mediator() {this.apc = new Apc(this);
        this.jungle = new Jungle(this);
        this.support = new Support(this);
    }

    public void help() {System.out.println("法师申请声援");
        jungle.daye();
        support.vision();}

    public void gank() {System.out.println("打野开始抓人：");
        apc.poke();
        support.vision();}


    public void back() {System.out.println("辅助临时回城了：");
        apc.poke();
        jungle.daye();}
}

AbstractHero 类（形象共事类）：

public abstract class AbstractHero {
    // 和具体中介者产生一个分割关系
    Mediator mediator;

    public AbstractHero(Mediator mediator) {this.mediator = mediator;}
}

为了缩小篇幅呢，具体英雄类我就只拿 Jungle 类来讲，其它都是一样的

Jungle 类（具体共事类）：

public class Jungle extends AbstractHero {
    
    // 首先注入中介者
    public Jungle(Mediator mediator) {super(mediator);
    }

    // 属于本人干的事件的还是一样，也能够多几个办法
    public void daye() {System.out.println("打野打野");
    }
    
    // 设计到他人的事件，几个人一起单干的事件呢
    // 也不必本人分割别人，间接跟中介者说下，交给中介者来办
    public void gank() {this.mediator.gank();
    }

}

至于其它的共事类都是一样的，注入一个中介者，把耦合度高的事件交给中介者

Client 类：

public class Client {public static void main(String[] args) {Mediator mediator = new Mediator();
        
        Apc apc = new Apc(mediator);
        Jungle jungle = new Jungle(mediator);
        Support support = new Support(mediator);

        apc.help();

        System.out.println("------------------------------");
        jungle.gank();

        System.out.println("------------------------------");
        support.back();}

}