1700479736
Content-Type：multipart/mixed；charset=GB2312
1700479737
1700479738
Received：from XXXX（unknown[xxx.xxx.xxx.xxx]）by aaa.aaa.com（Postfix）with
1700479739
1700479740
ESMTP id 8DBCD172B8
1700479741
1700479742
结局是外星人被地球人打败了！
1700479743
1700479744
邮件格式为：超文本格式
1700479745
1700479746
当然了，还有其他三种发送邮件的方式：Postfix发送文本邮件以及SendMail发送文本邮件和超文本邮件。修改量很小，读者可以自行修改实现，体会一下桥梁模式的特点。
1700479747
1700479748
1700479749
1700479750
1700479751
设计模式之禅 33.1.3 最佳实践
1700479752
1700479753
策略模式和桥梁模式是如此相似，我们只能从它们的意图上来分析。策略模式是一个行为模式，旨在封装一系列的行为，在例子中我们认为把邮件的必要信息（发件人、收件人、标题、内容）封装成一个对象就是一个行为，封装的格式（算法）不同，行为也就不同。而桥梁模式则是解决在不破坏封装的情况下如何抽取出它的抽象部分和实现部分，它的前提是不破坏封装，让抽象部分和实现部分都可以独立地变化，在例子中，我们的邮件服务器和邮件模板是不是都可以独立地变化？不管是邮件服务器还是邮件模板，只要继承了抽象类就可以继续扩展，它的主旨是建立一个不破坏封装性的可扩展架构。
1700479754
1700479755
简单来说，策略模式是使用继承和多态建立一套可以自由切换算法的模式，桥梁模式是在不破坏封装的前提下解决抽象和实现都可以独立扩展的模式。桥梁模式必然有两个“桥墩”——抽象化角色和实现化角色，只要桥墩搭建好，桥就有了，而策略模式只有一个抽象角色，可以没有实现，也可以有很多实现。
1700479756
1700479757
还是很难区分，是吧？多想想两者的意图，就可以理解为什么要建立两个相似的模式了。我们在做系统设计时，可以不考虑到底使用的是策略模式还是桥梁模式，只要好用，能够解决问题就成，“不管黑猫白猫，抓住老鼠的就是好猫”。
1700479758
1700479759
1700479760
1700479761
1700479762
设计模式之禅 [:1700454076]
1700479763
设计模式之禅 33.2 门面模式VS中介者模式
1700479764
1700479765
门面模式为复杂的子系统提供一个统一的访问界面，它定义的是一个高层接口，该接口使得子系统更加容易使用，避免外部模块深入到子系统内部而产生与子系统内部细节耦合的问题。中介者模式使用一个中介对象来封装一系列同事对象的交互行为，它使各对象之间不再显式地引用，从而使其耦合松散，建立一个可扩展的应用架构。
1700479766
1700479767
33.2.1 中介者模式实现工资计算
1700479768
1700479769
大家工作会得到工资，那么工资与哪些因素有关呢？这里假设工资与职位、税收有关，职位提升工资就会增加，同时税收也增加，职位下降了工资也同步降低，当然税收也降低。而如果税收比率增加了呢？工资自然就减少了！这三者之间两两都有关系，很适合中介者模式的场景，类图如图33-4所示。
1700479770
1700479771
1700479772
1700479773
1700479774
图33-4 工资、职位、税收的示意类图
1700479775
1700479776
类图中的方法比较简单，我们主要分析的是三者之间的关系，通过类图可以发现三者之间已经没有耦合，原本在需求分析时我们发现三者有直接的交互，采用中介者模式后，三个对象之间已经相互独立了，全部委托中介者完成。我们在类图中还定义了一个抽象同事类，它是一个标志性接口，其子类都是同事类，都可以被中介者接收，如代码清单33-11所示。
1700479777
1700479778
代码清单33-11 抽象同事类
1700479779
1700479780
public abstract class AbsColleague{
1700479781
1700479782
//每个同事类都对中介者非常了解
1700479783
1700479784
protected AbsMediator mediator；
1700479785