Je commence tout juste à explorer SOLID et je ne sais pas si la lecture à partir de fichiers et l'écriture dans des fichiers sont la même responsabilité.
La cible est du même type de fichier; Je veux lire et écrire des .pdf dans ma candidature.
L'application est en Python si cela fait une différence.
Réponses:
L'implémentation en lecture et en écriture a probablement une forte probabilité d'être très cohérente. Si l'un devait changer, l'autre aussi. Une cohésion élevée est une indication forte d'une responsabilité unique et le principe de responsabilité unique nous dit qu'ils doivent être regroupés dans la même classe. Si ces opérations ont une faible cohésion, il est probable que leur séparation améliore la maintenabilité.
Cependant, si certains consommateurs ne lisent que des données sans écrire, ou écrivent uniquement sans lire, cela indique que du point de vue de l'interface, vous devez séparer ces opérations, comme le prescrit le principe de ségrégation d'interface. Cela signifie que les consommateurs doivent définir deux interfaces sur lesquelles ils peuvent compter, tandis que la Fileclasse implémentera les deux interfaces.
Lorsque vous appliquez le principe SOLID pour concevoir un objet, vous pouvez considérer la lecture et l'écriture de fichiers comme UNE responsabilité - travailler avec des données persistantes
Cependant, vous ne devez pas placer la lecture et l'écriture de fichiers dans la même méthode ou fonction.
La plupart des autres réponses semblent avoir oublié que dans votre question, il manque une information cruciale - vous ne nous avez pas dit si et comment les documents que vous allez lire et écrire sont liés!
Votre application a-t-elle quelque chose comme un «objet document» et l'écrit d'abord dans un fichier PDF, puis lit à nouveau le même fichier dans un objet document similaire? Ou vice versa, il lit les PDF dans un document, y apporte des modifications et enregistre à nouveau ce même document dans un nouveau PDF? La lecture et l'écriture doivent alors être considérées comme une responsabilité. Cela peut être le cas si votre application est ou contient quelque chose comme un composant "éditeur PDF" ou une "boîte à outils de manipulation PDF".
Toutefois, si une partie de votre application crée des fichiers PDF, par exemple, dans un composant de rapport, et qu'une autre partie non liée de votre application lit différents PDF (par exemple, un évaluateur de pièces jointes pour un moteur de recherche), et la représentation interne de ces derniers PDF n'ont rien de commun avec le premier cas d'utilisation, alors ces tâches sont des responsabilités différentes.
Surtout pour le PDF, ce deuxième cas d'utilisation est le cas que j'ai vu beaucoup plus souvent dans différents types d'applications. Il y a beaucoup plus de bibliothèques / composants qui ne prennent en charge que la création de PDF, et seulement un nombre beaucoup plus petit qui prend également en charge la lecture de PDF. Si vous comptez utiliser une seule bibliothèque pour générer les fichiers PDF et une autre complètement différente pour lire les PDF, il devrait être évident que la lecture et l'écriture des PDF seront des responsabilités distinctes.
Selon ( Robert C. Martin ), une responsabilité est un ensemble de fonctions qui sert un acteur particulier.
Un acteur devrait être la seule source de changement d'une responsabilité donnée (il ne devrait y avoir qu'une seule raison de changer).
Dans votre cas, vous devez d'abord définir les acteurs dans un premier temps, puis poser les questions:. Y a-t-il des acteurs qui ne sont intéressés que par la lecture de fichiers et d'autres par l'écriture?
Si c'est le cas, la lecture et l'écriture des fichiers sont deux responsabilités distinctes. Parce qu'il y aura de multiples sources de changements (de nombreux acteurs peuvent demander de changer la logique de lecture et la même chose pour l'écriture).