Je lis je lis avec des constructeurs comme celui-ci, quel est l'avantage d'appeler programmation perl , et j'ai trouvé ce code Snippet: nouveau sur une instance d'objet? Je suppose que c'est ce que c'est pour, non? Je suppose que si quelqu'un voudrait écrire un tel constructeur, il devra ajouter un autre code qui copie les attributs du premier objet à celui de la création.
3 Réponses :
Vous pouvez donc construire un autre objet de la même classe sans savoir ce que l'objet de la classe d'origine est - cela peut créer un motif d'usine compact vraiment soigné.
À titre d'exemple, ceci est utile lorsque vous avez des objets de ressources dont vous avez besoin pour construire, selon les besoins et le coût de calcul quel type d'objet de ressources est élevé (par exemple, une requête de DB à long terme). Par conséquent, une usine verrait si elle a été adoptée si elle a été adoptée un ancien objet de ressource et, si oui, créez-en une comme ça simplement en appelant simplement Comme autre exemple, si vous avez la hiérarchie de classe désignant des animaux et une usine pour la construction de nouveaux animaux dans une simulation, vous pouvez appeler old_Object-> nouveau () - Éviter le coût des ressources de la ré-informatique type de ressource.
$ nouveau-né = $ usine-> make_new_animal ($ mère) avec le La mise en œuvre d'usine étant simplement $ objet-> nouveau ()
La fonction ne copie rien de l'instance d'origine. Il suffit de recevoir le nom de la classe avec ref ($ auto) , rien d'autre. Après cela, cela crée un objet complètement nouveau.
Lucas - Yep, n'a pas lu le code soigneusement assez ... des doigts de démangeaisons :) J'ai édité le "Copie Constructeur" de référence au moment où vous avez commenté :)
À titre d'exemple, si vous avez des objets de ressources, vous devez construire, comme besoin survient. Le coût de calcul quel type d'objet de ressources est élevé (par exemple, une requête de DB à long terme). Par conséquent, une usine verrait si elle a été adoptée un ancien objet de ressource et, si oui, en créer un comme ça simplement en appelant simplement old_Object-> nouveau ()
Comme un autre exemple, si vous avez une hiérarchie de classe désignant des animaux et une usine pour la construction d'animaux Enw dans une simulation, vous pouvez appeler $ nouveau-né = $ usine-> make_new_animal ($ mère) avec la mise en œuvre de l'usine simplement $ objet-> nouveau ()
Je ne vois pas de véritable avantage. Vous pouvez toujours simplement faire ref ($ obj) -> nouveau ou avoir une méthode pour faire $ obj-> clone ; De cette façon, vous n'êtes pas laissé de vous demander lequel de ces deux $ objet-> nouveau fait.
YSTH - Voir ma réponse. Il existe des choses vraiment soignées semblables à une usine qui peuvent être implémentées si votre classe de base a cette nouvelle méthode "en fais un comme moi".
Peut être fait -yes. "mieux" - discutable. Je trouve les deux ok, avec celui du livre plus évident et plus strayeur par une marge mince.
"évident" du côté de l'appelant> "évident" sur le côté de la callee
Comme d'autres l'ont dit, il faut permettre la création polymorphe d'une nouvelle instance d'objet sans avoir à être consciente du type de cette instance.
comme pour le clonage d'objet, j'écris normalement des méthodes clone explicites () ou copie () qui peuvent copier correctement des attributs et d'autres données, mais il n'y a aucune raison pour que la nouvelle () ne puisse pas prendre en charge ce rôle, aussi longtemps que Il est clairement documenté. Cependant, je vois deux avantages à les définir séparément:
Remarque: quelques très bonnes informations dans un Q: Stackoverflow.com/questions/1621373/...
Lol, je lis le même livre en ce moment