Fliegengewicht und Fabrik Problem mit IDisposable

Question

Ich scheine in einem Flyweight Muster Dilemma geistig stecken.

Lassen Sie uns zuerst sagen, ich habe eine Einweg-Typ DisposableFiddle und eine Fabrik FiddleFactory:

public interface DisposableFiddle : IDisposable
{
    // Implements IDisposable
}

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

Dann, meiner Meinung nach, es ist ganz klar an den Client von FiddleFactory, dass die Fabrik kein Eigentum der erzeugten Geige behauptet, und dass es in der Verantwortung des Kunden, die Geige zu entsorgen, wenn sie mit ihm getan.

Lassen Sie sich jedoch stattdessen sagen, dass ich unter Verwendung des Flyweight Musters zwischen Kunden zu teilen Geigen will:

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

Dann fühle ich mich moralisch verpflichtet, das Werk selbst Wegwerf zu machen, da sie die Geigen schafft und hält Verweise auf sie während all ihrer Lebenszeit. Aber das würde Probleme für die Kunden führen, die davon ausgegangen, sie die Geigen im Besitz und sollten sie daher entsorgt werden.

Ist das Problem eigentlich, dass ich die Fabrik FiddleFactory nennen statt, sagen wir, FiddlePool, und die „Schöpfung“ Methode CreateFiddle statt GetFiddle? Wie folgt aus:

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
}

Dann ist es klarer an den Client, dass es nicht die zurück Geige besitzen würde, und es ist die Verantwortung des Pools die Geigen zu entsorgen.

Oder kann dies nur leicht Dokumentation weise gelöst werden?

Gibt es einen Ausweg aus dem Dilemma? Gibt es auch ein Dilemma? : -)

Answer 1

kann ich zwei Möglichkeiten sieht aus diesem Problem:

• Threadpool-Stil : die Klassen neu zu gestalten, so dass der FiddlePool eine Schnittstelle bietet knifflig Dinge zu tun. Der Pool ist auszuteilen nicht Fiddle Instanzen, weil es eine FiddlePool.PlayFiddle Methode stattdessen hat. Da die Pool Kontrollen Geige Leben, es ist verantwortlich für die von ihnen zu entsorgen.

• SqlConnection-style : modify Fiddle öffentliche dispose-Methode, so dass es wirklich nur wieder Geigen auf die Geige Pool (der die Geige Klasse kapselt). Intern wird die Geige Pool kümmert wirklich Einweg-Ressourcen zu.

Answer 2

Ich stimme mit Ihrer zweiten Meinung. Die Terminologie ‚Pool‘ und ‚Get‘ tut die Dinge klarer für die Verbraucher. Es ist jedoch immer noch nicht die Dinge klar genug machen, und Dokumentation sollte immer hinzugefügt werden, um ein vollständiges, gültiges Verständnis zu gewährleisten.

Answer 3

Sie sollten etwas mehr als nur Dokumentation tun und Benennungsmethoden Kunden zu sagen, nicht dispose zu nennen. Wirklich wäre es besser, die Kunden, dass die Nutzungsmuster dispose so machen rufen zu haben. Nehmen Sie sich etwas Richtung unserer Datenbankverbindungspools aufgebaut sind.

Die Datenbank-Pools eine Reihe von Verbindungen, die sich am Pool bewusst sind. Telefonvorwahl schafft eine Verbindung, öffnet es und ruft schließen (dispose) auf sich. Der anrufende Code noch nicht einmal weiß wirklich, wenn es gepoolt ist oder nicht, es ist alles intern von der Verbindungsklasse behandelt. Mit einer zusammengefassten Verbindung, ruft Open () werden ignoriert, wenn die Verbindung bereits geöffnet ist. (Close) / Dispose () aufgerufen wird und im Fall einer zusammengefassten Verbindung dieser gibt tatsächlich die Verbindung zurück an den Pool, anstatt sie zu schließen.

Sie können das gleiche tun, indem Sie eine PooledFiddle Klasse zu schaffen, die Entsorgung überschreibt und gibt das Objekt an den Pool. Im Idealfall würde der Kunde nicht einmal wissen müssen, es ist eine gepoolte Fiddle.