• 135235

    文章

  • 827

    评论

  • 13

    友链

  • 最近新加了换肤功能,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

[head first 设计模式] 第一章 策略模式

2年想跳槽阿里,大咖揭秘大厂面试的那些事儿 >>
关于策略模式介绍

[head first 设计模式] 第一章 策略模式

让我们先从一个简单的鸭子模拟器开始讲起。

假设有个简单的鸭子模拟器,游戏中会出现各种鸭子,此系统的原始设计如下,设计了一个鸭子超类,并让各种鸭子继承此超类。

1.jpg

若此时我们有了一个新的需求,我们需要鸭子会飞,那么我们该如何修改代码呢?

最初,我们想在基类上加上fly方法,使得所有子类鸭子都拥有相应的fly方法。但这样错误产生了,即使是本不该会飞的橡皮鸭子也拥有了fly方法。

或许我们可以把橡皮鸭中的fly方法覆盖掉,但这样每次新加入的不会飞的新鸭子类型,难道都要额外覆盖一次fly方法吗?太麻烦了。

利用继承来提供duck的行为,会导致运行时的行为不容易改变,且改变容易牵一发动全身。

那么,利用接口如何?

若经常需要更新产品,那么每次覆盖fly简直是噩梦。那么,我们将fly单独写成一个接口,只有会飞的鸭子实现这个接口如何?

2.jpg

但这样其实重复的代码会变得非常多,造成fly代码无法复用,每个会飞的鸭子都要实现fly方法。

那么我们该如何解决这个问题?在使用设计模式之前,不妨先求索于OO原则!

软件开发中,什么是永恒真理?

唯一不变的是变化本身——约翰逊·斯宾塞

现在我们已经知道了继承无法很好的解决问题,因为鸭子的行为在子类中不断改变,并且有的行为子类不应该拥有。使用接口初看挺不错的,但继承接口无法达到代码的复用。这意味着,无论合适你需要修改某个行为,你必须向下追踪并在每一个定义此行为的类中修改它。

但还好,有一个OO设计原则正好适用于此种情况:

找出系统中可能需要变化之处,把他们独立出来,不要和那些不变化的代码堆在一起。

也就是把会变化的部分取出来,好让其他部分不会受此影响。

把会变化的部分取出来并封装,以后可以轻易地改动或扩充此部分,而不影响其他不需要变化的部分。

那么,现在是时候把鸭子的行为从Duck类中取出了。

分开变化和不会变化的部分

目前而言,除了fly()和quack()以外,duck类其他部分看起来不怎么变动,所以我们仅做些小改变。

为此,我们准备建立两组类,一个是和fly相关的,另一个和quack相关的,每一组类都实现各自的动作。

3.jpg

设计鸭子的行为

如何设计

那组实现飞行和叫声的类呢?我们希望一切能有弹性,并且能够将行为指定到鸭子的实例。并且可以让鸭子的行为动态的改变。

有了这些目标要实现,我们看第二个设计原则

针对接口编程,而不是针对实现编程。

从现在开始,鸭子的行为将被放在分开的类中,此类专门提供某行为接口的实现。这样,鸭子类就不再需要知道行为的具体细节。

这次鸭子类不会负责实现flying和quacking接口,而是由我们制造一组其他类专门实现flybehavior和quackbeavior,这就称为行为类,由行为类而不是duck类来实现行为接口。

这种做法和以往不同,以往是行为来自于duck超类的具体实现,或是继承某个接口并由子类自行实现而来。这两种方法都是依赖于实现,没法变更行为。

在我们的新设计中,鸭子的子类将使用接口所表示的行为,所以具体的实现不会被绑定在鸭子的子类中。

4.jpg

整合鸭子的行为

关键在于,鸭子会将飞行和叫声行为委托给其他对象处理。而不是由自己定义。

在Duck类中加入flyBehavior和quackBeh.........


695856371Web网页设计师②群 | 喜欢本站的朋友可以收藏本站,或者加入我们大家一起来交流技术!

0条评论

Loading...


发表评论

电子邮件地址不会被公开。 必填项已用*标注

自定义皮肤 主体内容背景
打开支付宝扫码付款购买视频教程
遇到问题联系客服QQ:419400980
注册梁钟霖个人博客