S.O.L.I.D PAR LA PRATIQUE en JAVA(3è PARTIE) INTRODUCTION Dans les précédents articles nous avons parlé d'abord de ce que veut dire l'acronyme S.O.L.I.D et de son importance. Ensuite, nous avons abordé de manière singulière la première lettre de l'acronyme: " S ". Je rappelle que notre objectif est de découvrir par la pratique le rôle et l'impacte de chaque notion que revêt chaque lettre de l'acronyme SO.L.I.D . Pourquoi faire du code selon les principes S.O.L.I.D? un code avec pas ou moins de bugs un code propre et lisible un code cohérent donc logique et compréhensible un code facilement maintenable un code extensible ou facilement évolutif Aujourd'hui, nous allons continuer notre marche vers la découverte de la notion de la lettre " O ". Pour se faire , je vous propose la démarche suivante: 1- " O ": Ouvert à l'extension mais fermé à la modification, qu'est ce que cela représente pour nous les devs? 2- Zoomons sur...
Articles
- Obtenir le lien
- X
- Autres applications
S.O.L.I.D PAR LA PRATIQUE(2è partie) INTRODUCTION Après le premier article qui nous a permis de planter le décore, nous voici en plein dans ce voyage pour comprendre les principes S. O . L . I . D par la pratique. Pour ceux qui n'ont pas encore lu le premier article il est accessible ici SOMMAIRE 1- Que représente le "S" 2- Cas pratique 3- Conclusion 1- Que représente le "S" Tout commence par là. C'est le premier des 5 principes. C'est certainement le plus simple à comprendre cela ne dit en rien que les autres ne sont pas facilement compréhensible. Mais en terme niveau de compréhension, on peut dire c'est le plus simple. SRP ou principe de la responsabilité unique est le principe qui précise ce qui suit: Une classe doit avoir une et une seule raison de changer ou encore, une classe doit réaliser une et une seule tâche. Pour faire une comparaison, on pourrait dire que ce principe est à l'orienté objet ce que le singleton est au patron de con...
- Obtenir le lien
- X
- Autres applications
S.O.L.I.D PAR LA PRATIQUE Dé nos jours avoir un programme ou une application qui intègrent facilement les nouvelles fonctionnalités sans complication est devenu de plus en rare. Est-ce à cause d'une mauvais approche analytique? Est-ce la mauvaise compréhension aboutissant à un mauvais choix architecturale? On peut alors se poser autant de questions. Pour ma part, je pense qu'il ne faut pas sortir des chantiers battus. En effet, le choix d'une architecture au détriment d'une autre doit être un choix sagement nourri en prenant en compte de l'évolutivité des fonctionnalités. Heureusement que des ingénieurs en ingénierie logiciel se sont penchés sur la question en mettant en place des standards approuvés par la majeur partie de la communauté des développeurs. Je voudrais partager avec vous sur un ensemble de cinq(5) articles sur les principes S.O.L.I.D mais pas que la théorie, à travers des...