問題タブ [creation-pattern]

4 つの文字列フィールドと 3 つのブール フィールドを持つ Item オブジェクトがあります。3 つのブール変数に基づいてこのオブジェクトを構築する必要があります。目標は、ブール変数のいずれかが真である場合はいつでも、その/それらのブール変数が設定されたオブジェクトを作成する必要があることです。いずれのブール変数も true でない場合は、オブジェクトを作成しません。COR を使用して、ビジネス ロジックに基づいてブール フィールドが設定されるかどうかを確認しています。私はビルダーでこれを試みていましたが、非常に多くのオブジェクトを構築し、後でブール変数が真ではない場合にそれらを破棄する必要があります。

この種の問題を解決するためのより良いアイデアはありますか?

この質問の2つの削除フラグをありがとう。この質問についても考えていただきありがとうございます。私は自分が望むものを達成するために何かをしました。これは非常に柔軟だと思います。If ループに依存する部分のみですが、Report クラスには追加のブール値を含めることができるため、それは許容されます。したがって、そのクラスが変更された場合は、その変更に対応するためにビルダーを変更する必要があります。これは私が欲しかった柔軟性です。公開クラス レポート {

オブジェクトを作成するかどうかを決定する calculateInconsitencyReport() メソッド。

ヘルパー インターフェイス:

セキュリティ上の理由から、クラス ロジックの詳細は切り離されています。

クライアントは、基本クラス (Java コード) を介してそれらを使用します。

createNewConcreteFeatureマップから requiredFeature 値のみを取得し、インスタンスを返します。これは、派生クラスで静的になるメソッドのように見えますが、クライアントは既存のオブジェクトで派生クラスのインスタンスを作成できません。これを書くよりエレガントな方法はありますか？または、これには適用可能なパターンがありますか？

次のインターフェイスを検討してください (まだ C++98 を使用しているため、ダム ポインターが使用されます)。

次の可能性のある実装で

Widget は仮想デストラクタを持つ基本クラスであり、SpecificWidget はそれを拡張します。私の同僚は、WidgetMaker インターフェイスに次のメソッドを含める必要があると主張しています。

根拠は、このように makeWidget 実装に標準の新しい割り当てを使用することを強制しないことです。カスタム プール アロケータを使用するか、ウィジェットがステートレスなどの場合に常に同じグローバル インスタンスを返すことができます。

このような設計は一般的に悪い考えだと思います。クライアント コードを複雑にし、KISS と YAGNI に違反し、unique_ptr への移行を (今後 20 年間で私たちの組織ではありそうもないことですが) 困難にします。自分の気持ちを信じるべきですか？抽象ファクトリ インターフェイスの一部としてのフリー メソッドが正当化されるのはどのような場合ですか?

テスト中に使用されるエンティティ ビルダーの基本的な実装を提供する汎用 (抽象) ビルダーを作成しました。

これはエンティティ基本クラスです:

これはIKey インターフェイスです:

これはBuilder クラスです:

これはサンプルのUnitBuilder実装です。

そして、これは私が抱えている問題です:

エラー：

エラー CS1061 'Builder' には 'WithShort' の定義が含まれておらず、タイプ 'Builder' の最初の引数を受け入れる拡張メソッド 'WithShort' が見つかりませんでした (using ディレクティブまたはアセンブリ参照がありませんか?)

何が起こっているかは理解していますが、よりも優れた (よりエレガントな) ソリューションが必要thirdUnitです。

アップデート：

提案に従って、UnitBuilderクラスに以下を追加しました。

しかし、今では基本クラスに何のポイントも見当たりません... これは、一般的な一般的な基本クラスの問題でなければなりません。他の人はこれをどのように処理しますか? 多分thirdUnit解決策はエレガントですが、私はそれについて難しいですか？:)

私のプログラムには 2 つのクラスがあります。どちらも同じ基本クラスから派生します。

InitValコンストラクターを介して注入される別のクラスです。このクラスは内部使用用です。内部コンストラクターのため、ユーザーはクラスのインスタンスを直接作成できませAんB。代わりに、これらのオブジェクトを作成するメソッドを作成しました。

ObjectInstance上記のコードの列挙型です。

これは問題なく動作しますが、これほど醜いコードを見たことがないはずです。

使用すべき作成パターンを提案してください。ObjectInstance機能を変更せずに列挙型を削除したい。大掃除になります。

dotfactoryに記載されているCreational Patternsを試しました。 この場合、適切に見えません。Factory MethodAbstract Factory

私のコードは醜く見えますが、読んで理解するのはとても簡単です。コードの複雑さを増す上記のパターンを実装してみました。したがって、これは回答を選択する際の私の基準でもあります。

Initiatorクラス以外のコードを変更することはできません。他のすべてのクラスには、編集のためにアクセスできません。

編集 1: 上記のコードが私の見解では醜い理由

1) メソッドの呼び出し中CreateObjectに、ユーザーはオブジェクトのタイプを 2 回指定する必要があります。

最初はTジェネリック値、2 番目は列挙値です。これは避けたい。

2) ユーザーはオブジェクトのタイプを 2 回指定する必要があるため、間違える可能性があります。

上記のコードでは、列挙値とジェネリック値が異なります。これは許可されておらず、問題になります。私のコードでは、これを避けることはできません。

それが理由です; 複雑さを増すことなく、自分のケースに合ったパターンを探しています。

どうにかして enum の必要性を取り除けば、コードはずっと良くなります。の署名を次のように変更できればCreateObject、ずっと良くなります。

しかし、このメソッドを実装して適切なインスタンスを作成する方法がわかりません。

今月のフレーバーが、switch ステートメントと列挙型を使用して作成する具体的なクラス インスタンスを決定しているように見えるプロジェクトに取り組んでいます。

それらはすべて同じインターフェースを実装しているが、インスタンスの作成時に異なるオブジェクトパラメーターを必要とすることを考慮して、オブジェクトの作成を検討できる代替設計パターンはありますか?

たとえば、現在のコードは .