[JAVA] Comment penser la conception de classe (division) dans un système d'entreprise (1)
C'est un thème que j'explore encore, mais je vais l'écrire car la politique a été définie et les résultats obtenus. Pour ceux qui le connaissent, c'est "naturel", alors sautez l'article. Le contenu est destiné aux jeunes à mi-carrière. J'espère que la discussion l'améliorera encore.
supposition
- Application Java (C # convient, s'il s'agit d'un langage orienté objet)
- Pour les systèmes d'entreprise indépendamment du BtoC ou du BtoB
- Comprend l'API Web, etc. En bref, les lots Java, etc. ne sont pas couverts.
- Les compétences en programmation de l'équipe de projet ne sont pas si élevées.
- Imaginez une équipe avec un grand nombre de SE (qui ne sont plus codeurs) qui n'ont aucune compétence, même si le coût est à part entière en raison des effets néfastes de la sous-traitance multiple.
Points à considérer
- Je souhaite avoir une configuration qui répond de manière flexible aux changements dans l'entreprise (changements / ajouts / suppression d'exigences).
- Il sera continuellement rénové à l'avenir, mais il y a de fortes chances que les membres changent, c'est pourquoi nous voulons rendre la lisibilité importante.
- Je ne veux pas introduire de théories trop difficiles parce que je ne peux pas m'attendre aux compétences des membres du projet. (Je n'aime pas DDD)
Est-ce un tel endroit? Le point est, "Je veux écrire du code qui peut être facilement étendu avec du code simple."
Conclusion
Écrivez une brève conclusion. Divisez la classe verticalement (procéduralement) et horizontalement (orienté objet) en fonction du rôle. Ce n'est pas une grande histoire, mais comment diviser Controller / Service / Repository dans Spring Boot.
Concept 1: le principe selon lequel l'entreprise est unique et le mécanisme est commun
Pour faire simple, le développement de système consiste souvent à gérer l'entreprise d'un client. C'est une question d'efficacité et de création d'entreprise. Donc, ce qui est important en ce moment est ** Quand vous regardez différents systèmes, quelles sont les parties communes et les parties qui ne sont pas communes ** </ font>? C'est exactement ce que dit le titre, et l'activité du client elle-même n'est pas courante. Cependant, il y a une forte probabilité que le mécanisme pour y parvenir soit commun.
L'entreprise est unique
Par exemple, si l'on considère le système des opérations de transfert d'argent international des banques et les activités de commande des dépanneurs, dans quelle mesure les procédures sont-elles communes? N'est-ce pas 0? De cette façon, si le type d'entreprise est différent, l'entreprise sera complètement différente. De plus, même dans la même entreprise de transfert d'argent international, ce sera différent si la banque le fait et si la société de titres le fait. Même parmi les mêmes banques, UFJ et Sumitomo seront différents (si l'activité est la même, elle peut être réalisée à faible coût en installant le même système). En d'autres termes, la partie métier ne peut pas être réutilisée.
Le mécanisme est commun
Même si le système d'entreprise est complètement différent, le mécanisme utilisé est généralement le même. Cela signifie que si vous souhaitez stocker des données, utilisez LDAP ou SQL et si vous souhaitez envoyer un message, utilisez HTTP ou SOAP. En d'autres termes, vous pouvez voir que la partie du mécanisme telle que le stockage dans la base de données ou l'envoi de la requête quelque part est commune (ou réutilisée). Si vous vous concentrez sur une industrie, vous êtes peut-être en conformité avec la norme. Par exemple, il a été décidé d'utiliser Swift Telegram pour les envois de fonds internationaux, il semble donc que le mécanisme soit le même dans le cadre des envois de fonds internationaux.
Concept 2: accepter le code en double pour des raisons professionnelles
Parfois, il y a des radicaux qui n'autorisent pas du tout le code dupliqué et peuvent appeler du code qui apparaît plus d'une fois comme méthode, mais si vous créez une classe ou une méthode avec cette idée (même si cela ne va pas aussi loin ...) , Il devient impossible de se séparer selon le rôle, et un code chaotique est créé en termes de dénomination et de division des fonctions.
De plus, même si elle a été magnifiquement divisée par Extends etc. au début, il y a des cas où vous ne voulez changer qu'une petite partie de la classe héritée tout en poursuivant la réparation (dans le pire des cas, au moment de la prochaine réparation).
Même si une telle classe est créée en premier et divisée magnifiquement, AbstractClass2 sera créée et double héritée pour un traitement qui n'est que partiellement différent lors de la prochaine modification. C'est le début de l'enfer.
J'ai vu jusqu'à quadrupler l'héritage.
Dans le passé, on disait que les codes uniques étaient beaux, mais dans les cas où des membres peu qualifiés sont fréquemment remplacés, les codes compliqués deviennent un bagage. C'est parce que le code ne peut pas être compris ou maintenu.
Alors que devons-nous faire. Pensez séparément à l'activité et au mécanisme, implémentez la partie métier dans chaque classe et standardisez la partie mécanisme.
Même si du code dupliqué se produit, la partie métier est implémentée individuellement. Même si la plupart d'entre eux sont communs, ils seront plus faciles à réparer.
La méthode 1 est implémentée dans la classe affaires comme ceci. Le contenu de method1 peut contenir du code dupliqué, mais acceptons le duplicata comme une entreprise différente. Ensuite, même s'il est nécessaire de ne modifier qu'une seule des tâches qui étaient identiques au début, vous pouvez la corriger en apportant les modifications minimales.
Method2 est placé dans AbstractClass en tant que mécanisme commun.
Cela s'allonge un peu, alors continuons avec l'article suivant.
Recommended Posts