首页 > 代码库 > 再回首——行为型设计模式
再回首——行为型设计模式
行为型
?生活中的实例:订阅网站。
通过类图来分析观察者的优缺点：
设计模式被分成三大类，创建型，结构型，行为型。具体要阐述为什么这么分，这个问题，暂时解决不了，但是我们能做的是，合理的运用它。对于行为型设计模式，区别于其他两种的就是：它侧重的是对“方法”的操作。
下面是对几个行为型的设计模式的理解。
一、模板方法
1、概述
1、概述
将一个操作的算法的骨架和具体算法实现分离——解耦
? ?骨架在父类中，算法延迟到子类实现，就可以有N多实现——多态的体现
? ?骨架在父类中，算法延迟到子类实现，就可以有N多实现——多态的体现
回顾一下类图，看看模板解决的问题：
?模板的眼:；解决代码重复，会算法有既定顺序。
使用继承，解决代码重复的问题，重复的代码抽象成一个基类，做成模板；杜绝子类出现不变的代码，模板就是为了给子类瘦身。
基类中有代码实现:这里抽象出来不单单是某几个方法声明，方法中是可以有代码实现的。只要是会发生重复的就放到父类中。
算法顺序：父类中（模板）必须有一个既定的方法来执行算法顺序——算法的骨架，是既定的
子类只是不同算法的实现父类，不改变算法结构
算法的骨架是既定的，可以修改吗？要不要修改？
这里的算法骨架顺序跟建造模式类似，顺序基本是稳定。怎么说呢？
一般使用这两种模式的“事物”，它的构成顺序都是稳定的，不是经常需要变动的，这是一个前提，但是并不是说，这个顺序一定不可以改变，为了灵活编程，可以通过委托来实现。往委托队列注册的过程就是排序的过程，委托是一大块，不多说了。
? 子类可以扩展父类吗？
当然是可以扩展的，因为是继承呀。但是个人认为没有多大意义。如果只是为了添加方法到子类中，跟复写方法无关联，那就是有点破坏单一原则的味道了。
3、建造模式VS模板模式
3、建造模式VS模板模式
?相同:都有既定的顺序，仅此而已。
?不同:两个设计模式的适用范围不同，解决问题不同，一个是创建型，一个是行为型，其他就不用啰嗦了吧。
二、观察者
?1、观察者的几点认识
一对多的依赖关系
多个对象观察一个主题
主题发生变化，观察的对象随之变化
?生活中的实例:订阅网站。
通过类图来分析观察者的优缺点：
?优点:解耦是观察者的一大特色。通过依赖倒转，面向接口编程的思想，给多个观察者增加父类接口，让被通知者成为主动观察者，来实现观察者和主题的衔接。
?不足:主题只能和一种类型的观察者进行关联——从途中可以看出所有的观察者都是继承自一个父类：observer，所以这些观察者都是一个父类，要想增加多个类型的观察者，便有心无力了。
?2、观察模式进阶委托
那要是我想通知多个类型的观察者怎么办？答案还是——委托?
想要通知其他类型的观察者，需要如下改动:最大的局限就是这个抽象的接口——observer，那么就把它去掉。
抽象类不存在，那么主题中通知的方法（notify）就没有意义了，也去掉。
将动态通知观察者的权利从主题移交给调用者。——主题和观察者彻底解耦。
声明委托，在调用短端注册各种类型的观察者，执行调用。
三、策略模式:封装算法，算法变化不影响用户使用。
??（具体的在上篇博客中已经写到了）
总结：行为型的设计模式还有：职责链，命令，解释，迭代，中介者，备忘录，状态，访问者模式。这里只写了三个，其他的几个没有这几个上手。对于剩下的几个模式：我们本着一个这样的原则：what？when？how？
??（具体的在上篇博客中已经写到了）
总结：行为型的设计模式还有：职责链，命令，解释，迭代，中介者，备忘录，状态，访问者模式。这里只写了三个，其他的几个没有这几个上手。对于剩下的几个模式：我们本着一个这样的原则：what？when？how？
再回首——行为型设计模式
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。