Modèle de conception Java
table des matières
- Description du modèle de conception
- Modèle de façade
- Modèle de stratégie
- Résumé des modèles de conception
- 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
- Capacité d'extension améliorée: utilisation de l'orientation objet
- Réutilisation améliorée: utilisation de l'orientation objet
- Meilleure lisibilité: utilisation de l’orientation des objets et de la reconnaissance commune
- Vitesse de transmission améliorée Reconnaissance commune
Inconvénients (problèmes / risques)
- Écart par rapport à l'idée / mécanisme actuel (partie)
- Productivité réduite
- Respectez le modèle
- Complexité du code
- 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
- Modèle de façade
- 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
- Meilleure lisibilité en simplifiant le client
- Simplification de l'ajout / de la correction / de la suppression du traitement
- Simplification de l'ajout / suppression de clients
Démérite
- 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
- La plage d'influence lors de l'ajout d'une classe de traitement est claire
- Ne pas modifier le traitement existant
- Facile à comprendre le traitement de l'ensemble du programme
Inconvénients (risques)
- 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