IDisposable 的享元和工厂问题

Question

我似乎在精神上陷入了享元模式的困境。

首先，假设我有一个一次性类型 DisposableFiddle 和一个工厂 FiddleFactory：

public interface DisposableFiddle : IDisposable
{
    // Implements IDisposable
}

public class FiddleFactory
{
    public DisposableFiddle CreateFiddle(SomethingThatDifferentiatesFiddles s)
    {
        // returns a newly created fiddle.
    }
}

那么，在我看来，FiddleFactory 的客户端就很清楚了工厂声称对所制作的小提琴没有所有权，并且客户有责任在使用完小提琴后将其处理掉。

然而，我们可以说，我想通过使用 Flyweight 模式在客户之间共享小提琴：

public class FiddleFactory
{
    private Dictionary<SomethingThatDifferentiatesFiddles, DisposableFiddle> fiddles = new ...;        

    public DisposableFiddle CreateFiddle(SomethingThatDifferentiatesFiddles s)
    {
        // returns an existing fiddle if a corresponding s is found,
        // or a newly created fiddle, after adding it to the dictionary,
        // if no corresponding s is found.
    }
}

然后我觉得在道德上有义务使工厂本身成为一次性的，因为它创建了小提琴并在它们的整个生命周期中保留对它们的引用。但这会给那些认为自己拥有小提琴并因此应该处置它们的客户带来问题。

问题实际上是我调用工厂 FiddleFactory 而不是 FiddlePool，以及“创建”方法 CreateFiddle 而不是 获取小提琴？像这样：

public class FiddlePool : IDisposable
{
    private Dictionary<SomethingThatDifferentiatesFiddles, DisposableFiddle> fiddles = new ...;        

    public DisposableFiddle GetFiddle(SomethingThatDifferentiatesFiddles s)
    {
        // returns an existing fiddle if a corresponding s is found,
        // or a newly created fiddle, after adding it to the dictionary,
        // if no corresponding s is found.
    }

    // Implements IDisposable
}

然后客户端会更清楚地知道它不会拥有返回的小提琴，并且池有责任处置这些小提琴。

或者这只能通过文档来轻松解决？

有没有办法摆脱困境呢？甚至还有困境吗？ :-)

Answer 1

我可以看到解决这个问题的两种方法：

• ThreadPool-style：重新设计类，以便FiddlePool提供一个接口来完成繁琐的事情。该池不会分发 Fiddle 实例，因为它有一个 FiddlePool.PlayFiddle 方法。由于池控制 fiddle 生命周期，因此它负责处理它们。

• SqlConnection-style：修改Fiddle的公共dispose方法，以便它实际上只是将fiddle返回到fiddle池（fiddle类封装的）。在内部，fiddle 池负责真正释放可处置资源。

Answer 2

我同意你的第二个意见。术语“Pool”和“Get”确实让消费者更清楚。然而，它仍然没有让事情变得足够清晰，并且应该始终添加文档以确保完整、有效的理解。

Answer 3

您应该做的不仅仅是文档和命名方法来告诉客户端不要调用 dispose。实际上，让客户端调用 dispose 会更好，这样就可以形成使用模式。从我们的数据库连接池的构建中得到一些指导。

数据库汇集了一堆连接，这些连接本身是池感知的。调用代码创建一个连接，打开它，然后调用关闭（处置）它。调用代码甚至不知道它是否被池化，这一切都由连接类在内部处理。对于池连接，如果连接已打开，则调用 Open() 将被忽略。 Close()/Dispose() 被调用，在池化连接的情况下，这实际上将连接返回到池中而不是关闭它。

您可以通过创建一个 PooledFiddle 类来执行相同的操作，该类重写 Dispose 并将对象返回到池中。理想情况下，客户甚至不必知道这是一个池化的 Fiddle。