将状态模式与虚拟代理一起使用是否有意义？答案

【问题标题】：Does it makes sense to use state pattern with virtual proxies?将状态模式与虚拟代理一起使用是否有意义？
【发布时间】：2020-05-22 06:14:04
【问题描述】：

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();
    }
}

这个解决方案有意义吗？

代码有什么可能的改进吗？

以前有没有类似的例子？

这是不必要的并发症还是值得还是取决于具体情况？

它是否使代码更快？我的意思是，额外的函数调用可能比简单的条件调用要慢。

【问题讨论】：

标签： java oop design-patterns lazy-initialization state-pattern

【解决方案1】：

这是一个不必要的复杂问题还是值得还是这样做视情况而定？

虽然在使用 State Pattern 时只有 2 个状态是完全可以的，但在这种特殊情况下，这绝对是一种矫枉过正的做法，原因如下：

只有一个状态转换 UninitializedState -> InitailizedState。一次HeavyWeightObjcet 已经初始化了，你肯定不会从InitializedState -> UninitializedState 或反之亦然
我们有诸如YAGNI （你不需要它）和KISS（保持简单，愚蠢）之类的设计原则是有原因的。不要在代码的第一次迭代中引入复杂性。让设计成为持续重构的一部分。
虽然上述示例在纸面上看起来不错，但现实世界却完全不同。在现实世界的代码中还有更重要的问题需要解决。（例如，operate 方法是线程安全的吗？）

它是否使代码更快？我的意思是，额外的函数调用可能是比简单的条件要慢。

在性能方面，这个区域太小了，不用担心Read : micro-optimization

最后但并非最不重要的一点是，状态模式允许我们遵守Open-Closed principle.。如示例所示，就HeavyWeightObject 的初始化而言，operate 方法的更改没有令人信服的理由。此外，初始化代码首先应该在构造函数中，而不是operate方法中。

【讨论】：