状态模式

设计模式有哪些? 单例模式:单例模式对实例个数的控制并节约系统资源.在它的核心结构中只包含一个被称为单例类的特殊类,通过构造函数私有化和静态块以及提供对外访问的接口来实现. 应用场景：如果希望在系统中某个类的对象只能存在一个,单例模式是最好的解决方案。 工厂模式:工厂模式主要是为创建对象提供了接口 应用场景如下：在编码时不能预见需要创建哪种类的实例;系统不应依赖于产品类实例如何被创建、组合和表达的细节。 观察者模式:定义了对象间一对多的依赖关系，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新 应用场景如下：对一个对象状态的更新，需要其他对象同步更新，而且其他对象的数量动态可变；对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节； (实现参考https://www.jianshu.com/p/12a009f8d016) 来源： https://www.cnblogs.com/yh2two/p/11782347.html

职责链模式(Chain of Responsibility) 多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系， 将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止 典型应用：servlet filter 命令模式(Command) 命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式 将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化； 对请求排队或者记录请求日志，以及支持可撤销的操作。 命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开 五个角色： Command: 抽象命令类 ConcreteCommand: 具体命令类：持有一个接受者Receiver的引用，绑定一个特定的操作 Invoker: 调用者 Receiver: 命令接收者 Client:客户类 //抽象命令 public interface Command { void execute (); } //具体命令：开灯 public class LightOnCommand implements Command { private Light light ; public LightOnCommand ( Light light ) { this . light = light ; }

策略模式 1、策略模式介绍 实现某一个功能可以有多种算法或者策略，我们根据实际情况选择不同的算法或者策略完成该功能，一般就会用if…else或者switch…case语句来选择具体算法，需要增加一种新的排序算法时，需要修改封装算法类的源代码，违背了ocp原则和单一职责原则，将这些算法抽象出来提供一个统一的接口，不同算法有不同的实现类，让算法独立于使用它的客户而独立 2、策略模式的使用场景 （1）针对同一类型问题的多种处理方式，仅仅是具体行为有差别时 （2）需要安全地封装多种同一类型的操作时 （3）出现同一个抽象类有多个子类，又需要if…else switch-case选择具体子类时 3、策略模式的简单实现 建立一个策略的抽象，让具体的策略实现实现这个接口，Context则可以充当操作策略的上下文环境 一下例子为价格计算策略，它们都实现了calculatePrice这个接口的方法 以下代码为扮演Context角色的类 public class TranficCalculator { public static void main ( String [] args ){ TranficCalculator calculator = new TranficCalculator () calculator . setStrategy ( new BusStrategy (); }

【own】策略模式和状态模式，都是提取动态行为，解耦；if else 系列 策略模式： 在不确定具体行为，提取动态行为，便于后期维护；由于不确定具体的行为，所以行为对象会很多，不利于对象维护； 使用场景： 假设现在要设计一个贩卖各类书籍的电子商务网站的购物车系统。一个最简单的情况就是把所有货品的单价乘上数量，但是实际情况肯定比这要复杂。比如，本网站可能对所有的高级会员提供每本20%的促销折扣；对中级会员提供每本10%的促销折扣；对初级会员没有折扣。 　　根据描述，折扣是根据以下的几个算法中的一个进行的： 　　算法一：对初级会员没有折扣。 　　算法二：对中级会员提供10%的促销折扣。 　　算法三：对高级会员提供20%的促销折扣。 状态模式： 确定具体有几个状态，提取动态行为，不同状态有不同状态； 使用场景： 　考虑一个在线投票系统的应用，要实现控制同一个用户只能投一票，如果一个用户反复投票，而且投票次数超过5次，则判定为恶意刷票，要取消该用户投票的资格，当然同时也要取消他所投的票；如果一个用户的投票次数超过8次，将进入黑名单，禁止再登录和使用系统。 　　要使用状态模式实现，首先需要把投票过程的各种状态定义出来，根据以上描述大致分为四种状态：正常投票、反复投票、恶意刷票、进入黑名单。然后创建一个投票管理对象（相当于Context）。 状态模式与策略模式涉及到的角色： ●　　 环境

状态模式 也称状态机(State Machine)，简单用一句话解释就是：用对象定义具体状态，调用时指向具体状态对象的方法。 一、类图 状态模式包含以下主要角色。 环境（Context）角色：也称为上下文，它定义了客户感兴趣的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。 抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为。 具体状态（Concrete State）角色：实现抽象状态所对应的行为。 二、示例 用“状态模式”设计一个学生成绩的状态转换程序。包含了“不及格”“中等”和“优秀” 3 种状态，当学生的分数小于 60 分时为“不及格”状态，当分数大于等于 60 分且小于 90 分时为“中等”状态，当分数大于等于 90 分时为“优秀”状态，我们用状态模式来实现这个程序。 package state; public class ScoreStateTest { public static void main(String[] args) { ScoreContext account=new ScoreContext(); System.out.println("学生成绩状态测试："); account.add(30); account.add(40); account.add(45); account.add(-35);

1.策略模式※ 策略模式定义了算法家族，分别封装起来，让它们之间可以互相转换，此模式让算法的变化，不会影响到使用算法的用户。 策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。 在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。这本身并没有解除客户端需要选择判断的压力，所以策略模式配合常常可以简单工厂使用。 2.观察者模式※ 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化，关注它的对象就会得到通知；这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者。 class Observer { public: Observer() {}; ~Observer() {}; virtual void update(int) = 0; }; class ConCreteObserverA : public Observer { public: void update(int state) { cout << "A get state : " << state << endl;

状态模式 简介 　　在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。 特点 意图： 允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。 主要解决： 对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。 何时使用： 代码中包含大量与对象状态有关的条件语句。 使用场景： 1、行为随状态改变而改变的场景。 2、条件、分支语句的代替者。 需求 业务需求：公司架构一个模块需统计pdf纸张大小数量，需要利用开源的一个类库(itextsharp.dll)，纸张规格图如下，由于需要多个条件判断，第一想到了使用状态模式，以后便于维护，完整代码如下 实现 1)创建抽象类：State.cs namespace PdfUtui.GoF { public abstract class State { public abstract void Handle(Context context); } } 2)创建上下文：Context.cs namespace PdfUtui.GoF { public class Context { public State state { get; set; } public

上次我们很愉快的完成了状态模式的定义和代码的编写，但是在第一篇的时候我们说过，还需要实现一个抽十次中一次的功能，上次还没解决呢。 我们已经实现了状态模式，所以实现这个游戏应该易如反掌。首先，我们要在GumballMachine类中加入一个状态: State soldOutState; State noQuarterState; State hasQuarterState; State soldState; // 这是新加的状态 State winnerState; 然后，我们去实现WinnerState类本身，它和SoldState类很像: public class WinnerState implements State { GumballMachine gumballMachine; public WinnerState(GumballMachine gumballMachine) { this.gumballMachine = gumballMachine; } public void insertQuarter() { System.out.println("Please wait, we're already giving you a Gumball"); } public void ejectQuarter() { System.out.println("Please

　　状态模式又称对象模式，状态模式是对象的行为模式。 　　状态模式允许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样。 1.结构 　　用一句话来说，状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。 结构如下: 涉及到的角色如下: 环境(Context)角色，也成上下文：定义客户端所感兴趣的接口，并且保留一个具体状态类的实例。这个具体状态类的实例给出此环境对象的现有状态。 抽象状态(State)角色：定义一个接口，用以封装环境（Context）对象的一个特定的状态所对应的行为。 具体状态(ConcreteState)角色：每一个具体状态类都实现了环境（Context）的一个状态所对应的行为。 源代码如下: 环境角色： public class Context { private State state; public void setState(State state) { this.state = state; state.handleState(); } public State getState() { return state; } } 抽象状态: /** * 状态类 * * @author Administrator * */

一、创建类设计模式 前言 什么样的程序员是一个好的程序员？学会很多门编程语言，就是一个好的程序员了么？事实上，学会一门编程语言不是一件很难的事，而“学会”一门编程语言是非常难的一件事。前一个“会”强调“能”，懂语法，能写简单的程序就算是前者的“会”了；后一个“会”，强调“精”，显然，光能写出“Hello World”并不算是后者的“会”，能熟练应用，并用编程语言解决各种问题，才算是真正的“会”。 点击阅读详情 1、Python与设计模式--单例模式 总线是计算机各种功能部件或者设备之间传送数据、控制信号等信息的公共通信解决方案之一。现假设有如下场景：某中央处理器（CPU）通过某种协议总线与一个信号灯相连，信号灯有64种颜色可以设置，中央处理器上运行着三个线程，都可以对这个信号灯进行控制，并且可以独立设置该信号灯的颜色。抽象掉协议细节（用打印表示），如何实现线程对信号等的控制逻辑。 加线程锁进行控制，无疑是最先想到的方法，但各个线程对锁的控制，无疑加大了模块之间的耦合。下面，我们就用设计模式中的单例模式，来解决这个问题。 什么是单例模式？单例模式是指：保证一个类仅有一个实例，并提供一个访问它的全局访问点。具体到此例中，总线对象，就是一个单例，它仅有一个实例，各个线程对总线的访问只有一个全局访问点，即惟一的实例。 点击阅读详情 2、Python与设计模式--工厂类相关模式