[JAVA] J'ai beaucoup appris sur les «principes de conception de systèmes utiles sur le terrain», je les ai donc résumés ~ Chapitre 1 ~

Connaissez-vous les principes de la conception de systèmes?

Cet article est un article qui résume ce que j'ai appris en lisant «Principes de conception de systèmes utiles sur le terrain» et ce qui semble être utile au travail. C'est juste un résumé, et j'ai omis les parties que je ne peux pas expliquer, donc si vous voulez bien le comprendre, veuillez lire le livre!

[Principes de conception de système utiles sur le terrain](https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81%A7%E5%BD%B9%E7%AB % 8B% E3% 81% A4% E3% 82% B7% E3% 82% B9% E3% 83% 86% E3% 83% A0% E8% A8% AD% E8% A8% 88% E3% 81% AE % E5% 8E% 9F% E5% 89% 87-% E5% A4% 89% E6% 9B% B4% E3% 82% 92% E6% A5% BD% E3% 81% A7% E5% AE% 89% E5% 85% A8% E3% 81% AB% E3% 81% 99% E3% 82% 8B% E3% 82% AA% E3% 83% 96% E3% 82% B8% E3% 82% A7% E3% 82% AF% E3% 83% 88% E6% 8C% 87% E5% 90% 91% E3% 81% AE% E5% AE% 9F% E8% B7% B5% E6% 8A% 80% E6% B3% 95-% E5% A2% 97% E7% 94% B0-% E4% BA% A8 / dp / 477419087X)

La personne qui a écrit ce livre

L'auteur est Toru Masuda, qui est également impliqué dans la conception et le développement d'applications utilisant la conception axée sur le domaine. Il y avait de nombreuses diapositives liées à la conception axée sur le domaine dans le partage de diapositives.

Partage de diapositives de Masuda-san

Chapitre 1 "Petit et facile à comprendre"

Pourquoi les changements logiciels sont si difficiles

―― La raison pour laquelle des effets secondaires et des problèmes inattendus se produisent en raison de modifications et de changements logiciels est qu'il y a un problème avec la conception (= code source). --Un programme difficile à changer a trois caractéristiques

• Méthode longue (difficile à comprendre) --Grande classe (difficile d'identifier la plage d'influence lors du changement) --Beaucoup d'arguments (difficile de spécifier la plage d'influence lors du changement) ――Le tout devient compliqué en raison du chevauchement de petites corrections.

Comment écrire pour faciliter le changement de programme

--Utilisez un nom descriptif

• Évitez d'utiliser des abréviations et des noms incohérents

// Bad
int a; 
int qty;
return qty * up;

// Good
int quantity;
return quantity * unitPrice;

--Insérez une ligne vide pour chaque unité de code (unité de traitement) --Préparer des variables (= variables pour l'explication) pour chaque objectif (éviter l'affectation destructive ((l'affectation destructive est une façon d'écrire en utilisant une variable et en répétant l'affectation)))

// Bad
int price = quantity * unitPrice; //Quantité x prix unitaire

if (price < 3000)
  price += 500;  //livraison

price = price * taxRate(); //Montant TTC

// Good
int basePrice = quantity * unitPrice; //Quantité x prix unitaire

int shippingCost = 0; //livraison
if (basePrice < 3000)
  shippingCost = 500;

int ItemPrice = ... //Montant TTC

• Indépendant en tant que méthode (les mérites sont les suivants) --Il devient plus facile de verrouiller l'effet des changements de méthode
• Les détails sont décrits dans la méthode, le code appelant est donc propre.
• Le nom de la méthode facilite la compréhension de l'intention du code

int basePrice = quantity * unitPrice; //Quantité x prix unitaire

int shippingCost = shippingConst(basePrice) //Découpez le calcul d'expédition vers une autre méthode

int shippingCost(int basePrice) {
...
}

• Éliminer le code en double dans différentes classes --Créer une classe (objet de domaine) correspondant à chaque intérêt commercial ――Par exemple, vous pouvez limiter la cible de changement et la plage d'influence au sein de l'objet en regroupant les frais d'expédition dans la classe d'expédition.

Rendez-le facile à comprendre et sûr dans une petite classe

• Les valeurs gérées dans l'entreprise peuvent ne pas correspondre aux valeurs gérées dans le type de données de base. ――Par exemple, même si le prix unitaire est de 100 millions de yens en entreprise, si vous utilisez int, vous pouvez gérer de moins 2,1 milliards de yens à plus de 2,1 milliards de yens.
• Vous pouvez éviter les valeurs anormales en créant votre propre classe (objet de valeur) afin de pouvoir gérer les valeurs correctes à des fins commerciales ((la méthode de création d'une classe dédiée pour la gestion des valeurs est appelée un objet de valeur)). ça peut --Par exemple, en créant une classe Quantité spécialisée dans la quantité et une classe Téléphone spécialisée dans les numéros de téléphone, vous pouvez éviter les valeurs anormales et en même temps clarifier l'intention du code.
• Rendre les objets de valeur immuables (créer différents objets si nécessaire)
• Parce que l'écrasement des variables peut provoquer des effets secondaires inattendus --Utilisez des types pour rendre votre code clair et sécurisé --Utilisez des types pour que le compilateur trouve des erreurs

// Bad
int amount(int unitPrice , int quantity) {
... //Une erreur de compilation ne se produit pas même si le prix unitPrice et la quantité sont passés dans le mauvais ordre.
}

// Good
Money amount(Money unitPrice, Quantity quantity) {
... //Un mauvais ordre de passage de unitPrix et de quantité entraînera une erreur de compilation
}

Résumé du chapitre 1

• La base de l'organisation du code réside dans les noms et les paragraphes
• Méthodes courtes, organisez votre code en petites classes
• Facilitons la compréhension et la sécurisation avec des objets de valeur
• La mise en correspondance des noms de classes et des noms de méthodes avec des termes commerciaux rend le programme plus facile à comprendre et à modifier.