Cette série d'articles est écrite par l'auteur (expérience d'apprentissage Java: environ 2 ans, expérience de travail Java: un peu) Créé pour comprendre "GoF Design Pattern 23". J'ai l'intention de me concentrer sur l'image plutôt que sur la précision, et je pense que le contenu sera destiné à ** moins que la programmation Java intermédiaire **.
Si vous ne pouvez pas y accéder, veuillez commenter <(_ _)>
** Principales sources d'apprentissage: ** ・ "Introduction aux modèles de conception appris dans le langage Java amélioré et révisé (par Hiroshi Yuki)" ・ Modèle de conception | TECHSCORE
Concevoir des modèles pour améliorer la qualité du programme. Dans une telle situation, c'est un recueil de la sagesse de nos prédécesseurs, comme concevoir comme ça et aider plus tard.
Cet article traite de 23 modèles appelés ** «GoF Design Patterns» **.
"[GoF](https://ja.wikipedia.org/wiki/%E3%82%AE%E3%83%A3%E3%83%B3%E3%82%B0%E3%83%BB%E3%" 82% AA% E3% 83% 96% E3% 83% BB% E3% 83% 95% E3% 82% A9% E3% 83% BC_ (% E6% 83% 85% E5% A0% B1% E5% B7 Il a été préconisé par un groupe important d'ingénieurs en logiciel appelé "% A5% E5% AD% A6))" et est l'un des modèles de conception les plus connus.
Version japonaise du livre: ** "Modèle de conception pour réutilisation en orientation objet" **
(Je suis désolé de ne pas avoir lu!)
Il y a plusieurs buts. .. En apprenant les modèles de conception du GoF, vous pouvez vous attendre aux avantages suivants.
-Les modèles de conception sont utiles pour regrouper les composants du programme par fonction ou séparer les rôles pour créer des parties générales.
-Java Collection (ArrayList, etc.) utilise le modèle Iterator. De plus, beaucoup utilisent le modèle Factory pour l'instanciation. -Certains modèles utilisant des modèles de conception sont difficiles à comprendre à première vue. Si vous ne connaissez pas le modèle, vous ne pouvez pas le comprendre en regardant le programme, et vous pouvez le mal interpréter comme un design compliqué et médiocre.
-Il existe de nombreux langages de programmation orientés objet, non limités à Java. Cependant, il est assez difficile de savoir comment bien utiliser «orienté objet». .. (Je ne pense pas que ce soit un concept très intuitif) Je pense que l'apprentissage de divers modèles vous aidera à apprendre l'orientation des objets.
・ GoF est un modèle de conception célèbre, et de nombreux ingénieurs le savent. Par conséquent, si vous dites "cette conception est un" motif XXX "", cela peut suffire à expliquer.
Pour ceux qui apprennent les modèles de conception à partir de maintenant, au lieu d'utiliser simplement les modèles Il y a un «but» pour chaque modèle, et «le GoF le conçoit dans ce but». Je pense que si vous êtes conscient de ce point, vous pourrez l'appliquer.
C'est un bonus. Vous pouvez l'ignorer.
Facilité de faire des ajouts et des modifications au programme. Il comprend également la lisibilité du code et une journalisation appropriée pour l'analyse en cas de problème. En termes de conception de programme, il montre une «flexibilité» qui peut répondre à des situations telles que les ajouts de fonctions et les changements de spécifications.
-Si des parties sont organisées pour chaque fonction / rôle dans le programme, la visibilité du programme sera améliorée et la maintenabilité sera améliorée. ・ Même si chaque pièce est modifiée, la maintenabilité s'améliorera si elle est faite de manière à ne pas affecter l'environnement.
Facilité de réutilisation des programmes et de leurs composants. Vous pouvez utiliser une partie à plusieurs endroits dans le programme, ou vous pouvez l'utiliser dans un autre programme avec quelques modifications. En plus de réduire le problème d'écrire deux fois le même code Les pièces qui ont réussi la phase de test rigoureux doivent être garanties en qualité. Si les pièces de qualité garantie peuvent être réutilisées telles quelles, l'effort de test peut être réduit.
-Les pièces de "conception générale" qui ne dépendent pas de conditions spéciales sont hautement réutilisables. -On peut dire que les API de langue officielle sont hautement réutilisables.
Un "bon" programme hautement maintenable et réutilisable -Il est "organisé" pour chaque fonction / rôle, ce qui facilite la modification et l'ajout de fonctions. -Il existe de nombreuses parties "générales" qui sont séparées autant que possible des circonstances spéciales du programme.
Cependant, parce que le programme est destiné à résoudre un vrai problème concret, Vous devez écrire un traitement et des valeurs "concrets" quelque part.
** Compte tenu des circonstances qui l'entourent, le modèle de conception du GoF est souvent conçu comme suit. ** **
・ En subdivisant, le travail en charge de chaque partie devient clair. ・ La plage d'influence lors du remplacement ou de la modification de pièces est réduite.
-Utiliser des interfaces et des classes abstraites pour déterminer les relations entre les parties. ・ Laissez le traitement spécifique à une classe ordinaire (classe concrète). Cela facilite le remplacement de la classe concrète.
・ N'écrivez pas de descriptions spécifiques telles que la classe concrète à new () ici et là. Laissez un expert le gérer, par exemple, la fonction principale. Ensuite, vous pouvez basculer entre différentes classes concrètes en modifiant uniquement main ().
-En réduisant la dépendance entre les pièces ou en les collectant dans un endroit précis La plage d'influence lors de la modification des pièces peut être réduite.
・ Préservez l'indépendance des pièces en ne montrant que les pièces nécessaires côté utilisateur -Il est également possible de combiner plusieurs pièces en une seule grande pièce. Dans ce cas, masquez tout sauf les parties de la fenêtre.
Les parties du programme sont étroitement liées aux autres parties.
Un problème courant lorsque vous souhaitez modifier un programme La modification d'une partie "A" peut nécessiter (éventuellement) de modifier également l'autre partie "B". A ce moment, "B" est dit ** "dépendant" ** de "A".
En Java, lorsque le nom de la classe "A" apparaît dans la description de la classe "B", "B" dépend de "A". Par exemple, si vous renommez «A» en «Nouveau A», vous devrez changer tous les «A» qui apparaissent dans «B» en «Nouveau A». Sinon, le compilateur se mettra en colère.
Il est peu probable que vous changiez uniquement le nom, mais tant que vous avez volontairement décrit la classe «A» dans la classe «B», "B" signifie que "A" est utilisé d'une certaine manière. (Il peut y avoir différentes situations telles que l'utilisation d'une instance ou son héritage) Si vous réécrivez la description dans "A" dans cet état, il est possible que la fonction de "B" en utilisant "A" soit affectée d'une manière ou d'une autre.
Au contraire, quelle que soit la modification apportée à la classe "B", cela n'affecte pas le côté classe "A". (Lorsque "A" n'utilise pas "B") A partir du code de la classe "A", vous ne pourriez même pas voir si "B" existe en premier lieu. Par conséquent, on peut dire que la classe "A" ne dépend pas de la classe "B".
Lorsque la dépendance entre les pièces se complique, l'indépendance des pièces est perdue et le temps et l'effort requis pour la correction augmentent. Par conséquent, les dépendances doivent être conçues pour être aussi petites que possible et faciles à contrôler.
Empêcher qu'une partie spécifique d'un composant du programme ne soit vue ou touchée de l'extérieur s'appelle ** "dissimulation" **. "Cacher" la bonne partie s'appelle ** "encapsulation" **.
Par exemple, disons que vous avez un poêle ici. Il y a un bouton marche / arrêt sur le dessus du poêle, et lorsque vous appuyez dessus, une brise chaude sort. L'intérieur de la machine est recouvert d'un couvercle et les pièces telles que les radiateurs et les ventilateurs qui se déplacent à l'intérieur ne peuvent pas être vues ou touchées. Il s'agit de l'état «encapsulé», et les parties inutiles pour l'utilisateur sont «masquées».
Que faire si le couvercle du poêle est retiré et que les pièces mécaniques sont complètement visibles? Vous ne pouvez pas trouver le bouton d'alimentation en un coup d'œil, mais vous pouvez voir le radiateur, le ventilateur, les vis et d'autres pièces internes. Il est très difficile de comprendre où opérer. Il est possible que vous touchiez par inadvertance une partie importante et que vous cassiez le poêle. C'est l'état où il n'est pas "caché".
De cette manière, une dissimulation appropriée présente deux avantages. -Il sera plus facile à manipuler car l'utilisateur n'a qu'à vérifier la fenêtre (bouton d'alimentation, etc.) pour utiliser les pièces. ・ Protège les éléments internes des pièces contre les changements inattendus de l'extérieur
En Java, le masquage est principalement réalisé en utilisant un ** contrôle d'accès ** tel que privé et public.