Respostas:
A implementação de leitura e escrita provavelmente tem uma alta probabilidade de ser altamente coesa. Se um mudaria, o outro mudaria. Coesão alta é uma forte indicação de uma responsabilidade única e o princípio de responsabilidade única nos diz que eles devem ser reunidos na mesma classe. Se essas operações tiverem baixa coesão, é provável que sua divisão melhore a capacidade de manutenção.
Se, no entanto, houver consumidores que apenas leem dados sem gravar, ou apenas escrevem sem ler, é uma indicação de que, de uma perspectiva da interface, você deve separar essas operações, conforme prescrito pelo Princípio de Segregação da Interface. Isso significa que os consumidores devem definir duas interfaces nas quais podem confiar, enquanto a Fileclasse implementará as duas interfaces.
Ao aplicar o princípio SOLID ao design de um objeto, você pode considerar a leitura e gravação de arquivos como UMA responsabilidade - trabalhe com dados persistentes
No entanto, você não deve colocar a leitura e gravação de arquivos no mesmo método ou função.
A maioria das outras respostas parece ter esquecido que em sua pergunta falta uma informação crucial - você não nos disse se e como os documentos que você vai ler e escrever estão relacionados!
Seu aplicativo está com algo como um "objeto de documento" e o grava primeiro em um arquivo PDF e depois lê novamente o mesmo arquivo em um objeto de documento semelhante? Ou vice-versa, lê PDFs em um documento, faz algumas modificações e salva o mesmo documento em um novo PDF novamente? Então a leitura e a escrita devem ser vistas como uma responsabilidade. Pode ser o caso se o seu aplicativo for ou contiver algo como um componente "editor de PDF" ou um "kit de ferramentas de manipulação de PDF".
No entanto, se uma parte do seu aplicativo cria alguns arquivos PDF, por exemplo, em um componente de relatório, e outra parte não relacionada do seu aplicativo lê PDFs diferentes (por exemplo, um avaliador de anexo de email para um mecanismo de pesquisa) e a representação interna de Como esses últimos PDFs não têm nada em comum com o primeiro caso de uso, essas tarefas são responsabilidades diferentes.
Especialmente para PDF, esse segundo caso de uso é o caso que tenho visto com mais frequência em diferentes tipos de aplicativos. Existem muito mais bibliotecas / componentes por aí que apenas suportam a criação de PDF e apenas um número muito menor que também suporta a leitura de PDF. Se você usar uma biblioteca para gerar os arquivos PDF e uma biblioteca completamente diferente para ler os PDFs, deve ficar evidente que a leitura e gravação do PDF serão responsabilidades separadas.
De acordo com ( Robert C. Martin ), uma responsabilidade é um conjunto de funções que serve a um ator em particular.
Um ator deve ser a única fonte de mudança de uma determinada responsabilidade (deve haver apenas um motivo para mudar).
No seu caso, você deve primeiro definir os atores como um primeiro passo e depois fazer as perguntas:. Existem atores interessados apenas na leitura de arquivos e outros na escrita?
Se for o caso, a leitura e gravação de arquivos são duas responsabilidades separadas. Porque haverá várias fontes de mudanças (muitos atores podem pedir para alterar a lógica de leitura e a mesma coisa para escrever).