装饰者模式在具有许多字段的"臃肿"类中是否存在缺点？

Question

我们都知道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
}

那么，我们难道不能看到这里装饰器本身的大多数字段都是无用的，我们真正感兴趣的只是被装饰的类的字段，这会导致很大的内存占用吗？

对我来说，这是一个很大的缺点。不是吗？

- Manish Kumar Sharma

---

如果“_你的基类很庞大_”，那么它不应该是单一的类。一个有50个字段的类是一个巨大的警示标志。 - Boris the Spider

@BoristheSpider：但作为一名Android开发者，你会发现一些基本类（如View类）相当臃肿，我看到有人在SO上应用了装饰器模式。我立即感到警觉，不知道是否要采纳那个答案。 - Manish Kumar Sharma

Answer 1

是的，直接使用装饰器模式确实有一个缺点，对于具有多个字段的类来说，它们的大部分在包装“mBase”实例的派生类中保持未使用。

然而，这个缺点源于继承实现，而不是继承接口。因此，您可以通过从“BulkyBaseClass”中提取一个接口，并在“Decorator”类中使用它来轻松解决这个问题：

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

- Sergey Kalinichenko

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

使用自己的接口实现可以确保您不会与特定实现耦合，并避免某些实现过大的问题。当面对外部类需要装饰时，显然这并不总是可行的。

- Robert Bräutigam