重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
一. 责任链模式
创新互联公司坚持“要么做到,要么别承诺”的工作理念,服务领域包括:网站建设、网站设计、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的龙江网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!
这种模式中,有发送者和接收者。通常,每个接收者都包含对另一个接收者的引用,形成一条链,如果一个接收者不能处理该请求,那么它会把相同的请求传给下一个接收者,依次类推。
这种模式将请求的发送者和接收者解耦,但是不能保证请求一定被接收。
使用场景是有1. 多个对象可以处理同一个请求,具体哪个对象处理该请求由运行时刻自动确定。2. 在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。 3. 可动态指定一组对象处理请求。
这里有个特别形象的例子:
假设现在有个需求来了,首先是实习生拿到这个需求。
如果实习生能够实现,直接实现。如果不行,他把这个需求交给初级工程师。
如果初级工程师能够实现,直接实现。如果不行,交给中级工程师。
如果中级工程师能够实现,直接实现。如果不行,交给高级工程师。
如果高级工程师能够实现,直接实现。如果不行,交给 CTO。
如果 CTO能够实现,直接实现。如果不行,直接跟产品说,需求不做。
这种模式和装饰者模式有一定相似的地方。
二. 命令模式
根据菜鸟教程的描述,“在软件系统中,行为请求者与行为实现者通常是一种紧耦合的关系,但某些场合,比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合适”。
对于这个描述,我现在的理解不深。我理解的是,将一个请求用一个对象进行封装,相当于在请求的发起者和请求之间加多一层,以便将请求者与请求进行解耦。
三. 解析器模式
这个看不太明白,感觉没有应用的场景。
四. 迭代器模式
对这个理解的也不深,感觉用的也不多。
五. 中介者模式
用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类,该类通常处理不同类之间的通信,并支持松耦合,使代码易于维护。
具体的做法是将交联型(网状)的关系转化为星型关系,1、系统中对象之间存在比较复杂的引用关系,导致它们之间的依赖关系结构混乱而且难以复用该对象。 2、想通过一个中间类来封装多个类中的行为,而又不想生成太多的子类。缺点可能是中介者会庞大,变得复杂难以维护。具体的应用有mvc中的c的作用。
六. 备忘录模式(应用比较少?)
主要解决:所谓备忘录模式就是在不破坏封装的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样可以在以后将对象恢复到原先保存的状态。
何时使用:很多时候我们总是需要记录一个对象的内部状态,这样做的目的就是为了允许用户取消不确定或者错误的操作,能够恢复到他原先的状态,使得他有"后悔药"可吃。
如何解决:通过一个备忘录类专门存储对象状态。
关键代码:客户不与备忘录类耦合,与备忘录管理类耦合。
应用实例: 1、后悔药。 2、打game时的存档。 3、Windows 里的 ctri + z。 4、IE 中的后退。 4、数据库的事务管理。
优点: 1、给用户提供了一种可以恢复状态的机制,可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装,使得用户不需要关心状态的保存细节。
缺点:消耗资源。如果类的成员变量过多,势必会占用比较大的资源,而且每一次保存都会消耗一定的内存。
七. 观察者模式
当对象间存在一对多关系时,则使用观察者模式(Observer Pattern)。比如,当一个对象被修改时,则会自动通知它的依赖对象。观察者模式属于行为型模式。应用是mvc中的事件机制。
八. 状态模式
将一个状态封装为一个对象(状态对象),这个对象会依赖于持有该状态的对象。状态对象有一个或多个方法改变持有状态的对象的行为。应用有: 状态机,行为树的动作节点等。
九. 空对象模式
to be continued……
十. 策略模式
意图:定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
主要解决:在有多种算法相似的情况下,使用 if...else 所带来的复杂和难以维护。
何时使用:一个系统有许多许多类,而区分它们的只是他们直接的行为。
如何解决:将这些算法封装成一个一个的类,任意地替换。
关键代码:实现同一个接口。
应用实例: 1、诸葛亮的锦囊妙计,每一个锦囊就是一个策略。 2、飞机game里面的bullet。
优点: 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点: 1、策略类会增多。 2、所有策略类都需要对外暴露。
十一. 模板模式
to be continued……
十二. 访问者模式
to be continued……
to be continued