Modèle de conception Java

table des matières

1. Description du modèle de conception
2. Modèle de façade
3. Modèle de stratégie
4. Résumé des modèles de conception
5. Références

Modèle de conception (présentation)

• Les 23 modèles qu'une personne intelligente nommée GoF a pensé --Target est un langage orienté objet --Il existe plusieurs autres types
• Tirer parti des fonctionnalités Java pour améliorer (principalement) l'extensibilité --Héritage --Polymorphisme --Encapsulation, etc.
• L'excellent vétéran pense comme ça! Une collection d'idées --Pas une méthode de mise en œuvre concrète
• Comprenez l'idée et appliquez-la à votre propre programme

Modèle de conception (utilisation efficace)

• Appliquer l'idée et la refléter dans votre propre source
• ≠ Mettre en œuvre selon le modèle -Utiliser uniquement lorsque l'effet est prévisible
• ≠ Appliquer autant que possible
• ≠ Illusion de l'efficacité du modèle de conception
• Si vous l'utilisez de force, cela aura l'effet inverse. ―― Décidez de manière flexible de l'application en fonction de la situation
• ≠ Étant donné que la décision relative à la demande a été prise au moment de la conception, elle sera certainement reflétée dans le programme

Modèle de conception (avantages et inconvénients)

mérite

1. Capacité d'extension améliorée: utilisation de l'orientation objet
2. Réutilisation améliorée: utilisation de l'orientation objet
3. Meilleure lisibilité: utilisation de l’orientation des objets et de la reconnaissance commune
4. Vitesse de transmission améliorée Reconnaissance commune

Inconvénients (problèmes / risques)

1. Écart par rapport à l'idée / mécanisme actuel (partie)
2. Productivité réduite
3. Respectez le modèle
4. Complexité du code
5. Malentendus et discussions inutiles en raison de différences d'interprétation (car il est abstrait)

Modèle de conception (calendrier d'utilisation)

--Au moment de la conception de la classe --Au moment du refactoring

• Au moment de l'examen
• Temps d'explication réduit aux examinateurs --Seulement si les deux côtés connaissent le motif --Au moment de l'enquête de programmation
• Temps de lecture réduit
• Précision de prédiction améliorée --Seulement si vous connaissez le modèle --Lors de la modification de la programmation

Deux modèles à couvrir cette fois

• Ramassez les points de vue suivants --Facile à comprendre --Facile à utiliser --Un certain effet peut être attendu --Il y a un exemple autour de vous

1. Modèle de façade
2. Modèle de stratégie

Motif de façade (aperçu)

--Créez une classe qui gère le flux de traitement compliqué au nom du client

• Le côté client peut effectuer un traitement compliqué simplement en appelant la classe Facade.
• Traitement simplifié côté client
• Le modèle le plus couramment utilisé, sans le savoir dans une certaine mesure --Très utile pour la refactorisation

Motif de façade (conditions d'utilisation)

--Il est nécessaire d'appeler différentes classes dans une série de processus

• C'est un processus général appelé par de nombreux clients.

Motif de façade (personnages)

• Client --Classes qui souhaitent effectuer un traitement compliqué --Appeler la classe Façade
• Facade --Classe qui accepte les appels de traitement complexes --Appeler les vraies classes
• Groupe de classe réel
• Un groupe de cours qui assument une partie d'un traitement compliqué
• Appelé au moment requis pour la classe Façade

Motif de façade (image)

Motif de façade (avantages et inconvénients)

mérite

1. Meilleure lisibilité en simplifiant le client
2. Simplification de l'ajout / de la correction / de la suppression du traitement
3. Simplification de l'ajout / suppression de clients

Démérite

1. Production de masse de classe de façade inutile

Motif de façade (résumé)

• Le traitement compliqué est effectué dans une classe --Facile à ajouter un traitement côté client ――Il est relativement facile à appliquer ――Si vous ne restreignez pas l'utilisation, les classes inutiles augmenteront et cela aura l'effet inverse

Modèle de stratégie (aperçu)

• Sous-classez la partie où le traitement est commuté par branchement conditionnel --Ajout minimum aux sources existantes lorsque les conditions augmentent --Très similaire au modèle State

Modèle de stratégie (caractères)

• Strategy --Interface d'utilisation de la stratégie --Responsable du traitement de la définition du type et de la réutilisation du type
• ConcreteStrategy --Mise en œuvre de la stratégie ――Responsable du traitement proprement dit
• Context --Classes qui utilisent la stratégie --Dispose d'une variable de type Stratégie
• Traitement de type Stratégie d'appel, mais ne comprends pas la situation réelle
• Client
• Passer le type de stratégie au contexte
• Traitement du contexte d'appel

Schéma de stratégie (conditions d'utilisation)

• Un traitement similaire est appelé par branchement conditionnel
• Les conditions devraient augmenter ou diminuer à l'avenir

Modèle de stratégie (image / non utilisé)

Modèle de stratégie (lors de l'utilisation de l'image)

Modèle de stratégie (avantages et inconvénients)

mérite

1. La plage d'influence lors de l'ajout d'une classe de traitement est claire
2. Ne pas modifier le traitement existant
3. Facile à comprendre le traitement de l'ensemble du programme

Inconvénients (risques)

1. Complexité du code due à une application déraisonnable

Modèle de stratégie (résumé)

• Utilisé lorsqu'un traitement similaire est exécuté dans le branchement conditionnel
• La gamme d'influence des sources existantes peut être réduite
• Légèrement plus encombrant et compliqué que la façade --Si aucun traitement supplémentaire n'est prévu, l'effort est plus important

Modèle de conception (résumé)

• Tirez parti de l'orientation des objets pour l'évolutivité et la réutilisation
• Améliore la lisibilité (parfois) ――Appliquez l'idée au lieu de l'utiliser telle quelle
• La combinaison est également possible --Avec motif 〇〇! La communication est rapide et facile si vous pouvez communiquer avec ―― Puisque l'original est approximatif, il y a une différence d'interprétation
• Certains des livres que j'ai lus cette fois avaient des interprétations différentes «Si vous en faites trop, ce sera un gaspillage de travail et de travail.

Références (titres omis)

• Modèles de conception appris en langage Java
• Auteur: Hiroshi Yuki
• Capture complète des modèles de conception Java --Auteur: Japan Software Engineering Co., Ltd. --Refactoring: améliorer en toute sécurité le code existant
• Auteur: Martin Fowler
• Traduction: Kiminobu Kodama, Masao Tomono, Akira Hirasawa, Takashi Umezawa
• Modèles de conception tirés des études de cas
• Auteur: Naoki Fukuda
  • URL：https://www.ogis-ri.co.jp/otc/hiroba/technical/DesignPatternsWithExample/ ――Dramatique avant ◯ Modèle de conception appris par le service après-vente --Auteur: karoten512
  • URL：http://karoten512.hatenablog.com/entry/2017/10/21/134048