هو تعدد الأشكال يستحق زيادة في اقتران?

Question

أنا أكتب اللعبة الساذجة لتعلم الحصول على المزيد من 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();

مع شوكة يجري في الواقع مستمدة من موقع ، إثقال بعض وظيفة جديدة getNext().ولكن في الحالة الأخيرة ، location (تدني مستوى الهيكل) يجب أن يكون واحد لتقديم الرسالة إلى المستخدم بدلا من "تمرير هذه العودة" التي لا يشعر أنيقة كما الأزواج location إلى UserInterface::*.

آرائكم?

Answer 1

ويمكن أن تحل جميع المشاكل عن طريق إضافة مستوى المراوغة. وأود أن استخدام الخاص بك البديل المقترح، وفصل الدولة عن الحزب من خلال السماح getNext لقبول كائن الذي يحل الخيارات الاتجاه. هنا مثال (غير مجربة):

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';
  }
};

Answer 2

ويجب عليك استخدام تعدد الأشكال طالما أنه من المنطقي ويبسط التصميم الخاص بك. يجب عدم استخدام ذلك لمجرد أنها موجودة ولها اسم يتوهم. إذا كان لا تجعل التصميم الخاص بك أسهل، ثم انه يستحق اقتران.

والصواب والبساطة يجب أن يكون الهدف النهائي من كل قرار تصميم.

Answer 3

أعتقد أنك رصدت قضايا نفسك و ربما يمكن العمل بها مع معرفة بقية النظام أو بعض مزيد من التفاصيل هنا بالنسبة لنا أن ننظر إلى.

كما ذكر:

1. تعدد الأشكال ينبغي أن تستخدم لتبسيط التصميم الذي سوف تفعل في هذه الحالة ، لذلك جيدا رصدت.
2. لديك مشكلة مع اقتران - مرة أخرى رصدت اقتران يمكن أن يؤدي إلى مشاكل في وقت لاحق.ومع ذلك ، ما هذا يقول لي هو أن الطريقة التي كنت تطبيق تعدد الأشكال قد لا يكون أفضل وسيلة.
3. برمجة الواجهات يجب أن تسمح لك لإخفاء الداخلية تفاصيل النظام هو وضع معا وبالتالي الحد من اقتران.

Answer 4

وتعدد الأشكال لا تقرض أكبر اقتران، أعتقد أنها قضايا منفصلة.

في الواقع إذا كنت البرمجة إلى واجهات وبعد انقلاب عام لأنماط السيطرة فإنك سوف تؤدي إلى أقل أو الصفر اقتران.

في كنت سبيل المثال، وأنا لا أرى كيف يقترن الموقع لUserInterface؟

وإذا كان هذا هو الحال، يمكن إزالة اقتران من خلال مستوى آخر من التجريد بين UserInterface والمكان، مثل LocationViewAdapter؟