問題タブ [open-closed-principle]

データ グリッドに一意の値を表示し、ユーザーがグリッド内の特定の列の一意の値をフィルターできるようにする汎用フィルター コントロールを構築しようとしています。

この質問に対して提案された回答は気に入りましたが、それらはすべて事前にプロパティを知る必要があります。コードをOCPに準拠させ、プロパティ名の文字列を取り、それに個別の機能を適用するメソッドを1つだけ持ちたいと思います(おそらくリフレクションを使用します)。私の列を考慮して、この問題の最良の解決策は何ですか（それにより、名前、年齢などのフィルタリングする列名は動的です）。

具体的には、次の switch case ステートメントを回避しようとしています。

次のような一般的なメソッドがあります。

参考までに - ViewModel の私のコレクションは ICollectionView 型です (私が探している種類のフィルタリングを行う CollectionView で既に定義されている同様のものがあると思います)。

次の関数は C で実装されています。

各ブランチにはさまざまな処理があり、Open-Closed Principle を満たしていません (p が指す構造体が安定していないため、新しいフィールドが頻繁に追加されます。つまり、新しいプロセス コードが関数に頻繁に追加されます) 。 ; OCP を満たすためにどのように変更できますか?

オブジェクトのタイプに基づいて、オブジェクトに対していくつかの操作 (db 永続化、json シリアル化など) を実行したいと考えています。ポリモーフィズムはこれを行うための通常の方法ですが、モデルにビジネス以外のロジックを多く追加したくありません。

これは単純な型階層です (これらは私のオリジナルの型ではありませんが、問題を示すために単純化したものです):

これらの書籍はクライアント側で JS オブジェクトとして作成され、JSON としてサーバーに送信され (構造を変更することはできません)、書籍のリストに解析されます。

次に、このリストをデータベースに保存します。

私は、SaveBooksToDatabase メソッドでのタイプのディスパッチに満足していません。これは、Open-Closed Principle に違反しており、新しいタイプを追加するときにあまり安全ではありません。

しかし、ブック階層に抽象的な Save() メソッドを追加したくありません。保存以外にも型に依存する操作 (json シリアル化など) があり、これは単一責任の原則に違反するからです。訪問者パターンが代替ソリューションと見なされる可能性があることは知っていますが、IMO では、より厄介なボイラープレート コードが導入されます。

そのような場合を処理するための最良かつ最もエレガントな方法は何ですか?

私は一連の型のコレクションを持っています。それらはすべて同じ基本クラスから派生し、それぞれを検索するための一連の述語があります。

各タイプの繰り返しを避けるためにこれを行う方法はありますか?

私の次のステップは、Dogs、Cats を共通の 'Result' タイプに変換し、これらのコレクションを返すことです。今後、より多くの種類の動物がきれいにスケーリングされます。

プロジェクトには、3 つのアクター (ユーザー、エキスパート、管理者) と 5 つの主要なユース ケース (CRUD: 作成、読み取り、更新、削除、同期) があります。ただし、各ユース ケースへのユーザーのアクセスは他のアクターとは異なります。たとえば、ユーザーは 1 つのエンティティを作成できますが、専門家と管理者は任意の数を作成できます。他のユース ケースでは次のようになります。

また、アクターは同じ UI を使用します。そのため、実行時に現在のアクターに関してアクションを有効または無効にすることを決定する必要があります。それを行うのは簡単に思えますが、私は良いデザインが好きです。特に、ユースケース、アクターの数そして、それらのアクセス権レベルは後で変更される可能性があります。したがって、 OCP の原則を尊重する必要があります。しかし、ユース ケースとアクターのアクセス権レベルを管理するための適切な設計をどのように行うことができますか?