私はSOLIDの原則に従って設計するように一生懸命努力しています。私が見つけたのは、「単一責任の原則」（SOLIDのS）を使用する場合、通常、データコンテナとデータプロセッサの間でクラスを分割する必要があるということです。たとえば、すべてをクラス内に配置するのではなく、DBから読み取られる5つのプロパティを持つクラスpersonがある場合、プロパティを持つPersonクラスと、データベースからその情報を読み取ってPersonを作成する別のPersonReaderクラスを作成します。
その場合、PersonReaderがアクセスできるように、Personプロパティを開く必要がありますが、すべてをブラックボックスに入れてプロパティを読み取り可能にするよりも、カプセル化が少なくなります。
私は何かが足りないのですか、それともこれはこの原則の欠点ですか？
前もって感謝します
編集：最初にプロパティセッターを公開する必要がなかったので、私はパーソンライターをパーソンリーダーに変更しました。
何かが足りないかもしれませんが、すべてのプロパティを受け入れるPersonクラスのコンストラクターを作成してみませんか？このようにして、PersonReaderは、個人のプロパティを開かなくても個人を作成できます。
別のオプションは、個人のプロパティのセッターを内部としてマークすることです（別のアセンブリにある場合は、アセンブリの内部をPersonReaderのアセンブリから見えるようにします）。これにより、人物のプロパティにアクセスできるようになりますが、アセンブリの外部で誰もがそれらを変更することはできなくなります。
ほとんどのデータアクセス戦略（ORM手法）には、説明している種類の妥協が含まれます。最も邪魔にならないものは、必要なときに（たとえば、パブリックセッターが存在しない場合）、リフレクション（またはイントロスペクションなど）を使用してエンティティにデータを入力します。
そうは言っても、エンティティが（アネミックドメインモデルのように）データコンテナのみである場合、オブジェクトには台無しになる（または干渉する）複雑なロジックがないため、単一責任の原則はそれほど重要ではありません。 ）データアクセスコード。
私はあなたが時々この問題に遭遇することをあなたに間違いなく同意します。ORMに似たシリアル化でそれを経験しました。私の場合、オブジェクトの状態を（バイナリ）ファイルに書き込む必要がありました。
場合によっては、内部状態を読み書きできるインターフェイスを作成することが適切な場合があります。したがって、あなたの人のクラスは、「保存」と「ロード」（または「書き込み」と「読み取り」またはあなたが適切だと思うもの）の2つの方法を取得します。これらのメソッドには、それぞれ「IPropertyWriter」と「IPropertyReader」が渡されます。（私の場合、それらをInStreamおよびOutStreamと呼びました）。
Person :: save（IPropertyWriter writer）は、
writer.writeProperty("name", this.name);
writer.writeProperty("age", this.age);
あなたはまだ単一責任の原則に違反していると主張することができますが、私は他の誰も人の内部を知っているべきではないと主張します。（特にシリアル化の場合、ゲッターから部分的にアクセスできない内部状態を保存する必要がありました）。重要な点は、Personはどのデータベースコードにも結合されていないということです。IPropertyWriterはすべてにすることができます。さらに、「自分の特性を知る」責任は、実際には新しい特性ではなく、とにかくすべてのオブジェクトに付随しています。
また、人が変わる可能性がどの程度あるかという質問をすることもできます。可能性が非常に低い場合friendは、C ++のようなクラスが良い方法だと思いますが、変更される可能性がある場合は、プロパティが宣言されている場所にシリアル化メソッドを配置して、依存関係を更新することを忘れないでください。コード。
あなたはあまりにもきめ細かく考えています。特定のクラスがデータベースを読み取る必要がありますが、Personを作成することが唯一の仕事であるクラスは必要ありません。それは無駄です。単一のデータベースリーダーは、データベースを介して取得する任意のクラスを作成できる必要があります-それが仕事だからです。データベースから読み取る。
Personのプロパティを開いて、DatabaseReaderがそれらにアクセスできるようにすることで、カプセル化の問題は発生しません。Personは、作成できるクラスがない場合は冗長であるためです。作成可能で破壊可能であることがクラスの責任の本質的な部分です。