9
votes

Quel modèle de conception est le contraire du modèle d'usine?

Je me demandais s'il y a un modèle opposé du modèle d'usine. Par exemple, lorsqu'un certain objet doit être supprimé, un travail supplémentaire doit être effectué, pour annuler la configuration effectuée dans l'objet d'usine.

Extension de l'objet d'usine avec une méthode de suppression par exemple semble tromper, car le motif d'usine est un motif créateur strict.

MISE À JOUR: La raison pour laquelle j'utilise une usine est parce que la configuration à effectuer pourrait introduire certaines dépendances à l'objet qui ne correspondrait pas. Mettre cette dés-configuration dans le constructeur poserait le même problème.


4 commentaires

Qu'est-ce que tu veux dire exactement avec "Supprimer"? Libérer de la mémoire, ou enlever d'un magasin de données?


Avec la suppression, je voulais le supprime d'un magasin de données, cela serait fait par le référentiel.


et quelle sorte de "configuration a été effectuée dans l'objet usine"? Un objet doit être capable de nettoyer après elle-même, la tâche des destructeurs et / ou de disposer. Je dirais qu'une usine ne devrait pas savoir quoi que ce soit des objets qu'il a créés.


Le fonctionnement de la configuration que l'objet d'usine effectue relie les racines d'agrégats et initialise le contexte de sécurité. Faire cela dans le constructeur introduirait certaines dépendances, qui ne seraient utilisées que là-bas. Le motif d'usine semblait approprié pour la création.


3 Réponses :


4
votes

Un référentiel peut être utilisé pour supprimer un objet persisté ou utiliser la méthode d'élimination pour effectuer un nettoyage sur un objet en mémoire uniquement.


2 commentaires

Je vais mettre cette "désenfiguration" dans le référentiel pour l'instant.


Avez-vous besoin de détruire des informations persistantes (base de données / fichier)?



3
votes

C'est bon moyen d'utiliser l'usine. L'usine est non seulement un moyen de créer des objets, mais aussi la façon de dire: j'ai besoin d'une initialisation spéciale pour ce type d'objets. Avec votre problème, je pense que la meilleure solution serait de notifier l'usine avec un événement, comme disposé. Donc, votre création d'objet se fera de telle manière: créer, souscrire une usine à un événement nouvellement créé. Chaque objet est supprimé, vous remarquez l'usine et effectuez une action dont vous avez besoin.

Si vous n'aimez pas mettre cela dans l'usine, vous pouvez le déléguer à une sorte d'autre objet, comme le chef de guerre ;-). Votre code ressemblera donc à ce que ceci: xxx

Maintenant, chaque fois que vous devrez supprimer un objet, votre objet informera le détenteur du détenteur de la mort et il ferait tous le disposer de la logique. À propos, je ne sais pas comment tout fonctionne, mais vous pouvez utiliser une interface iDisposable pour effectuer la logique personnalisée pour éliminer les ressources détenues par objet. La décision dépend de ce que là-bas dans votre projet et qui est à vous.


0 commentaires

2
votes

J'utilise un modèle de "installation de recyclage" travaillant en tandem avec l'usine:

  • avoir une méthode "propre" pour chaque classe pouvant être recyclée
  • avoir une "pièce d'identité unique" pour chaque instance d'objet

    Chaque fois qu'un objet atteint sa fin de vie, envoyez-le à la "installation de recyclage" (RF):

    • Le RF stocke l'objet en fonction de certaines stratégies (par exemple, ne conserve que des instances x de la classe Y)
    • Lorsqu'une instance de classe Y est requise, l'usine "demande" le RF si son a obtenu un
      • Si le RF a une pratique, le RF appelle la méthode "propre ()" sur l'instance et le renvoie à l'usine

        ... et ainsi de suite.

        J'espère que cela aide.


0 commentaires