Ho appena iniziato a esplorare SOLID e non sono sicuro che la lettura da file e la scrittura su file siano la stessa responsabilità.
La destinazione è lo stesso tipo di file; Voglio leggere e scrivere .pdf nella mia applicazione.
L'applicazione è in Python se questo fa la differenza.
Risposte:
L'implementazione di lettura e scrittura ha probabilmente un'alta probabilità di essere altamente coesa. Se uno cambiasse, lo stesso farebbe l'altro. L'alta coesione è una forte indicazione di una singola responsabilità e il principio della singola responsabilità ci dice che dovrebbero essere riuniti nella stessa classe. Se tali operazioni hanno una bassa coesione, è probabile che suddividerle migliora la manutenibilità.
Se, tuttavia, ci sono consumatori che leggono solo dati senza scrivere o scrivono solo senza leggere, ciò indica che dal punto di vista dell'interfaccia è necessario separare queste operazioni, come prescritto dal principio di segregazione dell'interfaccia. Ciò significa che i consumatori dovrebbero definire due interfacce da cui possono dipendere, mentre la Fileclasse implementerà entrambe le interfacce.
Quando si applica il principio SOLID per progettare un oggetto, è possibile considerare la lettura e la scrittura dei file come UNA sola responsabilità: lavorare con dati persistenti
Tuttavia, non dovresti mettere la lettura e la scrittura dei file nello stesso metodo o funzione.
La maggior parte delle altre risposte sembra aver trascurato il fatto che nella tua domanda manca un'informazione cruciale: non ci hai detto se e come sono correlati i documenti che stai per leggere e scrivere!
La tua applicazione ha qualcosa di simile a un "oggetto documento" e lo scrive prima in un file PDF, quindi legge nuovamente lo stesso file in un oggetto documento simile? O viceversa, legge i PDF in un documento, li modifica e salva di nuovo lo stesso documento in un nuovo PDF? Quindi leggere e scrivere dovrebbe essere visto come una responsabilità. Ciò può accadere se l'applicazione è o contiene qualcosa come un componente "editor PDF" o un "kit di strumenti di manipolazione PDF".
Tuttavia, se una parte dell'applicazione crea alcuni file PDF, ad esempio, in un componente di report e un'altra parte non correlata dell'applicazione legge PDF diversi (ad esempio un analizzatore di allegati di posta elettronica per un motore di ricerca) e la rappresentazione interna di questi ultimi PDF non hanno nulla in comune con il primo caso d'uso, quindi tali compiti hanno responsabilità diverse.
Soprattutto per il PDF, quel secondo caso d'uso è 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 hai intenzione di utilizzare una libreria per generare i file PDF e una completamente diversa per leggere i PDF, dovrebbe essere evidente che la lettura e la scrittura del PDF saranno responsabilità separate.
Secondo ( Robert C. Martin ) una responsabilità è un insieme di funzioni che serve un attore particolare.
Un attore dovrebbe essere l'unica fonte di cambiamento di una determinata responsabilità (ci dovrebbe essere solo una 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?
In tal caso, la lettura e la scrittura dei file sono due responsabilità distinte. Perché ci saranno più fonti di cambiamenti (molti attori potrebbero chiedere di cambiare la logica di lettura e la stessa cosa per la scrittura).