Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm just starting to explore SOLID and I'm unsure if reading from files and writing to files are the same responsibility.
The target is the same file type; I want to read and write .pdf's in my application.
The application is in Python if that makes any difference.
The reading and writing implementation likely have a high probability of being highly cohesive. If one would change, so would the other. High cohesion is a strong indication of a Single Responsibility and the Single Responsibility Principle tells us that they should be put together in the same class. If those operations have a low cohesion, chances are that splitting them improves maintainability.
If, however, there are consumers that only read data without writing, or only write without reading, it is a indication that from an interface perspective you should separate these operations, as prescribed by the Interface Segregation Principle. This means that the consumers should define two interfaces that they can depend on, while the File class will implement both interfaces.
When you apply SOLID principle to design an object, you can consider file reading and writing as ONE responsibility - work with persistent data
However, you should not put file reading and writing in the same method or function.
Most of the other answers seem to have overlooked that in your question one crucial piece of information is missing - you did not tell us if and how the documents you are going to read and write are related!
Is your application having something like a "document object" and writes that into a PDF file first, and then later reads the same file again into a similar document object? Or vice versa, it reads PDFs into a document, makes some modifications to it and saves that same document into a new PDF again? Then reading and writing should be seen as one responsibility. That may be the case if your application is or contains something like a "PDF editor" component, or a "PDF manipulation toolkit".
However, if one part of your application creates some PDF files, for example, in a reporting component, and another unrelated part of your application reads different PDFs (for example, a mail attachment evaluator for a search engine), and the internal representation of those latter PDFs has nothing in common with the first use case, then those tasks are different responsibilities.
Especially for PDF, that second use case is the case which I have seen much more often in different kind of applications. There are much more libraries / components out there which just support PDF creation, and only a much smaller number which support also PDF reading. If you are going to use a one library for generating the PDF files, and a completely different one to read the PDFs, then it should be evident that PDF reading and writing will be separate responsibilities.
According to (Robert C. Martin) a responsibility is a set of functions that serves one particular actor.
An actor should be the only source of change of a given responsability (there should be only one reason to change).
In your case you should first define the actors as a first step, then ask the questions : . Are there actors that are interested only by reading files and other by writing ?
If it is the case then reading and writing files are two separate responsibilities. Because there will be multiple sources of changes (many actors may ask to change the reading logic and same thing for writing).
