Nous ajouterons et organiserons au besoin.
Il y a des choses comme le concept lui-même et aucune explication claire.
** "Style de programmation qui extrait les pièces fréquemment modifiées en classes, en se concentrant sur les parties qui ne changent pas" **
Bref, je comprends que c'est une façon de penser à programmer pour qu'il soit facile de changer les spécifications et d'étendre les fonctions par la suite.
** L'essence de l'héritage est une interface qui rassemble des concepts abstraits **
** Programmation pour une interface (résumé) **
** Éliminez le gaspillage, affinez et faites quelque chose de facile à comprendre **
--La couche est différente de l'héritage et du polymorphisme
Pour le moment, je ne protégerai que les éléments suivants.
--Affaire de chameau -La classe est le nez ou la nomenclature
** Il ne doit pas y avoir plus d'une raison pour changer de classe (rôle = responsabilité = raison de changer) **
** ・ S'il y a un changement de spécification, vous pouvez gérer le changement en ajoutant un comportement. -Le comportement d'ajout n'affecte pas le code existant **
Ce que l'on souhaite, c'est la propriété de substitution suivante:
Il existe un objet de type T o2 pour chaque objet de type S o1 Il existe un programme p défini en utilisant o2 À ce stade, même si o1 est utilisé au lieu de ** o2, le comportement de p ne change pas **
** • Ne forcez pas le client à dépendre de méthodes que le client n'utilise pas **
-Si vous dépendez d'une méthode que vous n'utilisez pas, cela peut affecter les clients qui ne devraient pas être liés lorsque cette méthode est modifiée.
-Faire en sorte que chaque client s'appuie ** uniquement sur les méthodes qu'il utilise réellement **
** - Regrouper les interfaces liées et préparer une interface spécialisée pour chaque client ** Cela permet au client de rompre les dépendances sur les méthodes qu'il n'utilise pas.
-Les modules supérieurs ne doivent pas dépendre des modules inférieurs, ** Les deux modules doivent dépendre de "abstract" **
· "Abstract" ne doit pas dépendre des détails de l'implémentation, ** Les détails de l'implémentation doivent dépendre de "Abstract" **
-Si le module supérieur suit l'interface déclarée par le module inférieur, on peut dire que la propriété de l'interface appartient au module inférieur.
** • Faites en sorte que les relations au sein du programme se terminent par une classe ou une interface abstraite, indépendante de la classe spécifique ** Aucune classe dérivée d'une classe concrète N'écrasez pas les méthodes implémentées dans la classe de base
** ・ Il est tout aussi important de ne pas faire de "abstrait" prématuré et d'utiliser "abstrait" **
Il y avait une explication. Je voudrais identifier des abstractions significatives et efficaces.
Recommended Posts