2009-06-30 15 views
0

私は、すべてのレスラーが互いと戦うレスリングゲームを開発したとします。デザインパターン - インターフェイス分離

だから私は、次のようなクラスとインタフェースを設計し:

public interface IWrestler 
{ 
    void Attack(); 
} 

public class Sumo : IWrestler 
{ 
    public Sumo() 
    { 
    } 

    public void Attack() 
    { 
     Console.Write("Sumo attacked the opponent..."); 
    } 
} 

public class Shaolin : IWrestler 
{ 
    //------ etc. 
} 

今年、私は力士が(以前に考えられていなかった)武器を運んでほしいです。

既に多数のクラスを作成しているとします。

この問題を解決するために、今どのようなデザインパターンを使用できますか?または、今この問題をどのように解決すればよいですか?

この問題を回避するために、最初に使用できるデザインパターンは何ですか?

答えて

4

私はこの問題のデザインパターンに深く関わっていないと思います。手元にある設計上の問題では、私は自発的に、武器を持っているレスラーはレスラーではなく、新しいインターフェースで表現されるべき戦士であると言うでしょう。 Sumoは棒で武装されている場合とコメントについて

public interface IWrestler 
{ 
    void Attack(); 
}  
public interface IWarrior : IWrestler 
{ 
    void WeaponedAttack(); 
} 
// let's assume that Sumo's don't carry weapons 
public class Sumo : IWrestler 
{ 
    public void Attack() 
    { 
     Console.Write("Sumo attacked the opponent..."); 
    } 
} 
//..but Shaolin do: 
public class Shaolin : IWarrior 
{ 
    public void Attack() 
    { 
     Console.Write("Shaolin attacked the opponent as a wrestler..."); 
    } 

    public void WeaponedAttack() 
    { 
     Console.Write("Shaolin attacked the opponent as a warrior..."); 
    } 
} 

:下位互換性のために、我々はまた、力士であることを、すべての戦士を必要とすることができ、私は棒でSumoも戦士と考えることができることを推測します。代わりにIWarriorを実装し、WeaponedAttackを使用してスティックで攻撃してください。スティックが防衛専用でない限り(ただし、インターフェースの一部ではないようですが、攻撃者が相手をどのように見ているのか、その逆のことはわかりません)。

IAttackerIDefenderのインターフェイスを持つ必要があります。ここにはIAttacker.Attack(IDefender)IDefender.BeingAttacked(IAttacker)があり、両方のクラスを実装していますか?そうすれば、誰が戦闘に勝つのかを決める何らかの仕組みが可能になります。 (ちょうどアイデアを投げて..)

+0

スムージングをスティックで行うにはどうすればいいですか? –

+0

@JMSA:あなたの質問を誤解し、回答を削除しました...代わりに更新された回答を参照してください。 –

+0

これに抽象クラスを組み込めますか? –

-1

この問題を回避するために最初に使用できるデザインパターンは何ですか?

Visitorをご覧ください。これらの構造を変更せずに既存のオブジェクト構造に新しい操作を追加することができます

2

にはどのようなデザインパターンを使用できますか?または、今すぐこの問題を解決するにはどうすればよいですか?

既に設計されたクラスの場合、この問題を解決するのに役立つAOP以外の静的言語で魔法のように適用できるデザインパターンはありません。 IWeaponのインターフェースと武器のリストへの参照をすべてのレスラーに追加する必要があります。

最初にこの問題を回避するにはどのようなデザインパターンを使用できますか?

このように自分を気にしないでください。あなたはクラスをうまく設計しました。変化のパターンを認識し、それをあなたのdesingでサポートすることは重要です。さもなければ、考えられる全ての事例を考えるのは時間の無駄でしょう。

0

私は、あなたが本当に相撲のクラスを始めるか、IWrestlerのインターフェースを望んでいるかどうかという質問をしています。

IWrestlerは、攻撃を解決したり、内部統計を調べたりするなど、数多くのことを担当しなければならないようです。この種のものは、Single Responsibility Principleに違反しています。

Iwrestlerには、完了するまでに多くの方法がありますが、そのうちのいくつかはお互いにほとんど関係がありません。それはあなたが泥の大玉に漂っている別の兆候です。

攻撃と防御がおそらく相互に関連しているということは、そこに隠れている別のクラス(またはそれ以上)が存在する可能性があることを示唆しています。

最後の示唆として、これはデータ構造ベースの観点からではなく、ユーザーとのやりとりの観点から考えてみる価値があります。ユーザー入力から最終的な結果までのデータの流れをモデリングすると、一目でわからない可能性のあるいくつかのデザインが示唆されることがあります。これは、古典的なデザインパターンの多くが実際に輝き始めるという見方をしたときです。

関連する問題