Estoy empezando a explorar SOLID y no estoy seguro de si leer archivos y escribirlos sea la misma responsabilidad.
El objetivo es el mismo tipo de archivo; Quiero leer y escribir .pdf en mi aplicación.
La aplicación está en Python si eso hace alguna diferencia.
La implementación de lectura y escritura probablemente tenga una alta probabilidad de ser altamente cohesiva. Si uno cambiara, también lo haría el otro. La alta cohesión es un fuerte indicio de una Responsabilidad Única y el Principio de Responsabilidad Única nos dice que se deben reunir en la misma clase. Si esas operaciones tienen una baja cohesión, es probable que dividirlas mejore la capacidad de mantenimiento.
Sin embargo, si hay consumidores que solo leen datos sin escribir, o solo escriben sin leer, es una indicación de que, desde una perspectiva de interfaz, debe separar estas operaciones, según lo prescrito en el Principio de Segregación de Interfaz. Esto significa que los consumidores deben definir dos interfaces en las que puedan depender, mientras que la clase File implementará ambas interfaces.
Cuando aplica el principio SOLID para diseñar un objeto, puede considerar la lectura y escritura de archivos como UNA responsabilidad: trabaje con datos persistentes
Sin embargo, no debe colocar la lectura y escritura de archivos en el mismo método o función.
La mayoría de las otras respuestas parecen haber pasado por alto que en su pregunta falta una pieza de información crucial: ¡no nos dijo si los documentos que va a leer y cómo están relacionados están relacionados!
¿Su aplicación tiene algo así como un "objeto de documento" y lo escribe primero en un archivo PDF, y luego lee el mismo archivo nuevamente en un objeto de documento similar? O viceversa, ¿lee los PDF en un documento, le hace algunas modificaciones y guarda el mismo documento en un nuevo PDF de nuevo? Entonces la lectura y la escritura deben verse como una responsabilidad. Ese puede ser el caso si su aplicación es o contiene algo como un componente de "editor de PDF" o un "kit de herramientas de manipulación de PDF".
Sin embargo, si una parte de su aplicación crea algunos archivos PDF, por ejemplo, en un componente de informes, y otra parte no relacionada de su aplicación lee diferentes PDF (por ejemplo, un evaluador de archivos adjuntos para un motor de búsqueda), y La representación interna de estos últimos PDF no tiene nada en común con el primer caso de uso, entonces esas tareas son responsabilidades diferentes.
Especialmente para PDF, ese segundo caso de uso es el caso que he visto mucho más a menudo en diferentes tipos de aplicaciones. Hay muchas más bibliotecas / componentes que solo soportan la creación de PDF, y solo un número mucho más pequeño que también admite la lectura de PDF. Si va a utilizar una biblioteca para generar los archivos PDF y otra completamente diferente para leer los archivos PDF, entonces debería ser evidente que la lectura y escritura de los PDF serán responsabilidades separadas.
Según ( Robert C. Martin ) una responsabilidad es un conjunto de funciones que sirve a un actor en particular.
Un actor debe ser la única fuente de cambio de una responsabilidad dada (solo debe haber una razón para cambiar).
En su caso, primero debe definir a los actores como un primer paso, luego haga las preguntas: . ¿Hay actores que están interesados solo leyendo archivos y otros escribiendo?
Si es el caso, leer y escribir archivos son dos responsabilidades separadas. Porque habrá múltiples fuentes de cambios (muchos actores pueden pedir cambiar la lógica de lectura y lo mismo para escribir).
Lea otras preguntas en las etiquetas object-oriented-design solid single-responsibility