私は現在プロジェクトに取り組んでおり、デザインに何かが浮かびました。複数のフィールドで構成される Key という名前のクラスがあります。この Field クラスはマザー クラスであり、Age、Name などの子は Field を実装します。Key クラス内には、さまざまな種類のフィールドを保持するためのフィールドの配列である属性があります。
class Key {
private:
Field * fieldList;
}
私はチームに取り組んでいますが、次の問題への回答方法がわからなかったために防御できないという設計上の選択肢が出てきました...またはそれが欠けている可能性がありますか? これについてあなたが私の心を開いてくれると信じています。
この Key クラスの目的は、いくつかのフィールドを保持することです。このクラスがあるのは、こういうデータを扱うからです。
（名前と年齢....）
これは、すでに実装されているように見えると私が思った方法です:
Key myKey = Key();
Age newAge = Age(50);
myKey.add(newAge);
Key クラスの add メソッドのプロトタイプは次のようになります。
void Key::add(Field);
ご想像のとおり、Key クラスには Field の配列があるため、このメソッドは Field を受け取り、Age も Field であるため、継承の原因となるため、これは魅力的に機能します。Name クラスや、今後登場する可能性のある他のクラスについても同じことが言えます。
これは、データを含む行があり、列が属性に属しているデータベースと同じ考え方であるため、同じ列には同じタイプの属性があります。
また、フィールドの 1 つだけで 2 つのキーを比較したいと思います。たとえば、次のようになります。
このデータに2つのキーがあるとしましょう:
(ジョン、50) <- myKey1
(ポール、60) <- myKey2
これを行う私の方法は次のようになります。
myKey1.compareTo(myKey2, 2)
これは、最初の myKey1 の 2 番目の属性が 2 番目の myKey2 の属性よりも大きい、等しい、または小さい場合に答えます。
これには問題があります。add メソッドを使用すると、さまざまなタイプの Field をランダムに追加しました。たとえば、最初に Age、次に Name などを Key オブジェクトに追加しました。私の Key オブジェクトは、それらを出現順に内部配列に追加しました。したがって、compareTo メソッドを使用する場合、両方のオブジェクト内で、それらの配列の 2 番目の要素に Name フィールドと言う Field があることを保証するものは何もありません。年齢、内部にはフィールドの配列のみが保持されているため、キークラスが認識している限り、それらは同じ型です。
これが私の解決策への私のアプローチでしたが、私が答えられなかったのは、この問題を解決する方法です。
私のチームの別のメンバーは、既存の各フィールドのキー クラスのメソッドを実装することを提案しました。
myKey.addAge(newAge);
myKey.addName(newName);
その中にはまだ Field 配列がありますが、今回は、Age が配列の 1 番目の位置にあり、Name が配列の 2 番目の位置にあることをクラスが保証できます。これは、各メソッドがそれを確認するためです。 .
これに関する明らかな問題は、存在するフィールドのタイプごとにメソッドを追加する必要があることです。つまり、将来、「生年月日」を追加して新しい Date クラスを作成したい場合は、メソッド addDate などを追加する必要があるということです...私のチームメンバーが私に与えた別の理由それは、私のアプローチが悪かった理由を指摘するとき、「外部ユーザーがフィールドを順序どおりに追加することを信頼できない」ということです。
結論として：
最初のアプローチでは、Key クラスは Fields を追加したプログラマーに依存して、必要な順序になっていることを確認しますが、フィールドの種類ごとにメソッドを追加する必要がないという利点があります。
2 番目のアプローチでは、Key クラスは、存在する Field タイプごとにメソッドを実装することにより、順序が正しいことを確認しますが、作成された新しい Field のタイプごとに、クラスはどんどん大きくなります。
これで何かアイデアはありますか？これに対する回避策はありますか？
事前に感謝します。明確でない場合はお詫び申し上げます。必要に応じて新しい詳細を追加します。