1700466449
1700466450
target2.request（）；
1700466451
1700466452
}
1700466453
1700466454
}
1700466455
1700466456
适配器模式的原理就讲这么多吧，但是别得意得太早了，如果你认为适配器模式就这么简单，那我告诉你，你错了！复杂的还在后面。
1700466457
1700466458
1700466459
1700466460
1700466462
设计模式之禅 19.3 适配器模式的应用
1700466463
1700466464
19.3.1 适配器模式的优点
1700466465
1700466466
❑适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成。
1700466467
1700466468
❑增加了类的透明性
1700466469
1700466470
想想看，我们访问的Target目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块是透明的，也是它不需要关心的。
1700466471
1700466472
❑提高了类的复用度
1700466473
1700466474
当然了，源角色在原有的系统中还是可以正常使用，而在目标角色中也可以充当新的演员。
1700466475
1700466476
❑灵活性非常好
1700466477
1700466478
某一天，突然不想要适配器，没问题，删除掉这个适配器就可以了，其他的代码都不用修改，基本上就类似一个灵活的构件，想用就用，不想就卸载。
1700466479
1700466480
1700466481
1700466482
1700466483
设计模式之禅 19.3.2 适配器模式的使用场景
1700466484
1700466485
适配器应用的场景只要记住一点就足够了：你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式，这也是我们例子中提到的。
1700466486
1700466487
1700466488
1700466489
1700466490
设计模式之禅 19.3.3 适配器模式的注意事项
1700466491
1700466492
适配器模式最好在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题，没有一个系统分析师会在做详细设计的时候考虑使用适配器模式，这个模式使用的主要场景是扩展应用中，就像我们上面的那个例子一样，系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。
1700466493
1700466494
再次提醒一点，项目一定要遵守依赖倒置原则和里氏替换原则，否则即使在适合使用适配器的场合下，也会带来非常大的改造。
1700466495
1700466496
1700466497
1700466498
[
上一页 ]
[ :1.700466449e+09 ]
[
下一页 ]