Toute personne ayant une certaine expérience en programmation logicielle juge le code logiciel écrit par d'autres, en utilisant des paramètres de jugement basés sur leur cheminement de carrière.
Au cours de ma carrière professionnelle, j'ai connu de nombreux développeurs, j'ai vu des milliers de lignes de code et lorsque j'ai besoin d'évaluer les compétences d'un développeur, je considère principalement deux facteurs:
Heureusement, il existe des principes fondamentaux ou des principes qui facilitent l'amélioration du codage.
l'acronyme SOLID signifie:
S: principe de responsabilité unique
O: principe ouvert-fermé
L: Principe de substitution de Liskov
I: Principe de ségrégation des interfaces
D: Principe d'inversion des dépendances
Commençons par plonger dans le premier principe SOLID, à savoir le
Une classe (ou un module) ne doit avoir qu'une seule raison de changer, d'évoluer.
Le concept lui-même est très simple, mais pour atteindre cette simplicité, le chemin de mise en œuvre peut être très compliqué. Une classe ne doit avoir qu'une seule raison de changer.
Mais pourquoi
Pourquoi est-il si important de n'avoir qu'une seule raison de changer?
Par exemple, s'il y a deux raisons différentes de changer, il est concevable que deux équipes différentes puissent travailler sur le même code pour deux raisons différentes. Chacun devra implémenter sa propre solution, ce qui dans le cas d'un langage compilé (comme C ++, C # ou Java), pourrait conduire à des modules incompatibles avec d'autres équipes ou d'autres parties de l'application.
Un autre exemple, si vous utilisez un langage interprété, vous devrez peut-être retester la même classe ou module pour différentes raisons. Cela signifie plus de travail, de temps et d'efforts pour le contrôle qualité.
Identifier la caractéristique qu'une classe ou un module devrait avoir est beaucoup plus complexe que de simplement consulter une liste de contrôle pour exécuter des tests.
Mais essayons de penser d'un point de vue moins technique, c'est-à-dire essayons d'analyser l'utilisateur de notre classe ou module, c'est-à-dire qui l'utilisera. Un aspect fondamental que nous devons toujours garder à l'esprit est le fait que les utilisateurs de l'application ou du système que nous développons qui sont servis par un module particulier seront ceux qui en demanderont des modifications. Les personnes servies demanderont à changer de classe ou de module.
Quelques exemples de modules et leur utilisation:
Donc si la première étape est de rechercher les acteurs ou l'acteur qui a le rôle d'interlocuteur avec le module, associer des individus à tous les rôles peut être difficile. Dans une petite entreprise, une personne peut jouer plusieurs rôles tandis que dans une grande entreprise, plusieurs personnes peuvent avoir un seul rôle.
Il semble plus raisonnable d'identifier des rôles plutôt que des personnes ou des utilisateurs.
donc:
Voyons quelques exemples
Supposons que nous ayons une classe Book qui encapsule le concept d'un livre et ses fonctionnalités.
livre de classe {
function getTitle () {
retourner «Un grand livre»;
}
function getAuthor () {
retourner «Alessandro Baricco»;
}
function page suivante () {
// page suivante
}
function printCurrentPage () {
echo "contenu de la page courante";
}
}
C'est une classe très normale. Nous avons un livre, et la classe peut nous donner le titre, ils peuvent nous donner l'auteur et ils peuvent passer à autre chose. Enfin, il est également capable d'imprimer la page en cours sur l'écran.
Cependant, il y a un petit problème.
En pensant aux acteurs impliqués dans la gestion de l'objet Livre, qui pourraient-ils être?
On peut facilement penser à deux acteurs différents ici: Gestion des livres (viens il bibliothécaire) Et Mécanisme de soumission des données (comme la façon dont nous voulons fournir du contenu à l'utilisateur: interface utilisateur graphique à l'écran, interface utilisateur texte uniquement, peut-être impression).
Nous avons donc deux acteurs très différents qui interagissent avec la classe.
En un mot, cette classe fait un mélange entre:
cela peut poser problème car cela viole le principe de responsabilité unique (SRP).
Comment changer, comment améliorer ce code pour respecter le principe de responsabilité unique?
Jetez un œil au code suivant:
livre de classe {
function getTitle () {
retour «Oceano Mare»;
}
function getAuthor () {
retourner «Alessandro Baricco»;
}
fonction tourner la page () {
// page suivante
}
function getCurrentPage () {
echo "contenu de la page courante";
}
}
Imprimante d'interface {
function printPage ($ page);
}
La classe StampaLibro implémente l'imprimante {
function printPages ($ page) {
echo $ page;
}
}
La classe HtmlPrinter implémente l'imprimante {
function printPages ($ page) {
écho ' ». $ page. ' ';
}
}
Cet exemple très simple montre comment séparer la présentation de la logique métier, et en conformité avec SRP, il offre de grands avantages dans la flexibilité de notre projet.
Regardons un autre exemple:
Un exemple similaire à celui ci-dessus est celui où un objet peut s'enregistrer et se récupérer de la présentation.
livre de classe {
function getTitle () {
retour «Oceano Mare»;
}
function getAuthor () {
retourner «Alessandro Baricco»;
}
fonction tourner la page () {
// page suivante
}
function getCurrentPage () {
retourne "contenu de la page courante";
}
function save () {
$ filename = '/ documents /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();
file_put_contents ($ filename, sérialiser ($ this));
}
}
Comme auparavant, ici aussi, nous pouvons identifier différents acteurs comme Gestion des livres (viens il bibliothécaire) Et Persistance. Chaque fois que nous voulons changer la façon dont nous allons de page en page, nous devons changer cette classe. Nous pouvons avoir plusieurs raisons de changer.
livre de classe {
function getTitle () {
retour «Oceano Mare»;
}
function getAuthor () {
retourner «Alessandro Baricco»;
}
fonction tourner la page () {
// page suivante
}
function getCurrentPage () {
retourne "contenu de la page courante";
}
}
class SimpleFilePersistance {
function save (Book $ book) {
$ filename = '/ documents /'. $ livre-> getTitle (). '-'. $ livre-> getAuthor ();
file_put_contents ($ filename, serialize ($ book));
}
}
Déplacer l'opération de persistance vers une autre classe séparera clairement les responsabilités et nous serons libres d'échanger des méthodes de persistance sans affecter notre classe Book. Par exemple, implémenter une classe DatabasePersistence serait trivial, et notre logique métier construite autour des opérations de livre ne changera pas.
Continuez en lisant le deuxième principe Ouvert / Fermé ->
Ercole Palmeri
Développer la motricité fine grâce au coloriage prépare les enfants à des compétences plus complexes comme l’écriture. Colorier…
Le secteur naval est une véritable puissance économique mondiale, qui a navigué vers un marché de 150 milliards...
Lundi dernier, le Financial Times a annoncé un accord avec OpenAI. FT autorise son journalisme de classe mondiale…
Des millions de personnes paient pour des services de streaming en payant des frais d’abonnement mensuels. Il est communément admis que vous…
