Respuestas:
La implementación de lectura y escritura probablemente tenga una alta probabilidad de ser altamente coherente. Si uno cambiara, también lo haría el otro. La alta cohesión es una fuerte indicación de una responsabilidad única y el Principio de responsabilidad única nos dice que deben agruparse 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 por el Principio de segregación de interfaz. Esto significa que los consumidores deben definir dos interfaces de las que pueden depender, mientras que la Fileclase implementará ambas interfaces.
Cuando aplica el principio SOLID para diseñar un objeto, puede considerar la lectura y escritura de archivos como UNA responsabilidad: trabajar 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 crucial de información: ¡no nos dijo si y cómo están relacionados los documentos que va a leer y escribir!
¿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 archivos PDF en un documento, realiza algunas modificaciones y guarda el mismo documento en un nuevo PDF nuevamente? Entonces leer y escribir debe 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 de correo para un motor de búsqueda) y la representación interna de esos últimos PDF no tienen nada en común con el primer caso de uso, entonces esas tareas son diferentes responsabilidades.
Especialmente para PDF, ese segundo caso de uso es el que he visto con mucha más frecuencia en diferentes tipos de aplicaciones. Hay muchas más bibliotecas / componentes que solo admiten la creación de PDF, y solo un número mucho menor que también admite la lectura de PDF. Si va a utilizar una biblioteca única para generar los archivos PDF, y una completamente diferente para leer los archivos PDF, entonces debería ser evidente que la lectura y escritura de 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 (debe haber una sola razón para cambiar).
En su caso, primero debe definir a los actores como un primer paso, luego hacer las preguntas:. ¿Hay actores interesados solo en leer archivos y otros en escribir?
Si es el caso, leer y escribir archivos son dos responsabilidades separadas. Debido a que habrá múltiples fuentes de cambios (muchos actores pueden pedir cambiar la lógica de lectura y lo mismo para escribir).