SOLIDを探索し始めたばかりです。ファイルからの読み取りとファイルへの書き込みが同じ責任であるかどうかはわかりません。
ターゲットは同じファイルタイプです。アプリケーションで.pdfを読み書きしたい。
アプリケーションは、Python=にあります。
読み取りと書き込みの実装は、非常にまとまりがある可能性が高いです。一方が変わると、もう一方も変わる。高い凝集性は単一の責任を強く示しており、単一の責任の原則は、それらを同じクラスにまとめる必要があることを示しています。これらの操作の凝集度が低い場合、それらを分割することで保守性が向上する可能性があります。
ただし、書き込みなしでデータの読み取りのみ、または読み取りなしの書き込みのみを行うコンシューマーがある場合、インターフェース分離の原則で規定されているように、インターフェースの観点からこれらの操作を分離する必要があることを示しています。つまり、File
クラスは両方のインターフェースを実装しますが、コンシューマーは依存できる2つのインターフェースを定義する必要があります。
SOLID原則を適用してオブジェクトを設計する場合、ファイルの読み取りと書き込みを1つの責任と見なすことができます-永続データを操作します
ただし、ファイルの読み取りと書き込みを同じメソッドまたは関数で行うことはできません。
他の回答のほとんどは、あなたの質問で重要な情報が欠落していることを見落としているようです-読み書きしようとしているドキュメントが関連しているかどうか、またどのように関連しているかを教えてくれませんでした!
アプリケーションに「ドキュメントオブジェクト」のようなものがあり、それをPDFファイルに最初に書き込み、次に同じファイルを同様のドキュメントオブジェクトに再度読み取りますか?またはその逆で、PDFを読み取りますドキュメントにいくつかの変更を加え、同じドキュメントを新しいPDFに再度保存しますか?それから、読み取りと書き込みは1つの責任として見なされます。アプリケーションがまたは「PDFエディター」コンポーネントや「PDF操作ツールキット」などが含まれています。
ただし、アプリケーションの一部がPDFファイルをレポートコンポーネントなどに作成し、アプリケーションの別の無関係な部分が別のPDFを読み取る場合(たとえば、検索エンジン)、そしてこれらの後者のPDFの内部表現は最初の使用例と共通点がなく、それらのタスクは異なる責任を負います。
特にPDFの場合、その2番目の使用例は、さまざまな種類のアプリケーションで私がより頻繁に目にしたケースです。 PDFの作成をサポートするライブラリ/コンポーネントがはるかに多く、PDFの読み取りをサポートするはるかに少ない数のみです。 PDFファイルを生成するために1つのライブラリを使用し、PDFを読み取るために完全に異なるライブラリを使用する場合、PDFの読み取りと書き込みは別の責任。
(Robert C. Martin)によると、責任は特定の1人の俳優に仕える一連の機能です。
アクターは、特定の責任を変更する唯一のソースでなければなりません(変更する理由は1つだけです)。
あなたのケースでは、最初にアクターを最初のステップとして定義し、次に質問をする必要があります。ファイルを読んだり、他のことを書いたりするだけで興味を持つ俳優はいますか?
その場合、ファイルの読み取りと書き込みは2つの別々の責任です。なぜなら、変更には複数のソースがあるからです(多くのアクターは、読み取りロジックを変更するように要求し、書き込みについても同じことを要求する場合があります)。