Шаблон дизайну для поліморфної поведінки, дозволяючи розділити бібліотеку

Скажімо , у мене є ієрархія Itemкласів: Rectangle, Circle, Triangle. Я хочу вміти їх малювати, тому моя перша можливість - додати віртуальний Draw()метод до кожного:

class Item {
public:
   virtual ~Item();
   virtual void Draw() =0; 
};

Однак я хочу розділити функцію малювання на окрему бібліотеку Draw, тоді як основна бібліотека містить лише основні подання. Є кілька можливостей, про які я можу придумати:

1 - Таблиця, DrawManagerяка містить список Items і повинна використовувати, dynamic_cast<>щоб розробити, що робити:

class DrawManager {
  void draw(ItemList& items) {
    FOREACH(Item* item, items) {
       if (dynamic_cast<Rectangle*>(item)) {
          drawRectangle();
       } else if (dynamic_cast<Circle*>(item)) {
          drawCircle();
       } ....
    }
  }
};

Це не ідеально, оскільки він покладається на RTTI і змушує одного класу бути обізнаним про всі предмети в ієрархії.

2 - Інший підхід полягає у відкладанні відповідальності за ItemDrawerієрархію ( RectangleDrawerтощо):

class Item {
   virtual Drawer* GetDrawer() =0;
}

class Rectangle : public Item {
public:
   virtual Drawer* GetDrawer() {return new RectangleDrawer(this); }
}

Цим досягається розділення проблем між базовим поданням Елементів і кодом для малювання. Однак проблема полягає в тому, що класи Item залежать від класів малювання.

Як я можу відокремити цей малюнковий код в окрему бібліотеку? Чи рішення для елементів повернути заводський клас деякого опису? Однак як це можна визначити, щоб бібліотека Core не залежала від бібліотеки Draw?

Погляньте на шаблон відвідувачів .

Її метою є відокремлення алгоритму (у вашому випадку креслення) від об'єктної структури, над якою він працює (елементів).

Таким простим прикладом для вашої проблеми буде:

class Item
{
public:
    virtual void visit(Visitable v)
    {
        v.accept(*this)
    }
};

class Rectangle : public Item
{
public:
    virtual void visit(Visitable v)
    {
        v.accept(*this)
    }
};

class Circle : public Item
{
public:
    virtual void visit(Visitable v)
    {
        v.accept(*this)
    }
};


class Visitable
{
public:
    virtual void accept(Rectangle& r);
    virtual void accept(Circle& c);
};

class Drawer : public Visitable
{
public:
    void accept(Rectangle& r)
    {
        // draw rectangle
    }   
    void accept(Circle& c)
    {
        // draw circle
    }
};


int main()
{
    Item* i1 = new Circle;
    Item* i2 = new Rectangle;

    Drawer d;
    i1->visit(d); // Draw circle
    i2->visit(d); // Draw rectangle

    return 1;
}

Розділений ви опис - на дві паралельні ієрархії - по суті є мостовим малюнком .

Ви хвилюєтесь, що це робить вишукану абстракцію (Прямокутник тощо) залежною від реалізації (RectangleDrawer), але я не впевнений, як ви могли цілком цього уникнути.

Ви, звичайно, можете надати абстрактну фабрику, щоб подолати цю залежність, але вам все одно потрібен спосіб сказати фабриці, який підклас створити, а цей підклас все ще залежить від конкретної уточненої реалізації. Тобто, навіть якщо Rectangle не залежить від RectangleDrawer, він все одно потребує способу сказати фабриці побудувати його, а сам RectangleDrawer все ще залежить від Rectangle.

Також варто запитати, чи корисна це абстракція. Чи намалювати прямокутник настільки важко, що варто ввести його в інший клас, або ви справді намагаєтесь абстрагувати бібліотеку графіки?

Погляньте на поліморфізм, заснований на цінності та поняттях .

Ця робота змінила те, як я дивлюся на поліморфізм. Ми використовували цю систему, щоб мати великий вплив у повторних ситуаціях.

Причина, чому у вас виникають проблеми, полягає в тому, що об’єкти не повинні малювати себе. Намалювати щось правильно залежить від стану мільярда, і прямокутник не матиме жодної з цих частин. У вас повинен бути центральний графічний об'єкт, який представляє стан ядра, як резервний буфер / буфер глибини / шейдери / тощо, а потім надати йому метод Draw ().