9
votes

Le modèle de méthode d'usine violera-t-il le principe ouvert / fermé?

Est-ce que le Modèle de méthode d'usine (à ne pas être confondu avec les motifs d'usine ou d'usine abstraits) Violez le Principe ouvert / fermé ?

Mise à jour: Pour clarifier, je parle du scénario où une classe de béton contient des méthodes d'usine statiques. Par exemple (c'est à partir de la page Wikipedia sur FMP): P>

class Complex 
{
    public static Complex fromCartesian(double real, double imag) {
        return new Complex(real, imag);
    }

    public static Complex fromPolar(double modulus, double angle) {
        return new Complex(modulus * cos(angle), modulus * sin(angle));
    }

    private Complex(double a, double b) {
       //...
    }
}


8 commentaires

J'aimerais savoir ce que vous pensez de cela avant de répondre. Votre réponse me fera sentir que vous recherchez la réponse. Sinon, c'est comme si vous externalisez votre travail.


Désolé, prévoyait d'ajouter un commentaire, mais a été détourné par le travail. :) Je pense que cela le violera. Merci de me corriger si je me trompe, mais FMP dicte un constructeur privé et un constructeur privé interdit l'extension. De plus, la classe ne doit-elle pas être modifiée pour soutenir des implémentations alternatives? Je pense à la situation où une classe a des méthodes statiques de l'usine. Peut-être que ce n'est qu'une seule saveur de FMP?


Si c'est une classe enfant, vous pouvez surmonter la méthode ou utiliser Super () (supposant Java). Vous ferez mieux de ne pas avoir de méthodes statiques et que vous disposez d'une seule méthode qui prend des paramètres sur lequel choisir à l'aide d'une instruction de commutation ou en lisant dans un fichier de configuration fourni.


L'instruction de commutation ne nécessite-t-elle pas encore besoin de modifier la classe? Qu'en est-il de la question du constructeur privé empêchant l'extension?


Le code Wikipedia que vous citez n'est pas vraiment le modèle de méthode classique de l'usine. C'est semblable, mais à mon avis, ce n'est pas la même chose. Vous n'utiliseriez pas de code comme celui-ci dans une situation appelée à une méthode d'usine.


OK, le problème fondamental peut donc être que ce que je pensais être une saveur de la méthode d'usine n'est vraiment pas. Seriez-vous d'accord pour dire que ce qui est présenté ci-dessus enfreint le principe ouvert / fermé?


Ce code spécifique ne fait pas vraiment que des choses comme des chiffres sont généralement un cas particulier et les moyens de les créer ne sont pas quelque chose que vos exigences vont appeler à être configurables. Mais une autre classe (contenant la logique d'entreprise pouvant changer) qui avait un constructeur privé et des méthodes d'usine statiques? Oui.


Différences entre le modèle d'usine abstrait et la méthode d'usine L'exemple ici n'est ni.


3 Réponses :


2
votes

Nope. De votre lien Wikipedia:

Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes à l'extension, mais fermées pour la modification

Remplacer la méthode d'usine est une extension. Vous créez une nouvelle classe. Vous ne changez pas la classe existante. Vous devez remplacer (via la configuration de votre conteneur COI, espérons-le) la sous-classe pour l'original.


0 commentaires

6
votes

Non, cela ne violera pas du tout le principe ouvert / fermé.

Ouvrir / fermé signifie que vous pouvez modifier la manière dont un système fonctionne sans modifier le code déjà existant. Vous pouvez étendre le code et l'utiliser de différentes manières, mais l'ancien code est toujours en tact et n'a pas besoin d'être réutilisé.

Le modèle de méthode d'usine créera un type d'objet différent basé sur des paramètres spécifiés. La méthode d'usine fonctionne bien avec le principe ouvert / fermé s'il est fait correctement. Toutefois, si vous créez une nouvelle classe, puis souhaitez que la méthode d'usine crée un nouvel objet de ce type, vous devez modifier la méthode d'usine.

Bien que, si vous avez eu une sorte de fichier de configuration ou quelque chose de ce type qui est lu par la méthode d'usine, vous n'auriez pas à modifier la méthode d'usine ... Juste le fichier de configuration qui dicte ensuite quel objet va être créé par la méthode d'usine.


0 commentaires

4
votes

Le modèle d'usine est pas en soi un violateur de OCP .

Cela dépend comment strong> vous prenez le comportement de complexe code> plus. p>

Si complexe code> est nécessaire pour soutenir la production de nouveaux types de complexe code>, et que vous choisissez de modifier complexe code> en ajoutant de nouvelles fromX code> sont ajoutés pour les soutenir, cela signifie que complexe code> devient un violateur du OCP parce que complexe code> doit être re- ouvert pour la modification: p>

class Complex 
{
    public static Complex fromCartesian(double real, double imag) {
        return new Complex(real, imag);
    }

    public static Complex fromPolar(double modulus, double angle) {
        return new Complex(modulus * cos(angle), modulus * sin(angle));
    }

    //class opened for modification
    public static Complex fromOtherMeans(String x , String y) {
        return new Complex(x, y);
    }
}


0 commentaires