Question

所以我们都知道好的'ol Decorator模式，特别是我在互联网上找不到这样的缺点。但是有一个我能想到的大问题：

如果你的基类碰巧是笨重的（拥有50个字段）并且你决定装饰它：

public class BulkyBaseClass {

    // 50 fields
    //...
}

class Decorator extends BulkyBaseClass{

    private BulkyBaseClass mBase;

    public Decorator(BulkyBaseClass bulkyBaseClass){
        this.mBase = bulkyBaseClass;
    }

    // Some overrides to decorate the composed base class
}

然后，我们不能在这里看到装饰器本身的大多数字段都是无用的，我们真的只对正在装饰的类的字段感兴趣并且会导致大量的内存占用吗？

对我而言，这是一个很大的劣势。不是吗？

Answer 1

是的，直接使用装饰器模式对于具有多个字段的类确实有缺点，因为它们的大多数在包装mBase实例的派生类中仍未使用。

但是，缺点源于继承实现，而不是继承接口。因此，您可以通过从BulkyBaseClass提取接口并在Decorator类中使用它来轻松修复它：

interface LeanInterface {
    void method1();
    int method2();
}
class BulkyBaseClass implements LeanInterface {
    ...
}
class Decorator implements LeanInterface {
    private BulkyBaseClass mBase;
    ...
}

Answer 2

这不是装饰问题，而是另一个继承问题。

尽可能通过接口进行装饰，如下所示：

public interface Connection {
    void connect();

    void write(byte[] data) throws IOException;
}

public final class ReconnectingConnection implements Connection {
    private final Connection delegate;

    public ReconnectingConnection(Connection delegate) {
        this.delegate = delegate;
    }

    ...
    @Override
    public void write(byte[] data) {
        ...reconnect on exception from delegate.write()...
    }
}

在接口上使用自己的实现可以确保您实际上没有耦合到特定的实现，并且还避免了某些实现太大的问题。

当面对你要装饰的外部课程时，这显然并非总是可行。

Decorator模式对于具有许多字段的“庞大”类有缺点吗？

2 个答案: