将状态模式与虚拟代理一起使用是否有意义?
Does it makes sense to use state pattern with virtual proxies?
class HeavyweightObjcet
{
public void operate() {
System.out.println("Operating...");
}
}
class LazyInitializer
{
HeavyweightObjcet objcet;
public void operate()
{
if (objcet == null)
objcet = new HeavyweightObjcet();
objcet.operate();
}
}
这里我正在为一个重量级对象制作一个虚拟代理。每次调用HeavyweightObject::operate
之前,程序首先检查对象是否为null
。这部分在对象的整个生命周期中只检查一次。
可能的改进可能是使用这样的状态模式:
class HeavyweightObjcet
{
public void operate() {
System.out.println("Operating...");
}
}
class LazyInitializer
{
HeavyweightObjcet objcet;
State state = new UninitializedState(this);
public void operate()
{
state.operate();
}
}
abstract class State
{
LazyInitializer initializer;
public State(LazyInitializer initializer)
{
this.initializer = initializer;
}
abstract void operate();
}
class UninitializedState extends State
{
public UninitializedState(LazyInitializer initializer) {
super(initializer);
}
@Override
public void operate() {
initializer.objcet = new HeavyweightObjcet();
initializer.state = new InitializedState(initializer);
initializer.operate();
}
}
class InitializedState extends State
{
public InitializedState(LazyInitializer initializer) {
super(initializer);
}
@Override
public void operate() {
initializer.objcet.operate();
}
}
这个解决方案有意义吗?
代码是否有任何可能的改进?
有没有以前做过的类似的例子?
这是不必要的并发症还是值得,还是要视情况而定?
它会使代码更快吗?我的意思是,额外的函数调用可能比简单的条件调用慢。
Is it an unnecessary complication or does it worth it or does it
depend on the situation?
虽然在使用 State Pattern 时只有 2 个状态完全没问题,但出于以下原因,在这种特殊情况下绝对是一种矫枉过正的做法:
- 只会有一次状态转换
UninitializedState
-> InitailizedState
。一次 HeavyWeightObjcet
已经初始化,你绝对不会
在从 InitializedState
-> UninitializedState
或
反之亦然
- 我们有YAGNI (You aren't gonna need it) and KISS(Keep it simple, stupid)这样的设计原则是有原因的。不要在代码的第一次迭代中引入复杂性。让设计成为持续重构的一部分。
- 虽然上面的例子在纸面上看起来不错,但现实世界完全是另一回事。在现实世界中,代码中还有更重要的问题需要解决。 (例如,
operate
方法是线程安全的吗?)
Does it make the code faster? I mean, the extra function calls may be
slower than just a simple conditional.
就性能而言,这个区域太小了,无需担心 Read : micro-optimization
最后但同样重要的是,状态模式 允许我们遵守 Open-Closed principle.。正如示例所示,就 HeavyWeightObject
的初始化而言,没有令人信服的理由让 operate
方法发生变化。此外,初始化代码应该放在构造函数中,而不是首先放在 operate
方法中。
class HeavyweightObjcet
{
public void operate() {
System.out.println("Operating...");
}
}
class LazyInitializer
{
HeavyweightObjcet objcet;
public void operate()
{
if (objcet == null)
objcet = new HeavyweightObjcet();
objcet.operate();
}
}
这里我正在为一个重量级对象制作一个虚拟代理。每次调用HeavyweightObject::operate
之前,程序首先检查对象是否为null
。这部分在对象的整个生命周期中只检查一次。
可能的改进可能是使用这样的状态模式:
class HeavyweightObjcet
{
public void operate() {
System.out.println("Operating...");
}
}
class LazyInitializer
{
HeavyweightObjcet objcet;
State state = new UninitializedState(this);
public void operate()
{
state.operate();
}
}
abstract class State
{
LazyInitializer initializer;
public State(LazyInitializer initializer)
{
this.initializer = initializer;
}
abstract void operate();
}
class UninitializedState extends State
{
public UninitializedState(LazyInitializer initializer) {
super(initializer);
}
@Override
public void operate() {
initializer.objcet = new HeavyweightObjcet();
initializer.state = new InitializedState(initializer);
initializer.operate();
}
}
class InitializedState extends State
{
public InitializedState(LazyInitializer initializer) {
super(initializer);
}
@Override
public void operate() {
initializer.objcet.operate();
}
}
这个解决方案有意义吗?
代码是否有任何可能的改进?
有没有以前做过的类似的例子?
这是不必要的并发症还是值得,还是要视情况而定?
它会使代码更快吗?我的意思是,额外的函数调用可能比简单的条件调用慢。
Is it an unnecessary complication or does it worth it or does it depend on the situation?
虽然在使用 State Pattern 时只有 2 个状态完全没问题,但出于以下原因,在这种特殊情况下绝对是一种矫枉过正的做法:
- 只会有一次状态转换
UninitializedState
->InitailizedState
。一次HeavyWeightObjcet
已经初始化,你绝对不会 在从InitializedState
->UninitializedState
或 反之亦然 - 我们有YAGNI (You aren't gonna need it) and KISS(Keep it simple, stupid)这样的设计原则是有原因的。不要在代码的第一次迭代中引入复杂性。让设计成为持续重构的一部分。
- 虽然上面的例子在纸面上看起来不错,但现实世界完全是另一回事。在现实世界中,代码中还有更重要的问题需要解决。 (例如,
operate
方法是线程安全的吗?)
Does it make the code faster? I mean, the extra function calls may be slower than just a simple conditional.
就性能而言,这个区域太小了,无需担心 Read : micro-optimization
最后但同样重要的是,状态模式 允许我们遵守 Open-Closed principle.。正如示例所示,就 HeavyWeightObject
的初始化而言,没有令人信服的理由让 operate
方法发生变化。此外,初始化代码应该放在构造函数中,而不是首先放在 operate
方法中。