Il n'y a pas de réponse claire à cela. Bien que la question soit étroite, les explications ne le sont pas.
Pour moi, c'est un peu comme le rasoir d'Occam si vous le souhaitez. C'est un idéal où j'essaie de mesurer mon code actuel. Il est difficile de le décrire avec des mots clairs et simples. Une autre métaphore serait "un sujet" aussi abstrait, c'est-à-dire difficile à saisir, que "une seule responsabilité". Une troisième description serait "traitant d'un niveau d'abstraction".
Qu'est-ce que cela signifie concrètement?
Dernièrement, j'utilise un style de codage qui comprend principalement deux phases:
La phase I est décrite comme un chaos créatif. Dans cette phase, j'écris le code pendant que les pensées circulent - c'est-à-dire crues et laides.
La phase II est le contraire. C'est comme nettoyer après un ouragan. Cela prend le plus de travail et de discipline. Et ensuite, je regarde le code du point de vue d'un designer.
Je travaille principalement en Python maintenant, ce qui me permet de penser à des objets et à des classes plus tard. Première phase I - Je n'écris que des fonctions et les diffuse presque aléatoirement dans différents modules. Au cours de la phase II , une fois les travaux en cours, j’examine de plus près quel module traite quelle partie de la solution. Et en parcourant les modules, des sujets me sont apparus. Certaines fonctions sont liées thématiquement. Ce sont de bons candidats pour les cours . Et après avoir transformé les fonctions en classes - ce qui est presque fait avec l'indentation et l'ajout self
à la liste des paramètres en python;) - j'utilise SRP
comme Razor d'Occam pour supprimer les fonctionnalités des autres modules et classes.
Un exemple courant peut être l’ écriture de petites fonctionnalités d’exportation l’autre jour.
Il y avait le besoin de CSV , Excel et des feuilles Excel combinées dans un zip.
La fonctionnalité simple a été réalisée dans trois vues (= fonctions). Chaque fonction utilisait une méthode commune pour déterminer les filtres et une seconde méthode pour récupérer les données. Ensuite, dans chaque fonction, l’exportation a été préparée et a été envoyée en tant que réponse du serveur.
Il y avait trop de niveaux d'abstraction mélangés:
I) traitement des demandes / réponses entrantes / sortantes
II) déterminer les filtres
III) récupération des données
IV) transformation des données
La première étape consistait à utiliser une seule abstraction ( exporter
) pour traiter les couches II à IV.
Le seul reste était le sujet traitant des demandes / réponses . Au même niveau d'abstraction, l' extraction des paramètres de requête est satisfaisante. J'ai donc eu pour cette vue une "responsabilité".
Deuxièmement, je devais séparer l'exportateur qui, comme nous l'avons vu, consistait en au moins trois autres couches d'abstraction.
La détermination des critères de filtrage et la remontée effective se situent presque au même niveau d'abstraction (les filtres sont nécessaires pour obtenir le bon sous-ensemble de données). Ces niveaux ont été placés dans quelque chose comme une couche d'accès aux données .
Dans l'étape suivante, j'ai cassé les mécanismes d'exportation actuels: lorsqu'il était nécessaire d'écrire dans un fichier temporel, je l'ai divisé en deux "responsabilités": une pour l'écriture proprement dite des données sur disque et une autre partie concernant le format réel.
Lors de la formation des classes et des modules, les choses sont devenues plus claires, ce qui appartenait à où. Et toujours la question latente, si la classe en fait trop .
Comment déterminez-vous les responsabilités que chaque classe devrait avoir et comment définissez-vous une responsabilité dans le contexte du PÉR?
Il est difficile de donner une recette à suivre. Bien sûr, je pourrais répéter la règle «un niveau d’abstraction» cryptée si cela aide.
C'est surtout pour moi une sorte d '"intuition artistique" qui mène au design actuel; Je modélise le code comme un artiste peut sculpter de l'argile ou peindre.
Imagine-moi comme un codeur Bob Ross ;)