[JAVA] [Critique de livre] Structure et conception du logiciel d'architecture propre appris des maîtres

Le livre que j'ai lu

Structure et conception du logiciel d'architecture propre appris des maîtres Robert C. Martin Auteur Je lis. C'est une critique de livre (impression de lecture).

Objectifs de conception et d'architecture

L'auteur plaide d'abord à des fins de design et d'architecture (l'auteur dit design = architecture). Dit "" Le but de l'architecture logicielle est de réduire au minimum les ressources humaines nécessaires pour construire et maintenir le système requis " Pendant un instant, c'est devenu "Hmm?" Et j'ai pensé que ça pourrait être le cas après un moment. Il ne s'agit pas de passe-temps, il s'agit de développer des logiciels en tant qu'entreprise. Cela ne vient peut-être pas à l'esprit des ingénieurs qui pensent que c'est un travail, mais des gens qui en font un passe-temps et ne connaissent pas la maintenance, mais c'est certainement correct d'un point de vue commercial. Au fait, je suis un ingénieur qui a grandi en créant des logiciels tout en m'amusant tout le temps, donc je ne pense pas que ce soit mauvais pour un ingénieur qui aime être libéré des affaires. (Le simple fait d'avoir un subordonné serait une douleur ...)

En d'autres termes ** "Les logiciels qui ne sont pas productifs en développement et en maintenance sont mal conçus" ** C'est pourquoi c'est tout à fait raisonnable. C'est un ** qui ** qui nécessite un énorme mois-homme chaque fois que quelque chose est modifié. De plus, cela devient de pire en pire au fil des jours.

Alors, comment obtenir le bon design?

Comment concevoir?

Jusqu'à la deuxième partie, on a l'impression de revenir sur l'histoire, alors sautez-la pour le moment, et la troisième partie

SRP: principe de responsabilité unique
OCP: principe ouvert / fermé
LSP: le principe de remplacement de Liskov
ISP: Principe de séparation des interfaces
DIP: Principe de l'inversion de dépendance

Est-ce par ici? Ce sont des acronymes ** Principes SOLID **. Ce sont des idées valables pour la ** «conception détaillée» ** plutôt que la ** «conception de base» ** du système. L'auteur dit également qu'il "s'applique au-dessus du niveau du code", et que ** la conception des composants ** attend plus loin. Si vous passez à la ** conception des composants **, elle tombera dans la catégorie ** «conception de base» **.

Mais d'abord, "SRP: Principe of Single Responsibility"

SRP: principe de responsabilité unique

C'est une explication assez déroutante dans ce livre, mais selon ma propre compréhension, c'est comme ça.

** La responsabilité doit être MECE **

Qu'est-ce que MECE? Pour ceux qui disent Apprenez les bases de 5 frameworks, qu'est-ce que "MECE" S'il vous plaît voir autour. Pour le dire simplement, MECE est un acronyme pour «mutuellement exclusif et collectivement exhaustif», ce qui signifie «sans omission et sans duplication». À l'origine terme interne de McKinsey, je pense que vous le verrez souvent dans le sujet de la pensée logique ces jours-ci. Je ne pense pas que MECE soit correct, mais c'est un très bon concept pour expliquer le "principe de la responsabilité unique". Je pense que cette idée est efficace pour l'analyse de tous les événements et est précieuse lorsqu'elle est appliquée à n'importe quel niveau de conception de base et d'exigences plutôt qu'au niveau de conception détaillée.

OCP: principe ouvert / fermé

En considérant le sens de l'encapsulation et de la dépendance, dit-il, «il devrait être possible d'étendre les artefacts existants sans modification». Le problème est de savoir quels sont les ** livrables existants **, mais fondamentalement Partie centrale telle que la logique métier Ou «Le côté situé dans la couche inférieure de la structure hiérarchique et appelé à partir de la couche supérieure» (généralement) Ce serait le cas. Les classes, modules, composants, etc. appelés ** artefacts existants **, bien entendu, doivent être correctement pris en compte par le «principe de responsabilité unique». Les classes, modules, composants, etc. qui sont «responsables sont correctement divisés et appelés uniquement de l'extérieur» sont naturellement isolés des changements externes, on peut donc dire qu'ils suivent le ** principe ouvert / fermé **. ..

LSP: le principe de remplacement de Liskov

