首先,设计模式( Design Pattern )是指面向对象设计模式,是“年迈”程序员对代码开放经验的总结,解决特定问题的一系列套路。目的是用来提高代码可复用性、可维护性、可读性、稳健性以及安全性。
所以设计模式不是什么理论,也不是语法规定,没有对与错,只有合不合适或者好与不好。
另外不能为了使用设计模式而去做架构,而是有了做架构的需求,这种架构层次在进行基本展开后发现它符合某一类设计模式的结构,再将两者结合。
时间充裕的话可以来看下 P8 工程师的干货分享:大厂高频设计模式应用及分析
要正确地使用设计模式,首先要了解有哪些设计模式及其使用场景。
设计模式按使用场景可以分为三大类
3 大类之下又可以分出 23 种设计模式,这里就不一一赘述了。学习设计模式,死记硬背是没用的,还是要在实践中来理解。
下面我结合实例来讲下如何使用设计模式——用适配器模式扩展我们的架构。
首先,要知道适配器模式的目的是**重用,**重用在工程实践中往往比编程更有价值。
其次,适用场景:现有的对象(类)有和当前场景相似的能力,但又有明显差异时运用。
基本思想就是**“封装”和“继承”:封装差异、继承能力。**
假设,现在我们有这样一个 class,拥有底层的显示商城 Banner 的能力:
我们期望编写这样一个类:CreateBannerView,其中实现两个方法:
①showBannerOnCell - 在手机设备上显示 Banner
②showBannerOnPc - 在 PC 设备上显示 Banner
所以我们可以找到这里存在的 Gap:实际需要是实现在不同设备上的显示 Banner,我们拥有按尺寸进行显示 Banner 的能力。
初学者的写法一般是这样的:
缺点是上游对象必须去感知下游对象的实现方式(耦合),BannerSize 的参数被硬编码了,如果要去 pad 上实现呢?
我们的策略可以用一句话来概括:**“间接”是程序员解决架构问题的钥匙。**具体来说继承方式是扩展一个抽象子类,增加一个确定 BannerSize 的能力:
这样我们的子类中,就被强制要求实现这样一种能力:
这里有个问题:抽象方法里面放一个类似“设备类型”的参数不好么?
回答:底层不应该主动感知上层怎么用,无论是设备类型还是 APP 类型,这个变化都不应该穿透到底层。
那么这个继承方式能否进一步优化?其实是可以的
就单一方法来看,无疑已经很简单了,但是我们仍然希望构造 Banner 使用参数的行为不要在这一个层次中出现,这样就需要适配器模式出场了。
继续利用好抽象类这一层次
子类只需要感知它应该感知的部分
现在我们介绍适配器模式的一种实现——委托
委托即把适配、调用底层的而工作交给别的对象来做。
委托的目的在于进一步解耦,即将场景感知与底层能力进一步隔离。
委托的实现有两个关键点:
通过接口,定义底层适配后开放两个接口:
改造 CreateBannerView 为委托类,委托类实现整体接口能力。
真正的子类,严格匹配场景,通过委托对象调用适配后的底层能力。
以上,用一张 UML 图概括一下:
最后总结一下
为什么要使用适配器模式?
将一些“现存的对象”放到新的环境钟,而新环境要求的接口是现对象不能满足的,使用适配器模式让他满足。
适配器模式的优缺点?
优点:
缺点:
适配器模式的使用场景
以上这些也是 Java 高级工程师面试中经常出现的问题,在 P8 技术专家主讲的《Java 高级工程师 P6+》会有详尽的讲解,内容涵盖 Java 技术栈的通透讲授、源码的分析导读、贴近实际的工程实践以及大厂思维的架构升级。有兴趣的同学,可以来看看~