Différence entre le singleton et le motif d’usine

Je suis nouveau à concevoir des modèles et je ne peux pas vraiment voir une différence entre ces deux modèles, les deux sont-ils des modèles créatifs? et quel est le but de chaque modèle? Merci.

Un modèle singleton garantit que vous récupérez toujours la même instance du type que vous récupérez, tandis que le modèle de fabrique vous donne généralement une instance différente de chaque type.

Le singleton a pour but de faire passer tous les appels par la même instance. Un exemple de ceci pourrait être une classe qui gère un cache de disque ou obtient des données d’un dictionnaire statique; partout où il est important, une seule instance connue interagit avec la ressource. Cela le rend moins évolutif.

Le but de l’usine est de créer et de renvoyer de nouvelles instances. Souvent, ce ne sont pas du tout le même type, mais ce seront des implémentations de la même classe de base. Cependant, il peut y avoir beaucoup d’instances de chaque type

Singleton

Le modèle unique est un modèle souvent utilisé dans de nombreuses applications lorsqu’une seule instance d’une ressource est requirejse. Le type de ressource le plus évident pour les pages Web PHP est une connexion à une firebase database, bien que d’autres types de ressources puissent être utilisés. Lors de l’extraction dynamic de la création d’une page Web, plusieurs appels de firebase database peuvent être nécessaires. Si une seule instance de la ressource pouvait être utilisée, plutôt que de créer plusieurs connexions, la surcharge est réduite. L’instance unique dans ce cas est créée par le modèle singleton.

setAtsortingbute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); } return self::$instance; } /** * Like the constructor, we make __clone private * so nobody can clone the instance */ private function __clone() { } } /*** end of class ***/ ?> 

Regardons ce qui s’est passé dans la classe singleton ci-dessus. Un nom de variable $instance est créé et rendu private , cela ne garantit personne et tente d’y accéder directement. De même, les méthodes constructor et __clone ont été rendues privées pour empêcher le clonage de la classe ou de quelqu’un qui en instancie une instance. La classe a une méthode unique pour fournir une ressource, la méthode getInstance() .

La méthode getInstance() vérifie qu’une instance n’existe pas déjà. Si aucune instance n’existe, une nouvelle instance de la classe PDO est créée et affectée à la variable d’ $instance . Si une instance existante est disponible, la méthode getInstance() renvoie ceci. Le résultat est que la valeur renvoyée est toujours la même instance et qu’aucune nouvelle ressource ou surcharge n’est requirejse.

Voici une petite démonstration de la façon dont cela pourrait être utilisé dans une application.

 query("SELECT animal_type, animal_name FROM animals");    /*** loop over the results ***/    foreach ($result as $row) {    print $row['animal_type'] .' - '. $row['animal_name'] . '
'; } } catch (PDOException $e) { echo $e->getMessage(); } ?>

Usine

Le modèle de fabrique est une classe qui crée des objects pour vous, plutôt que d’utiliser le nouveau mot-clé pour en créer un vous-même. L’usine est, comme son nom l’indique, une usine de création d’objects. Pourquoi avons nous besoin de ça? Considérons une application qui utilise un fichier ini pour l’option de configuration. Ensuite, l’application est modifiée pour obtenir les options de configuration à partir d’une firebase database. Le rest de l’application se désagrège comme un château de cartes à mesure que la base est retirée. Ce ” couplage serré ” d’objects, où chaque object s’appuie fortement sur un autre, crée des problèmes dans les applications plus grandes. Un système est nécessaire où les objects peuvent se référencer les uns aux autres, mais ne sont pas interdépendants.
Dans notre exemple du fichier de configuration devenant une firebase database, si d’autres classes étaient dépendantes de la classe lue dans le fichier ini , et que cela était soudainement atsortingbué à la classe de firebase database, des problèmes surviennent.
En utilisant le modèle de conception d’usine, si vous modifiez le type d’object de la classe ini reader à la classe de firebase database, vous devez uniquement modifier la fabrique. Tout autre code utilisant la fabrique sera mis à jour automatiquement.

 user_id = $id;  }  public static function Load($id) {     return new userConfig($id);  }  public function getName() {  try {      /*** query the database ***/         $sql = "SELECT username FROM user_table WHERE user_id=:user_id";         $db = db::getInstance();         $stmt = $db->prepare($sql)         $stmt->bindParam(':user_id', $this->user_id, PDO::PARAM_INT);         return $stmt->fetch(PDO::FETCH_COLUMN);        } catch (PDOException $e) {     /*** handle exception here ***/         return false;     } } } /*** end of class ***/ /*** returns instance of config ***/ $conf = userConfig::Load( 1 ); echo $conf->getName(); ?> 

Cela peut sembler un code un peu excessif pour récupérer simplement un nom d’utilisateur. Mais dans les applications à grande échelle où un changement de fichier basé sur la récupération de firebase database est effectué, les résultats peuvent être catastrophiques. Ici, il suffit simplement de changer la méthode getName() pour récupérer le nom, et l’object renvoyé est le même, permettant ainsi aux autres parties de l’application qui requièrent le nom d’utilisateur, par exemple: une connexion pour un panier, de continuer a fait précédemment.

Le modèle Singleton garantit qu’une seule instance de la classe existe et fournit généralement un point connu, c’est-à-dire global, pour y accéder.

Le modèle Factory définit une interface pour créer des objects (aucune limitation sur le nombre) et résume généralement le contrôle de la classe à instancier.

 +---------------------------+-------------------------------+ | Singleton | Factory | +---------------------------+-------------------------------+ | Returns Same instance | Returns various new instances | | Single Constructor hiding | Multiple Constructors expose | | No interface | Interface driven | | No Subclasses | Subclasses | +---------------------------+-------------------------------+ 

Singleton pattern est un modèle dont le but est de garantir que, quel que soit le nombre de fois qu’un client (ou plusieurs clients) demande qu’une instance de ce type spécifique soit créée (instanciée) pour eux, ils obtiendront toujours exactement le même et unique une instance du type. Il garantit qu’une seule instance du type peut être instanciée (comme par exemple si le Type gère une copie en mémoire cache de 200 Moctets en mémoire de certaines structures de données – vous voulez seulement qu’une copie existe) Un Type Singleton aura généralement une fabrique méthode, pour fournir aux clients demandeurs une seule et unique instance.

Une méthode Factory est une méthode qui encapsule la création ou l’instanciation d’un type afin que le type lui-même contrôle la manière dont il est instantiarté.

Singleton renvoie la même instance de classe tout le temps, la fabrique peut créer des objects en instanciant différentes classes ou en utilisant d’autres schémas d’allocation tels qu’un pool d’objects. Donc, singleton peut être utilisé en usine