1

このデザインの使い方はこちら

外部世界がユーザーとそのサービスを構成できるように、いくつかの API を公開する必要があります。ユーザーの構成には、主に、入力パラメーター (ID、パスワード、レベルなど) に基づく新しいユーザーの作成と、新しい接続オブジェクトの作成が含まれます。ユーザー オブジェクトが作成されたら、サービスの構成が必要です。これは、サービスの有効化、サービスの詳細の変更という 2 段階のプロセスです。サービスの詳細の変更は、一連のアクションで構成されています。これらのアクションは、そのサービスのみに固有です。これらのアクションは、他のサービスでは異なります。

これが私の現在の実装です

ユーザー クラスは、service_manager、connection、group クラスで構成されます。service_manager クラスは一連のサービスを管理します (ServiceA、ServiceB ... ServiceN など)。サービスごとに個別のクラスがあります。

ユーザー クラスには public 関数 assignService があります。この関数は、サービス クラスを識別するために必要な引数を取ります。それぞれのサービス クラスのオブジェクトを返します。これは同じ擬似コードです。

serviceObjectA = user.assignService ('A');

後で、このサービス オブジェクトを使用して、そのサービスに固有のアクションを実行できます。

serviceObjectA.performActionA1(...);
serviceObjectA.performActionA2(...);
serviceObjectA.performActionA10(...);

これが問題です。私はこの実装に直面しています:

a) performAction 関数は、ユーザー クラス (ID、パスワード、場所など) と接続オブジェクトの属性をほとんど必要としません。これらのユーザー属性は、リクエストを準備するために必要です。接続オブジェクトは、作成済みの接続を介してこの要求を送信するために必要です。現在、サービスクラスのコンストラクターで管理しています。ここでは、これらのユーザー属性と接続オブジェクトをコンストラクターの引数として渡しています。さまざまなサービス クラスがさまざまなユーザー属性を必要とするため、管理が少し難しくなっています。

これに代わるものを提案してください。

b) サービスオブジェクトを外部に公開することは本当に良い習慣ですか?

私はまだ OOP の世界に慣れていないので、間違って理解していたら申し訳ありません。疑似的な例でそれを示していただけると本当に助かります。

4

1 に答える 1

2

問題のいくつかを解決する 1 つの方法は、ビルダー パターンに従うことです。

したがって、これらのさまざまなオプションのすべてに適合するように、より多くのパラメーターとコンストラクターを含めるという規則は使用しません。コンストラクターで必要なすべてのオプションを要求する代わりに、必要なすべてのオプションを設定してから、適切に設定されたクラスをビルド (インスタンスを返す) できる "ビルダー" クラスを用意します。

これは、パブリック コンストラクターを持たず、静的ファクトリ メソッドを使用する別のオプションに似ています。これらは、コンストラクターを区別するのが難しくなり、パラメーターが制御不能になっている場合に役立ちます。静的ファクトリ メソッドを持つということは、メソッド名をより説明的にすることができ、あいまいさと複雑さを回避できることを意味します。効果的な Java には、これに関連するいくつかのトピックがあり、優れた設計パターンの詳細な議論を読むのに適しています。

デザインとその使用について詳しく知らないため、何を公開すべきで、何を公開すべきでないかを判断するのは困難です。アクションがさまざまなサービスによって実行されるという事実を隠して、クラスのユーザーに「ユーザー」のみと対話させる方がよいように思えます。これにより、複雑さが少し低く保たれ、必要に応じて後で実装を変更できます。

于 2012-07-31T18:30:18.630 に答える