Wzorzec Visitor, czyli separacja danych i zachowania

Wzorzec visitor oddziela dane od algorytmu. Pokażę na przykładach, kiedy warto stosować ten wzorzec, a kiedy nie. Warto wspomnieć, że nie zawsze chcemy takiej separacji.

Załóżmy, że piszemy moduł dla jakiegoś procesora tekstu. Mamy następujące 3 struktury:

struct Element {};
struct Paragraph : Element {
    std::string text;
};
struct Link : Element {
    std::string url;
    std::string text;
};
struct List : Element {
    std::vector<std::string> items;
};

Nasz program ma wypisać powyższe struktury w formacie Markdown i HTML.

(uwaga, dla uproszczenia przykładów stosuję wszędzie struct zamiast class)

Przykład 1. Jedna klasa, kilka algorytmów

Jeśli jedna klasa potrzebuje kilku zachowań, to nie musimy stosować wzorca visitor. Załóżmy, że mamy tylko klasę Paragraph, a Link i List nie istnieją. Wtedy wystarczy zwykły polimorficzny printer.

struct Printer {
    virtual void print(const Paragraph& paragraph) = 0;
};
struct HtmlPrinter : Printer {
    void print(const Paragraph& paragraph) override {
        std::cout << "<p>" << paragraph.text << "</p>";
    }
};
struct MarkdownPrinter : Printer {
    void print(const Paragraph& paragraph) override {
        std::cout << paragraph.text << "\n\n";
    }
};

Użycie mogłoby wyglądać tak:

int main() {
    Paragraph paragraph{"Hello, world!"};
    Printer* printer = getPrinter();
    printer->print(paragraph);
}

Nie wnikajmy w to jak dokładnie działa getPrinter, bo nie jest to istotne dla tego przykładu. Ważne, że funkcja ta podejmuje jakąś decyzję i zwraca abstrakcyjny printer. Mamy zatem odseparowaną logikę wyboru zachowania od danych i od samego wypisywania.

Jeśli chcemy dodać wsparcie dla nowego formatu, wystarczy dodać nową klasę dziedziczącą po Printer i zaimplementować metodę print dla typu Paragraph. Nie ma potrzeby stosowania wzorca visitor, bo mamy pełną separację danych i zachowania. Kod jest rozszerzalny i łatwy do utrzymania.

Występuje tutaj tzw. “dynamic dispatch”, czyli po prostu polimorfizm. Wybór odpowiedniej metody print jest podejmowany w czasie wykonywania programu.

Gdybyśmy chcieli dodać wsparcie dla nowego elementu, np. Link, to będzie trzeba dodać nową metodę do klasy Printer i do wszystkich klas dziedziczących. Ale wcale nie będzie to takie proste jak się na pierwszy rzut oka wydaje. W kolejnym przykładzie zobaczymy dlaczego.

Przykład 2. Wiele klas, jeden algorytm

Teraz mamy kilka klas, ale wszystkie z nich będą się wypisywać do Markdownu.

struct MarkdownPrinter {
    void print(const Paragraph& paragraph) {
        std::cout << paragraph.text << "\n\n";
    }
    void print(const Link& link) {
        std::cout << "[" << link.text << "](" << link.url << ")\n";
    }
    void print(const List& list) {
        for (const auto& item : list.items) {
            std::cout << "- " << item << "\n";
        }
    }
};

Tym razem użycie wygląda tak:

int main() {
    MarkdownPrinter printer;
    Element* element = getElement();

    // Auć, to nie wygląda dobrze!
    if (auto paragraph = dynamic_cast<Paragraph*>(element)) {
        printer.print(*paragraph);
    } else if (auto link = dynamic_cast<Link*>(element)) {
        printer.print(*link);
    } else if (auto list = dynamic_cast<List*>(element)) {
        printer.print(*list);
    }
}

Mamy tutaj tzw. “static dispatch”, czyli wybór metody print jest podejmowany w czasie kompilacji. Ale jest to możliwe dopiero po uzyskaniu konkretnego elementu poprzez rzutowanie dynamiczne.

Jeśli widzimy tego typu rzutowanie, to od razu wiadomo, że coś jest nie tak. Widząc taki kod część osób uzna, że funkcja print powinna być metodą wirtualną w klasie Element implementowaną przez Paragraph, Link i List. Wtedy nie będzie rzutowania, a polimorfizm załatwi sprawę.

struct Element {
    virtual void printInMarkdown() = 0;
};
struct Paragraph : Element {
    std::string text;
    void printInMarkdown() override {
        std::cout << text << "\n\n";
    }
};
struct Link : Element {
    std::string url;
    std::string text;
    void printInMarkdown() override {
        std::cout << "[" << text << "](" << url << ")\n";
    }
};
struct List : Element {
    std::vector<std::string> items;
    void printInMarkdown() override {
        for (const auto& item : items) {
            std::cout << "- " << item << "\n";
        }
    }
};

Nie mamy już dedykowanego printera, a kod wygląda tak:

int main() {
    Element* element = getElement();
    element->printInMarkdown();
}

I rzeczywiście, to często jest wystarczające rozwiązanie, choć ma ono jedną zasadniczą wadę: implementacja wypisywania do Markdown-u będzie teraz rozrzucona po kilku klasach, zamiast być zebrana w jednym miejscu.

Co więcej zachowanie, które dodaliśmy do klasy Element wcale nie musi tam pasować. Proste kontenery na dane stały się nagle odpowiedzialne za wypisywanie siebie.

Z pomocą przychodzi wzorzec visitor, który pozwoli nam na odseparowanie danych od zachowania.