Le principe et la compréhension du protocole en Swift, de l'interface en Java et des objets d'implémentation de classe abstraite en C ++ doivent se comporter comme défini par ces définitions d'interface. Si la définition de l'interface est correcte et claire, vous devez être prudent car vous ne faites que l'implémenter exactement, mais cela ne semble pas très important.

ISP: Principe de séparation des interfaces

Je pense que le principe est «ne dépendez pas des autres inutilement» et «ne dépendez pas des autres». Si la division des responsabilités est MECE, en utilisant le «principe ouvert et fermé» pour minimiser les dépendances et concevoir la bonne interface, les ** dépendances ** diminueront naturellement.

Qu'il suffise de dire, dans la dépendance à une interface telle que décrite dans le "Principe de l'inversion de dépendance" ci-dessous, l'idée qu'une classe définit plusieurs interfaces et ne force pas l'autre classe à implémenter des fonctions inutiles. Cela peut être important.

DIP: Principe de l'inversion de dépendance

Ce n'est presque plus une impression de lecture, mais j'aimerais aussi écrire ma propre opinion ici.

Premièrement, la dépendance est la direction de la jointure. Comme mentionné dans le «principe ouvert / fermé», si A est situé dans la couche supérieure (ci-après dénommée «couche A») et B est situé dans la couche inférieure (ci-après dénommée «couche B») dans la structure logicielle normale, A devient B. Même si cela dépend, B pense que cela ne posera pas beaucoup de problèmes car il y a peu de changements au départ.

Cependant, A dans la couche supérieure est un module invariant et je ne veux pas dépendre de B. Mais que faire si vous devez appeler la fonction B?

La réponse est ** "inversion des dépendances" **.

Plus précisément, cela dépend de l'interface (protocole Swift, interface Java) et ne dépend pas de l'implémentation (instance d'objet), non? C'est le "principe du renversement de la dépendance".

Dans la situation illustrée ci-dessus, A et B dépendent de l'interface. A appelle uniquement la fonction de B telle que définie dans l'interface, peu importe qui est B. B ne dépend pas de A en l'implémentant de manière à ne pas violer la définition de l'interface («Principe de Substitution de Riskov»). Je pense que l'expression ** inversion ** est utilisée en raison de la dépendance de cette interface de couche A.

Mais je suis un peu sceptique que c'est au propriétaire de l'interface ** de voir si elle est inversée. En d'autres termes, est le propriétaire de la définition de l'interface A ou B?

Compte tenu de la configuration illustrée ci-dessus, on ne peut pas dire qu'il s'agit d'un renversement. La couche B semble avoir pour objectif de définir une interface pour masquer une instance de B.

De cette façon, il est honnête que la dépendance à l'interface elle-même a une signification dans le modèle de conception et vous n'avez pas à vous soucier de l'inversion.

Résumé

** Architecture propre Je viens d'écrire mes pensées plutôt que le contenu de la structure et de la conception du logiciel que j'ai appris des maîtres **, mais je vais le résumer une fois.

Dans la conception détaillée des composants du module de classe, il est important

Pensez à vos responsabilités en tant que MECE
Réflexion sur le sens de la dépendance
Ne comptez pas dessus inutilement, n'en dépendez pas
Pensez à vous fier à l'interface si nécessaire

Je pense. Presque ** les divisions et les dépendances ** sont mentionnées.

Enfin, le tableau ci-dessous est donné. Puis-je écrire sur les parties 4 et 5 un jour ...

table des matières

Partie 1 Introduction
Design et architecture
Histoire de deux valeurs
Partie 2 Commencez par les composants:Paradigme de programmation
Vue d'ensemble du paradigme
Programmation structurée
Programmation orientée objet
Programmation fonctionnelle
Partie 3 Principes de conception
SRP: principe de responsabilité unique
OCP: principe ouvert / fermé
LSP: le principe de remplacement de Liskov
ISP: Principe de séparation des interfaces
DIP: Principe de l'inversion de dépendance
Partie 4 Principes des composants
composant
Condensation des composants
Combiner les composants
Partie 5 Architecture
Qu'est-ce que l'architecture?
Indépendance
Limite: dessinez une bordure
Anatomie des limites
Politique et niveau
Règles métier
Architecture hurlante
Une architecture propre
Présentateur et objet humble
Limite partielle
Calques et limites
Composant principal
Service: tout
Limite de test
Architecture intégrée propre
Détails de la partie 6
réduction
Partie 7 Annexe
réduction