1700479712
//使用Postfix发送邮件
1700479713
1700479714
MailServer mail=new Postfix（m）；
1700479715
1700479716
//发送邮件
1700479717
1700479718
mail.sendMail（）；
1700479719
1700479720
}
1700479721
1700479722
}
1700479723
1700479724
运行结果如下所示：
1700479725
1700479726
====正在发送的邮件信息====
1700479727
1700479728
发件人：a@a.com
1700479729
1700479730
收件人：b@b.com
1700479731
1700479732
邮件标题：外星人攻击地球了
1700479733
1700479734
邮件内容：
1700479735
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
[
上一页 ]
[ :1.700479712e+09 ]
[
下一页 ]