3

ベストプラクティスでは、新しいメソッドを保護対象として設定し、代わりに静的なnew ...メソッドを使用して、メソッドのオーバーロードの不足を軽減することをお勧めします。だから私はここで
説明されているようにこのパターンを使用します

ただし、静的メソッドは継承されません。したがって、サブクラスごとに静的構造と静的new...メソッドを定義する必要があります。
したがって、継承のメリットの一部が失われます。

より良い解決策を見つけることを期待してシステムクラスを調べましたが、実際には役に立ちませんでした：
-静的な新しいパターンを尊重し、サブクラスのメソッドを宣言するものもあります-
保護せずに新しいインスタンスを使用するものもあります
-いくつかSalesFormLetterのように、マザークラスを「クラスファクトリ」として使用します

static SalesFormLetter  construct(DocumentStatus    document,
                                  boolean           getParmId = true)
    {
    switch(document)
    {
        case DocumentStatus::Confirmation       :   return new SalesFormLetter_Confirm           (getParmId);
        case DocumentStatus::PickingList        :   return SalesFormLetter_PickingList::construct(getParmId);
        case DocumentStatus::PackingSlip        :   return new SalesFormLetter_PackingSlip       (getParmId);
        case DocumentStatus::ProjectPackingSlip :   return new SalesFormLetter_PackingSlipProject(getParmId);
        case DocumentStatus::Invoice            :   return new SalesFormLetter_Invoice           (getParmId);
        case DocumentStatus::ProjectInvoice     :   return new SalesFormLetter_InvoiceProject    (getParmId);

        default : throw error(strfmt("@SYS19306",funcname()));
    }

    throw error(strfmt("@SYS19306",funcname()));
}

それで、私はより良い解決策があるかどうか疑問に思っています、そしてそうでなければ、これらの中で何が最善でしょうか？

4

1 に答える 1

3

オブジェクト構築のより良い解決策は？

まあ、どこかに行かなければならず、クライアントコードにnew多くを入れることは壊れやすく柔軟性がありません。newしたがって、特に関連するクラスについては、クラス「ファクトリ」を使用してください。

2つのオプション：

  1. 保護しnewます。サブクラスごとにコンストラクトを作成し、サブクラスコンストラクターを呼び出す基本クラスにファクトリコンストラクトを配置します。しかし、誰でもサブクラスの構築メソッドを呼び出すことができます。

  2. 公開しnewます。サブクラスごとに構成を作成せず、ファクトリを基本クラスに配置し、サブクラスを新しくします。基本クラスはサブクラスの子孫ではないため、新しいものを保護することはできません。

1または2を選択するかどうかに関係なく、最終的にサブクラスコンストラクターを公開することになります。個人的には、オプション2の方が面倒が少ないので、好みです。

アドバイス：への引数を使用して、オブジェクトの依存関係を明示的にしてくださいnew。これは工場を複雑にしますが、クライアントコードから複雑さを取り除くので問題ありません。セッターメソッド（parmメソッド）は悪RunBaseですが、バッチシステムで必要とされるために必要です。

また、ボブおじさんが書いているものを見に行きます。

于 2012-07-12T10:44:46.133 に答える