1

設計上の問題が発生しました。おそらく、決定を手伝ってくれるでしょう。

私のクライアント オブジェクトは、クラスのオブジェクトのセットを要求できますReport。利用可能なレポートのセットが定義されており、クライアントの許可に従って、返されるセットにさまざまなレポートを含めることができます。レポートは要求ごとに作成されます (すべてのクライアントは要求ごとに新しいレポート インスタンスを取得します)。

以下のように、レポートの作成をカプセル化する一種の「ファクトリー」を使用する必要があります。

public class ReportsFactory {

    private UserPermissionsChecker permissionsChecker;

    public Set<Report> createReports() {
        Set<Report> reports = new HashSet<Report>();
        if(permissionsChecker.hasAccessTo('report A')) {
            reports.add(createReportA());
        }
        if(permissionsChecker.hasAccessTo('report B')) {
            reports.add(createReportB());
        }
        if(permissionsChecker.hasAccessTo('report C')) {
            reports.add(createReportC());
        }
        return reports;
    }

    private Report createReportA() {...}
    private Report createReportB() {...}
    private Report createReportC() {...}
}

これは、いわゆる単純な Factory パターンの正しい使用法ですか? または、他の提案はありますか？

** 編集 **

以下のいくつかのコメントは、それは正確には Factory パターンではないと言っています。そうでない場合、どうすればそれを呼び出すことができますか?

4

2 に答える 2

1

設計は正しいと思いますが、これは「工場」という言葉の間違った使い方です。Factory パターンでは、XxxxFactoryのインスタンスを作成Xxxxし、必要に応じて初期化しますが、他の種類のロジックは適用しません。

ここでのこの設計は私には正しいように思えますが、あなたのクラスはむしろ呼び出されますReportsService

そして多分そうなるでしょUserPermissionsCheckerうAuthorizationService

編集：「サービス」という言葉に対する批判を考慮に入れる。

現在、Java の世界では非常に広く (私は普遍的とは言いませんでした) 慣習があり、それは次のようなものです。

  • (おそらく誤って) POJO と呼ばれるすべてのロジックを空にしたクラスによって実装される、純粋に記述的なビジネスモデル
  • すべてのビジネス ロジックは、主に、XxxService というクラスのメソッドに手続き型で実装されたオブジェクト Xxx に関連しています。

私は個人的にこのコーディング スタイルに同意せず、オブジェクト指向プログラミングを好みますが、好むと好まざるとにかかわらず、この規則は Java EE の世界に存在し、一貫性があります。

OP によって提出されたクラスのコーディング スタイルから判断して、私は彼がこの手続き型アプローチに従っていると推測しました。そのような状況では、既存の規則に従い、Reports を ReportService で処理する手続き型コードのコンテナーとして機能するクラスを呼び出す方が適切です。

于 2012-11-09T15:08:58.567 に答える
0

私には、これは少しビルダーパターンのように見えます。ある意味で、オブジェクトを持っていて、そのデータを構築するためのものです。
これは、通常、作成されたオブジェクトのさまざまな具体的なタイプを返すファクトリとは対照的です。
通常、これらのオブジェクトのデータの構築は、それらのオブジェクトがファクトリから返される具体的なクラスの CTOR で行われます。

于 2012-11-10T14:18:19.537 に答える