0

すべてのパブリック メソッドはビジネス ロジックに対応する必要がありますか?

  • はいの場合、2 つのオブジェクトが下位の設計レイヤーで通信する必要があり、ビジネス以外のメソッドを公開する必要がある状況にどのように対処すればよいですか? (または、これはアンチパターンですか?)
  • いいえの場合、パブリック メソッドとビジネス パブリック メソッドを明確に区別する方法は?

これらは私が知っているオプションです：

  • ビジネス ロジック インターフェイスを作成する (Attila と ArjunShankar が提案するように)
  • #define BUSINESS（C ++で）そしてasを使用しますBUSINESS void myMethod()-それが良い考えかどうかはわかりません

他の可能性はありますか？

4

3 に答える 3

2

public単に、クラス外のコードがメンバーにアクセスできる (if メソッドを呼び出すなど) ことを意味し、ビジネス ロジックとは関係ありません。

オブジェクトのインターフェイスを、それを使用しているコードに制限する必要がある場合は、必要なメソッドのみをリストするインターフェイスをクラスに実装させ、そのインターフェイスを介してオブジェクトを渡すことができます (つまり、メソッド パラメーターの型はインターフェイスです)。オブジェクトで動作しているコードは、目的のメソッドにのみアクセスできます

于 2012-05-21T10:50:09.147 に答える
1

言語がインターフェースをサポートしている場合は、それを使用して、コンテキストに基づいて異なる動作を公開することができます（言語が多重継承をサポートしている場合は、それを使用してください）。

Interface Kickable /* For 'business logic'.  */
  method kick (Direction)
  method dribble (Technique)

Interface PhysicsObject /* For collaboration with other objects.  */
  method collide_with (PhysicsObject)
  method fall (gravity)

Class Football Implements <Kickable, PhysicsObject>

誰も彼らがすべきではないメソッドを見ることができないので、これはかなりきれいです：

Football football = new Football ();
/* Let the physics engine deal with PhysicsObjects.  */
physics_engine.add (PhysicsObject (football));

/* Let players deal with it Kickables.  */
game.set_ball (Kickable (football));
于 2012-05-21T11:03:13.897 に答える
0

どのメソッドが外部で使用され、どのメソッドが使用されるべきでないかを知ることは本当に可能ですか? 私の経験では、クラス間の内部通信に使用されるメソッドは、後でユーザーからの要件が変更されると、予期しない方法で使用されることがよくあります。そのため、クラスのすべてのパブリック メソッドの動作を検証するために、まず適切な単体テストを作成することをお勧めします。

そうは言っても、C++には目標を達成するためのイディオム、pimplイディオムがあります。なぜ「PIMPL」イディオムを使用する必要があるのですか?

于 2012-05-21T11:32:19.253 に答える