遵循SOLID时，读写文件是两个单独的职责吗？

我只是开始探索SOLID，而且不确定从文件读取和写入文件是否是同样的责任。

目标是相同的文件类型；我想在我的应用程序中读写.pdf。

如果有任何不同，该应用程序将使用Python。

读写实现很可能具有高度凝聚力。如果一个改变，另一个也会改变。高度凝聚力是单一责任的有力证明，而单一责任原则告诉我们，应该将它们放在同一个类别中。如果这些操作的内聚性较低，则将它们分开可以改善可维护性。

但是，如果有些使用者仅读取数据而不写入数据，或者仅写入数据而不读取数据，则表明从接口角度看，您应该按照接口隔离原则的规定将这些操作分开。这意味着使用者应定义他们可以依赖的两个接口，而File该类将实现这两​​个接口。

当您将SOLID原理应用于对象设计时，可以将文件读写视为一项责任-使用持久性数据

但是，不应将文件读取和写入置于相同的方法或函数中。

其他大多数答案似乎都忽略了您的问题中缺少一条至关重要的信息-您没有告诉我们您将要阅读和编写的文档是否以及如何关联！

您的应用程序是否具有类似“文档对象”的内容，并先将其写入PDF文件，然后再将同一文件读入类似的文档对象中？反之亦然，它会将PDF读取到文档中，对其进行一些修改，然后将同一文档再次保存为新的PDF？那么阅读和写作应该被视为一种责任。如果您的应用程序是或包含“ PDF编辑器”组件或“ PDF操作工具包”之类的东西，可能就是这种情况。

但是，如果您的应用程序的一部分（例如，在报告组件中）创建了一些PDF文件，而您应用程序的另一不相关的部分则读取了不同的PDF（例如，搜索引擎的邮件附件评估程序），以及后面的PDF与第一个用例没有共同之处，那么这些任务是不同的职责。

特别是对于PDF，第二种用例是我在不同类型的应用程序中经常看到的用例。那里有更多的库/组件仅支持PDF创建，只有很少的库/组件也支持PDF阅读。如果您要使用一个库来生成PDF文件，而要使用一个完全不同的库来读取PDF，那么显然PDF的读写是单独的责任。

根据罗伯特·C·马丁（Robert C. Martin）的说法，责任是为一个特定演员服务的一系列功能。

行为者应该是特定职责改变的唯一来源（应该只有一个改变的理由）。

在您的情况下，首先应定义参与者，然后提出以下问题：。是否有仅通过读取文件和通过编写其他文件而感兴趣的演员？

在这种情况下，读写文件是两个单独的职责。因为会有多种更改源（许多演员可能会要求更改阅读逻辑和相同的写作内容）。