6

私は C++ の経験を積むために単純なゲームを書いていますが、ポリモーフィズムがほとんど機能するのに機能しないという考えがあります。このゲームでは、Partyは をかなり直線的に移動しますが、道路で にMap遭遇することがあります。Forkフォークは (基本的に)です。当初は、メンバー関数std::vector<location*>に次のようなコードを作成する予定でした。Party

if(!CurrLocation->fork_.empty())
   // Loop through forks and show options to the player, go where s/he wants
else
  (CurrLocation++)

しかし、次のいくつかの変形がより良いのではないかと思っていました:

CurrLocation = CurrLocation->getNext();

Fork は実際には Location から派生しており、いくつかの新しい function をオーバーロードしていますgetNext()。しかし後者の場合、location(低レベルの構造) は、「これをバックアップする」のではなく、ユーザーにメッセージを表示するものでなければなりませlocationんUserInterface::*。

あなたの意見は？

4

4 に答える 4

6

すべての問題は、間接的なレベルを追加することで解決できます。提案されたバリアントを使用し、getNext が方向の選択を解決するオブジェクトを受け入れられるようにすることで、Location を Party から分離します。以下に例を示します (未テスト):

class Location; 

class IDirectionChooser
{
public:
  virtual bool ShouldIGoThisWay(Location & way) = 0;
};

class Location
{
public:
  virtual Location * GetNext(IDirectionChooser & chooser)
  {
    return nextLocation;
  }

  virtual Describe();
private:
  Location * nextLocation;
};

class Fork : public Location
{
public:
  virtual Location * GetNext(IDirectionChooser & chooser)
  {
    for (int i = 0; i < locations.size(); i++)
      if (chooser.ShouldIGoThisWay(*locations[i]))
        return locations[i];
  }
  virtual Describe();
private:
  vector<Location *> locations;
};

class Party : public IDirectionChooser
{
public:
  void Move()
  {
    currentLocation = currentLocation->GetNext(GetDirectionChooser());
  }

  virtual IDirectionChooser & GetDirectionChooser() { return *this; }

  virtual bool ShouldIGoThisWay(Location & way)
  {
    way.Describe();
    cout << "Do you want to go that way? y/n" << endl;

    char ans;
    cin >> ans;
    return ans == 'y';
  }
};
于 2009-01-09T00:12:30.180 に答える
1

あなたは自分で問題を見つけたと思います。おそらく、システムの残りの部分についての知識、またはここで私たちが調べるためのいくつかの詳細を使用して問題を解決できるでしょう。

述べたように：

  1. ポリモーフィズムは、設計を単純化するために使用する必要があります。この場合は、ポリモーフィズムが非常によくわかります。
  2. カップリングに問題があります。これもよくわかります。カップリングは後で問題を引き起こす可能性があります。ただし、これが私に言うことは、ポリモーフィズムを適用する方法が最善の方法ではない可能性があるということです。
  3. インターフェイスにプログラミングすると、システムの組み立て方法の内部の詳細を非表示にして、結合を減らすことができます。
于 2009-01-08T22:10:41.110 に答える
1

ポリモーフィズムが理にかなっていて設計を簡素化する限り、ポリモーフィズムを使用する必要があります。存在し、派手な名前を持っているという理由だけで使用しないでください。設計が単純になる場合は、結合する価値があります。

正確さと単純さは、すべての設計決定の最終的な目標であるべきです。

于 2009-01-08T22:01:26.620 に答える
0

ポリモーフィズムは、より大きな結合には役立ちません。それらは別の問題だと思います。

実際、インターフェイスをプログラミングし、制御パターンの一般的な反転に従うと、結合が少なくなるかゼロになります。

あなたの例では、場所がUserInterfaceにどのように結合されているのかわかりませんか?

この場合、UserInterface と Location の間の別のレベルの抽象化 (LocationViewAdapter など) を介してカップリングを削除できますか?

于 2009-01-08T22:01:48.897 に答える