struct Element {
    virtual void print(MarkdownPrinter* printer) override = 0;
};
struct Paragraph : Element {
    std::string text;
    void print(MarkdownPrinter* printer) override {
        printer->print(*this);
    }
};
struct Link : Element {
    std::string url;
    std::string text;
    void print(MarkdownPrinter* printer) override {
        printer->print(*this);
    }
};
struct List : Element {
    std::vector<std::string> items;
    void print(MarkdownPrinter* printer) override {
        printer->print(*this);
    }
};

I teraz jest całkiem nieźle, bo mamy pełną separację danych i zachowania. Dokładnie do tego służy visitor.

int main() {
    Element* element = getElement();
    MarkdownPrinter printer;
    element->print(&printer);
}

Uzyskaliśmy tutaj tzw. “double dispatch”, czyli wybór metody Element::print jest dynamiczny (polimorfizm), a wybór metody MarkdownPrinter::print jest statyczny (przeciążenie nazwy funkcji).

Najpoważniejszy problem pojawi się, gdy poza Markdown-em zechcemy dodać wsparcie dla HTML-a. Podobnie jak w przykładzie 1, to wcale nie jest takie proste jak się może wydawać. W tym celu będziemy musieli zmodyfikować zarówno wszystkie podklasy Element, jak i dodać nową klasę HtmlPrinter (to jest akurat zrozumiałe). A jeśli w ogóle nie skorzystaliśmy z visitora, to uzyskamy prawdopodobnie kod podobny do tego:

int main() {
    Element* element = getElement();

    // Znowu wracamy do serii warunków
    if (shouldPrintInMarkdown()) {
        element->printInMarkdown();
    } else if (shouldPrintInHtml()) {
        element->printInHtml();
    }
}

Nie rzuca się to aż tak w oczy jak dynamic_cast, ale nadal otrzymaliśmy kod, który jest trudniejszy do rozszerzenia niż mógłby być. Dodanie nowego formatu wymaga dodania metody printInXXX i pamiętania o dopisaniu kolejnego if-a w kodzie powyżej.

Oczywiście powyższe przykłady są bardzo uproszczone, aby dało się je zrozumieć bez większego wysiłku. W dużym systemie problemy, które tu pokazuję mają dużo poważniejsze konsekwencje.

Czy da się lepiej? Oczywiście! Z pomocą przychodzi abstrakcyjny visitor.

Przykład 3. Wiele klas, wiele algorytmów

Przejdźmy od razu do kodu:

struct Element {
    virtual void print(Printer*) = 0;
};
struct Paragraph : Element {
    std::string text;
    void print(Printer* printer) override {
        printer->print(*this);
    }
};
struct Link : Element {
    std::string url;
    std::string text;
    void print(Printer* printer) override {
        printer->print(*this);
    }
};
struct List : Element {
    std::vector<std::string> items;
    void print(Printer* printer) override {
        printer->print(*this);
    }
};

Widzimy, że klasy nadal wiedzą o tym, że mają być wypisywane, ale logika, która to robi jest gdzieś indziej.

struct Printer {
    virtual void print(const Paragraph& paragraph) = 0;
    virtual void print(const Link& link) = 0;
    virtual void print(const List& list) = 0;
};
struct HtmlPrinter : Printer {
    void print(const Paragraph& paragraph) override {
        std::cout << "<p>" << paragraph.text << "</p>";
    }
    void print(const Link& link) override {
        std::cout << "<a href=\"" << link.url << "\">" << link.text << "</a>";
    }
    void print(const List& list) override {
        std::cout << "<ul>\n";
        for (const auto& item : list.items) {
            std::cout << "  <li>" << item << "</li>\n";
        }
        std::cout << "</ul>\n";
    }
};
struct MarkdownPrinter : Printer {
    void print(const Paragraph& paragraph) override {
        std::cout << paragraph.text << "\n\n";
    }
    void print(const Link& link) override {
        std::cout << "[" << link.text << "](" << link.url << ")\n";
    }
    void print(const List& list) override {
        for (const auto& item : list.items) {
            std::cout << "- " << item << "\n";
        }
    }
};

Mamy teraz dwie implementacje Printer-a. Każda z nich skupia się na jednym formacie.

Pora na użycie tego kodu:

int main() {
    Element* element = getElement();
    Printer* printer = getPrinter();

    element->print(printer);
}

No cudo! Myślę, że powyższy kod sam się broni. Połączyliśmy wiele typów danych z wieloma zachowaniami zachowując przy tym pełną separację. Jeśli trzeba coś poprawić w składni HTML, to mamy jedną klasę, która zajmuje się tylko tym - wypisywaniem wszystkich elementów do HTML-a.

Dodanie nowego formatu nie wymaga modyfikacji Element-ów.

Dodanie nowego elementu, poza trywialną implementacją metody Element::print, wymaga dopisania nowej metody Printer::print do każdego Printer-a. To jest akurat zrozumiałe, nikt tego za nas nie zrobi. Plus jest taki, że jeśli zapomnimy o dopisaniu jednej z metod, to kompilacja programu się nie powiedzie. Dla porównania, wcześniej mogliśmy zapomnieć o dopisaniu kolejnego if-a i program by się uruchomił, ale działałby niepoprawnie.

Uzyskaliśmy połączenie zalet z obu poprzednich przykładów.

Na koniec zmapujmy nazwy klas i metod do terminologii wzorca visitor:

Osobiście nie jestem fanem używania tej terminologii w kodzie. Doświadczony programista i tak szybko zorientuje się, że ma do czynienia z visitorem, a nazywanie funkcji i klas w sposób, który jest zgodny z ich rolą w kodzie jest dla mnie bardziej naturalne.