Je travaille récemment sur une arborescence, plusieurs nœuds, des niveaux multiples et augmentés, et une méthode d'impression (). Au début, je pensais que cela devrait être un composite, j'ai ensuite écrit une conception et des codes possibles:
est bon, je pense et commencer la codage, la méthode d'impression () peut suivre le motif itérateur plus tard.
Mais pendant le codage, je me sens trop complexe pour ces nœuds simples? Et je dois instancier beaucoup de classes concrètes (plus de 50 ans et plus et en augmentation). J'ai ensuite arrêté et pensé une manière simple simple en utilisant le tableau: Les deux dessins ont l'air très similaire, maintenant je suis un peu confus, quelle est la valeur du modèle composite, Ai-je manqué quelque chose d'important de ce modèle? 
3 Réponses :
La valeur du composite est que vous négociez une certaine complexité Dans votre version de tableau, vous enfreignez l'encapsulation depuis que vous êtes
Tester si le nœud n'est pas une feuille: avec composite, vous pouvez dire: puis polymorphisme d'exécution appellera la bonne méthode. Dans ce cas (je ne suis pas un programmeur PHP, permettez-moi d'utiliser une syntaxe de type Java): Un autre avantage sur une matrice uni est que vous êtes
J'ai essayé de comprendre, mais je ne peux toujours pas attraper l'esprit. Ci-dessous mes pensées, n'hésitez pas à pointer mes erreurs, j'ai également corrigé des erreurs dans mes codes. 1. "Casser l'encapsulation", ce que je suis confus, c'est si je ne traite pas le nœud comme une entité, est-ce toujours une casse d'encapsulation? et quel problème cela causera-t-il enfin? 2. Je pense que les détails de la mise en œuvre sont cachés en structure de classe, n'est-ce pas le cas? 3. Je ne trouve toujours pas l'avantage du composite, quelle que soit la modification de cet arbre, les prix des changements de code ont pris de deux manières semblent les mêmes.
Maintenant, le code a l'air meilleur: 1. Avec le composite, vous ne distinguez pas les opérations sur des nœuds des opérations sur les feuilles 2. Il est maintenant clair que votre tableau est encapsulé dans une classe; dans votre question originale, ce n'est pas
Le point de la modèle composite est de pouvoir traiter une collection d'objets comme si C'était un seul objet (par exemple, pour l'afficher ou l'écrire à un fichier). Lorsque vous vous écrivez, la méthode d'impression () peut suivre le motif d'itérateur plus tard »- Eh bien, le point du motif composite serait que vous pouvez appeler Imprimer () sans avoir à vous soucier de savoir si vous imprimez un composant unique ou que vous devez itérrer à travers un arbre entier.
Mais il semble que vous ne soyez pas clair sur la programmation orientée objet en général, car vous envisagez d'utiliser des tableaux imbriqués à la place. La valeur de l'utilisation d'objets au lieu de hachages (que les tableaux PHP sont) pour tout est Sécurité de type , qui rend beaucoup plus facile de déboguer et de maintenir des programmes.
Vous avez raison, j'étais une longue période C programmeur, quand dans la programmation OO, je suis de nombreux principes et modèles que je sais qu'ils sont importants, mais je ne sais pas vraiment pourquoi ils sont importants. À ma compréhension, OO est surtout le moyen de rendre le programme facile à maintenir pour changer, mais je ne peux généralement pas voir, même ne sais pas si cela est efficace. Dans cet exemple, par exemple, je ne peux toujours pas voir à quel point le prix que composite est censé fournir, ajouter / supprimer des nœuds, changement de commande, ne sont pas les deux changements de codes qui semblent les mêmes?
Pensez-y comme ceci: l'utilisation de tableaux au lieu d'objets est similaire à un programme C utilisant Void * pour tous les paramètres de la méthode.
Je sens de votre part différente de penser, pensez à la matrice, je pense que c'est une mise en œuvre OO, tout simplement pas composite, n'est-ce pas? Je peux comprendre l'exemple que vous avez dit, mais cela ne vous aide pas à comprendre en utilisant des objets au lieu d'un tableau, dans cet exemple, les avantages?
Comme je l'ai dit: le bénéfice de l'utilisation d'objets est la sécurité de type. La mise en œuvre à base de tableau a la même structure, mais elle perd complètement la sécurité de type et ainsi la plupart des avantages de OO ainsi que du motif composite. Cela n'a probablement pas beaucoup d'importance dans un cas aussi simple, mais lorsque les structures deviennent plus complexes, l'utilisation de tableaux pour tout signifie que vous êtes plus susceptible de faire des erreurs (puisque une matrice ressemble à tout autre pour vous, le compilateur et le Runtime) et ils sont beaucoup plus difficiles à déboguer.
Wow, bon point, en le recherchant sur Google, je trouve des discussions intéressantes sur les matrices Java, PHP Type-Safety. et ceci, "PHP est une langue typée de manière lâche. Cela signifie que toute variable (par exemple x) peut être de n'importe quel type. Sur une ligne, il pourrait s'agir d'un entier, mais sur la ligne suivante, vous pouvez le traiter comme chaîne (i Le font souvent dans mon programme). Taper en vrac, tout en restant moins "sûr" du point de vue de l'intégrité d'exécution, permet à PHP de faire beaucoup de trucs soignés avec des tableaux qui les rendent très efficaces - dans certaines situations ". Merci d'avoir mis l'accent sur un point précieux, j'apprends maintenant plus d'informations et PHP
La mise en œuvre de la matrice ne vous semble-t-elle pas beaucoup plus complexe? Si je le regarde, je dois l'étudier plus près de comprendre ce que vous faites. Vous traitez avec des index, attribuant des entrées à des index spécifiques, etc. ... il a l'air vraiment complexe.
Votre implémentation du motif composite sur l'autre site semble simple et naturelle lorsque vous regardez le code où vous l'utilisez. Vous avez un nœud et vous attachez d'autres nœuds ou feuilles. Rien de complexe, étrange, je n'ai pas à m'en soucier / se souvenir d'index, etc ... c'est pourquoi le motif composite est utile dans votre cas. Bien entendu, sa mise en œuvre peut vous avoir un peu complexe, si vous n'êtes pas habitué à cela, mais le point important (aussi d'autre indiqué) est que vous cachez des détails. C'est
J'ai corrigé des erreurs dans d'anciens codes, il devrait maintenant être plus proche de mon esprit.
Ma conclusion: le modèle de conception est génial, mais ne signifie pas qu'ils sont toujours préférés. Dans cet exemple, étant donné que l'arborescence a plus de 1000 nœuds, un outil composite nécessite donc un client pour instancier 1000 objets, puis quoi? Vous devez résoudre un autre poids volé pour améliorer les performances et économiser des ressources. Le programme devient de plus en plus complexe, enfin, un composite + Itérateur + Flyweight (+ Vistor parfois) implémente. Sur un problème simple qui peut être résolu par une classe avec une matrice et une méthode. Enfin, sur cette question, ma réponse est, la matrice met en œuvre la mise en œuvre du modèle de défaite.