State设计模式上篇(理论篇)

State设计模式理论篇

参考了王备战老师的ppt,相当于是一次期末复习总结吧

⭐目标:目前的需求是我所制作的OJ项目在面临代码提交结果以及运行结果时对于其中的各个状态(如:通过!编译失败等等诸多状态进行代码开发时,很容易代码一不小心就写烂了,写到连自己都无法看懂的地步,所以尝试解决)

State适用性

一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。

一个操作中含有庞大的多分支语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举量表示。

State模式将每个条件分支放入一个独立的表示状态及其行为的类中。

目前判定可能可行,我们可以将对应判题结果归于对应的状态,而例如说编译失败状态,我们就不用再填装第一个没有通过的测试用例
不过不满足的地方也有,我们的需求主要是根据对应代码沙箱返回结果来赋值对应的代码提交结果

效果

它将与特定状态行为相关的行为局部化，并且将不同状态的行为分割开来。

这一句其实没有给我较大的启发,但是我却想到了另外的一个思路,不妨我也照着对应的金库保安系统抽象出一个提交结果管理员(类),由他们来进行对应的操作,例如说接收到对应的代码沙箱执行结果后,进行对应的操作,根据返回结果的状态修改其自身,同时让其能够拥有对应的状态该操作的能力

UML

State Pattern的参与者：

State：不同状态下所有方法的集合

ConcreteState:具体的不同的状态下的行为，实现了State

Context：（上下文）Context和SafeFrame，Context接口负责规定API，而SafeFrame则是 拥有 具有ConcreteState们的参与者。

更具体的UML

环境类与抽象状态类的作用：

•环境类实际上就是拥有状态的对象，环境类有时候可以充当状态管理器(State Manager)的角色，可以在环境类中对状态进行切换操作，它的实例定义了当前的状态。

•抽象状态类可以是抽象类，也可以是接口，不同状态类就是继承这个父类的不同子类。状态类的产生是由于环境类存在多个状态，同时还满足两个条件：1、这些状态经常需要切换；2、在不同的状态下对象的行为不同。因此可以将不同对象下的行为单独提取出来封装在具体的状态类中，使得环境类对象在其内部状态改变时可以改变它的行为，对象看起来似乎修改了它的类，而实际上是由于切换到不同的具体状态类实现的。由于环境类可以设置为任一具体状态类，因此它针对抽象状态类进行编程，在程序运行时可以将任一具体状态类的对象设置到环境类中，从而使得环境类可以改变内部状态并且改变行为。

启发

Divide and Conquer:分割控制，分体分解。State Pattern利用类表示系统状态，依据状态分解了复杂的系统。OO的核心就是代码的责任分解：单一职责原则。因为任何改动和变化都是致命的，如同刻板印刷一下。

有状态才会有处理，因状态而异的处理。

状态模式允许对象（CONTEXT）在内部状态改变时改变它的行为，对象看起来好像修改了它的类。实际上，我们是在使用组合通过引用不同的状态对象来造成类改变的假象。

Context的客户对于状态对象了解不多，甚至浑然不知。

总结

综合看来是可以的,我们甚至可以结合一下对应的工厂方法来进行生产对应的JudgeRes

2024/6/4号更新下章(尝试落地)