中关村在线,企业网站seo实,口碑营销渠道,烟台专业的网站建站公司作者简介#xff1a;大家好#xff0c;我是smart哥#xff0c;前中兴通讯、美团架构师#xff0c;现某互联网公司CTO 联系qq#xff1a;184480602#xff0c;加我进群#xff0c;大家一起学习#xff0c;一起进步#xff0c;一起对抗互联网寒冬 在上一篇设计山寨版Str…作者简介大家好我是smart哥前中兴通讯、美团架构师现某互联网公司CTO 联系qq184480602加我进群大家一起学习一起进步一起对抗互联网寒冬 在上一篇设计山寨版Stream API时有一个技巧被频繁使用接口多态。 接口用的是函数式接口即接口内部有且仅有一个抽象方法。 多态原本指的是接口下有多个子类实例可以指向接口引用但由于函数式接口恰好仅有一个方法此时接口多态等同于“方法多态”即一个抽象方法拥有多个不同的具体实现。 接口多态
我们都知道Java是面向对象的语言它具备多态性。私以为多态的精髓在于晚绑定。什么意思呢
PocketMon pocketMon new Pikaqiu();
pocketMon.releaseSkill();
只看pocketMon.releaseSkill()你能猜出来技能是电击还是喷火吗 哦一眼就看出来了 这样呢
Properties pro new Properties();
FileInputStream in new FileInputStream(pocketmon.properties);
pro.load(in);
PocketMon pocketMon Class.forName(pro.getProperty(nextPocketMon)).newInstance();
pocketMon.releaseSkill();
完全看不出来了。
即使你打开pocketmon.properties看了是皮卡丘运行时虚拟机看到的可能是我修改后的喷火龙。 这种现象其实很奇妙明明代码都写死了但虚拟机却无法提前确定具体会是哪只神奇宝贝在调用releaseSkill()除非实际运行到这行代码。而这正是得益于多态。
多态的原理本质是还是JVM层面通过运行时查找方法表实现的。可以简单理解为JVM在运行时需要去循环遍历这个方法对应的多态实现选择与当前运行时对象匹配的方法进行调用。所以从理论上来说晚绑定的多态在性能上是不如早绑定的直接写死不用多态。而多态是设计模式的灵魂所以对于一些非常、非常、非常要求性能的场景来说过于繁重的设计反而会降低性能。说白了这世上就不存在多、快、好、省。 多态是“晚绑定”思想的体现对于Java而言方法的调用并不是编译时绑定而是运行时动态绑定的取决于引用具体指向的实例。 方法多态
我生造了“方法多态”这个概念但这个概念在函数式接口的前提下是站得住脚的而且有利于跳出面向对象贴近函数式编程。 我们来看一个需求
要求写一个cook()方法传入鸡翅和可乐你给我做出可乐鸡翅。 很多人可能下意识地就把代码写死了
public static CokaChickenWing cook(Chicken chicken, Coka coka){1.放油、放姜;2.放鸡翅;3.倒可乐;4.return CokaChickenWing;
}
但是网上也有人说应该先倒可乐再放鸡翅每个人的口味不同做法也不同。有没有办法把这两步延迟确定呢让调用者自己来安排到底是先倒可乐还是先放鸡翅。 可以这样
public static CokaChickenWing cook(Chicken chicken, Coka coka, function twoStep){1.放油、放姜;2~3.twoStep();4.return CokaChickenWing;
}
想法很好既然这两步不确定那么就由调用者来决定吧让调用者自己传进来。 我们知道Java是不能直接传递方法的但利用策略模式可以解决这个问题。 定义一个接口
interface TwoStep {void excute();
}
然后呢
public static CokaChickenWing cook(Chicken chicken, Coka coka, TwoStep twoStep){1.放油、放姜;2~3.twoStep.excute();4.return CokaChickenWing;
}
这里twoStep.excute()是确定的吗 没有。 你说它是先倒可乐再放鸡翅我偏要说它是先放鸡翅再倒可乐反正接口也没方法体具体实现要看你传进来什么对象。 所以twoStep.excute()充其量只是先替“某些操作占个坑”后面再确定。 什么时候确定呢
main(){TwoStep twoStep new TwoStep(){Overridepublic void excute(){2.先放鸡翅3.再倒可乐}}// 调用cook时确定运行时cook(chicken, coka, twoStep);
}public static CokaChickenWing cook(Chicken chicken, Coka coka, TwoStep twoStep){1.放油、放姜;2~3.twoStep.excute();4.return CokaChickenWing;
} 来学过Lambda表达式后我们换个时髦的写法
main(){// 调用cook时确定 方案1cook(chicken, coka, (鸡翅, 可乐) - 2.先放鸡翅3.再倒可乐);// 调用cook时确定 方案2cook(chicken, coka, (鸡翅, 可乐) - 2.先倒可乐3.再放鸡翅);
}public static CokaChickenWing cook(Chicken chicken, Coka coka, TwoStep twoStep){1.放油、放姜;2~3.twoStep.excute();4.return CokaChickenWing;
}
这就是我所谓的“方法多态”通过函数式接口把形参的坑占住后续传入不同的Lambda实现各自逻辑。 晚绑定与模板方法模式
在设计模式中策略模式和模板方法看起来有点像但其实不一样。策略模式使用接口占坑然后传入实际对象调用需要的方法而模板方法模式是用抽象方法占坑粒度其实小一些。 晚绑定最典型的应用就是模板方法模式抽象类确定基本的算法骨架把不确定的、变化的部分做成抽象方法剥离出去由子类来实现。 还是以发送验证码为例
/*** 验证码发送器** author mx*/
public abstract class AbstractValidateCodeSender {/*** 生成并发送验证码*/public void sendValidateCode() {// 1.生成验证码String code generateValidateCode();// 2.把验证码存入Session// ....// 3.抽象方法占坑用于发送验证码sendCode();}/*** 具体发送逻辑留给子类实现发送邮件、或发送短信都行*/protected abstract void sendCode();/*** 生成验证码** return*/public String generateValidateCode() {return 123456;}}
对于上面的模板我们可以有多种实现方式以便把sendCode()这个坑填上
/*** 短信验证码发送** author mx*/
public class SmsValidateCodeSender extends AbstractValidateCodeSender {Overrideprotected void sendCode() {// 通过阿里云短信发送}
}
/*** QQ邮箱验证码发送** author mx*/
public class EmailValidateCodeSender extends AbstractValidateCodeSender {Overrideprotected void sendCode() {// 通过QQ邮箱发送}
}
作者简介大家好我是smart哥前中兴通讯、美团架构师现某互联网公司CTO 进群大家一起学习一起进步一起对抗互联网寒冬
