dimanche 8 mars 2020

Are there any disatvantages in this Factory design-pattern

In know that the general design-pattern for Factory class is something like this:

class Element {
    constructor();
    destructor();
}

class Factory {
    static function createElement() {return new Element();}
}

And that a typical use-case of it looks something like this:

Element x = Factory.createElement();
...
x.destructor();

And I'm aware of the fact that x.destructor() is generally invoked implicitly at the end of the scope where x is declared (or in virtual languages which implement a garbage collector, whenever that GC determines that x is no longer used).

But suppose that we don't have a destructor function at all - as is the case in Javascript.

Then I've been thinking of using the following design-pattern instead:

class Element {
    constructor();
    function destructor();
}

class Factory {
    static function createElement() {return new Element();}
    static function destroyElement(Element x) {x.destructor();}
}

And then a typical use-case of it would look something like this:

Element x = Factory.createElement();
...
Factory.destroyElement(x);

Is there any disadvantage in this design-pattern comparing to the "traditional" one?

Thank you!

Aucun commentaire:

Enregistrer un commentaire