Sto appena iniziando a esplorare SOLID e non sono sicuro che la lettura da file e la scrittura su file abbiano la stessa responsabilità.
La destinazione è lo stesso tipo di file; Voglio leggere e scrivere. Pdf nella mia domanda.
L'applicazione è in Python se questo fa alcuna differenza.
L'implementazione di lettura e scrittura probabilmente ha un'alta probabilità di essere altamente coesa. Se uno cambierebbe, anche l'altro. L'alta coesione è una strong indicazione di una singola responsabilità e il principio della responsabilità unica ci dice che dovrebbero essere messi insieme nella stessa classe. Se queste operazioni hanno una bassa coesione, è probabile che la loro divisione migliori la manutenibilità.
Se, tuttavia, ci sono consumatori che leggono solo i dati senza scrivere o scrivono solo senza leggere, è un'indicazione che dal punto di vista dell'interfaccia è necessario separare queste operazioni, come prescritto dal Principio di segmentazione dell'interfaccia. Ciò significa che i consumatori dovrebbero definire due interfacce da cui possono dipendere, mentre la classe File implementerà entrambe le interfacce.
Quando applichi il principio SOLID per progettare un oggetto, puoi considerare la lettura e la scrittura di file come UNA RESPONSABILITÀ - lavorare con dati persistenti
Tuttavia, non dovresti mettere il file in lettura e scrittura nello stesso metodo o funzione.
La maggior parte delle altre risposte sembra aver trascurato il fatto che nella tua domanda manca una parte fondamentale di informazioni - non ci hai detto se e in che modo i documenti che stai per leggere e scrivere sono correlati!
La tua applicazione ha qualcosa di simile a un "oggetto documento" e lo scrive prima in un file PDF, quindi in seguito legge nuovamente lo stesso file in un oggetto documento simile? O viceversa, legge i PDF in un documento, apporta alcune modifiche e salva di nuovo lo stesso documento in un nuovo PDF? Quindi leggere e scrivere dovrebbero essere considerati una sola responsabilità. Questo potrebbe essere il caso se la tua applicazione è o contiene qualcosa come un componente "PDF editor" o un "PDF manipulation toolkit".
Tuttavia, se una parte dell'applicazione crea alcuni file PDF, ad esempio in un componente di reporting, e un'altra parte non correlata dell'applicazione legge diversi PDF (ad esempio, un programma di valutazione degli allegati di posta elettronica per un motore di ricerca) e la rappresentazione interna di questi ultimi PDF non ha nulla in comune con il primo caso d'uso, quindi tali compiti sono responsabilità diverse.
Soprattutto per il PDF, questo caso di secondo utilizzo è il caso che ho visto molto più spesso in diversi tipi di applicazioni. Ci sono molte più librerie / componenti là fuori che supportano solo la creazione di PDF, e solo un numero molto più piccolo che supporta anche la lettura di PDF. Se si intende utilizzare una sola libreria per generare i file PDF e una completamente diversa per leggere i PDF, dovrebbe essere evidente che la lettura e la scrittura in PDF saranno responsabilità separate.
Secondo ( Robert C. Martin ) una responsabilità è un insieme di funzioni che serve un particolare attore.
Un attore dovrebbe essere l'unica fonte di cambiamento di una determinata responsabilità (dovrebbe esserci una sola ragione per cambiare).
Nel tuo caso dovresti prima definire gli attori come primo passo, quindi porre le domande: . Ci sono attori che sono interessati solo leggendo i file e altri scrivendo?
Se è il caso, leggere e scrivere file sono due responsabilità separate. Perché ci saranno molteplici fonti di cambiamento (molti attori potrebbero chiedere di cambiare la logica di lettura e la stessa cosa per scrivere).
Leggi altre domande sui tag object-oriented-design solid single-responsibility