中介者模式是一种行为型模式，是为了解决对象之间错综复杂的调用关系的一种设计模式，这种错综复杂的调用关系采用一个中介类来进行帮忙调用，所有的调用者只是需要关心中介者，而不需要进行互相依赖。
例如张三是一个单身男人，到了谈婚论嫁的年龄，家里人都非常着急。这一天张三打开了微信附近人，准备下网捞鱼，于是他联系了小红，约好了周五见面，而由于张三怕小红放鸽子，所以也约了小黄。可是小红和小黄可是认识的闺蜜所以小红和小黄是认识的。这下周五一见面张三的渣男人设不是暴露无疑。
如此一来他们三个的关系变得错综复杂，张三可以约小红，同样小洪也能约小黄，小红由于和小黄认识所以小红也能和小黄进行互相约。而张三由于广撒网，所以也可以约小黄，同样小黄也能约张三。
如果体现在代码中就是张三和小红两个对象存在可以互相依赖，小红和小黄存在互相调用依赖，而张三和小黄也存在互相调用依赖。
为了解决这个问题，我们可以衍生出一个协调者，也就是中介者而张三谈恋爱约会的事情就交给他去处理，他来负责协调。
Person是对人员信息的抽象，所以PersonZhangSan、PersonXiaoHong以及PersonXiaoHuang都继承于Person。而Mediator是中介者的抽象，ConcreteMeiator是对中介者的具体实现，所以继承于Mediator。
Person是对人员信息的抽象，所有人员都应该具备名字、空闲时间、是否已安排约会，所以单独进行抽象，让所有的人员具有一致性。
PersonZhangSan是对人员信息的具体实现，其中包含了基础的信息获取，实际上代码只是方便举例，才单独搞了一个人小红、小黄、张三的单独名字类。实际上都应该属于Person只是name不一样而已。
同样PersonXiaoHong也是对人员信息的具体实现，其中包含了基础的信息获取。
同样PersonXiaoHuang也是对人员信息的具体实现，其中也包含了基础的信息获取。
Mediator是对中介者的抽象，其中有两个方法，分别是registry用于保存需要协调者的实例对象，而appointment则是进行协调约会时间。
ConcreteMediator是中介者的具体实现，可以看到实现于Mediator而具体怎么收集用户信息以及怎么协调的都是在具体的中介者中进行实现的。
如果要申请约会的人的时间和收集到的用户信息中存在一致的空闲时间，那么可以约会，当然你不能自己给自己约会吧，所以要排除自己，同时如果一旦约会了就不能被别人再次邀约，所以还要判断是否为已安排约会。同时一旦匹配成功两个人都需要设置自己为已经安排约会。
现在张三可以通过中介者来协调进行约会，实际约会情况如下，可以看到由于张三和小黄是同一天有休息时间，所以他俩匹配成功进行约会。
中介者模式很像一个协调者，他的作用就是帮助协调，不再是自己去找别人，如果自己去做那么对象之间的关系就会变得十分复杂。你可以想象一下飞机的降落，飞机降落并不是飞机与飞机之间进行交互，谁可以下降到那个跑道，都是通过一个电台，他作为一个中介者进行协调。
Mediator(仲裁者、中介者)角色，用于对对象之间进行协调者，文中由Mediator扮演此角色。
ConcreteMediator(具体的仲裁者、中介者)角色，是对Mediator的具体实现，文中由ConcreteMediartor扮演此角色。
Colleague(同事)，用于被中介者或仲裁者进行协调的对象，文中由Person类扮演此角色。
ConcreteColleague(具体的同事)，是对Colleague的具体实现，文中由PersonZhangSan、PersonXiaoHong、PersonXiaoHuang扮演此角色。
参考文献《图解设计模式》、《设计模式之禅》
代码获取地址:https://gitee.com/bughong/design-pattern
