Design patterns 筆記 - Strategy pattern on C++

contributed by < jeffrey.w >

這篇筆記回顧我 2001 年剛學 design patterns 的時候對 strategy pattern 的誤解，透過重新審視 2001 那年的誤解，重新學習 strategy pattern。

Strategy pattern 很容易跟 template method pattern 混淆，2001 年我剛學這兩種 pattern 的時候，甚至直接誤以為「把實作碼寫在 base class 讓 derived class 繼承就是 design pattern」，當年我真是完全誤解了 strategy pattern 和 template method pattern 在設計上的初衷。

先舉一個跟 design pattern 完全沒有關係 的例子，但我在 2001 年卻曾經把這個例子誤會成 design pattern。

以下這個例子和 design pattern 沒有任何關係

#include <iostream>

/*
 * 哺乳動物
 */
class Mammalia {
    public:
        void run(){
            std::cout << "run with four legs" << std::endl;
        }
};

class Dog : public Mammalia {
    
};

class Cat : public Mammalia {

};

/*
 * gcc wrong.cpp -lstdc++ -o wrong
 */
int main() {
    Dog dog;
    Cat cat;

    dog.run();
    cat.run();

    return 0;
}

上面這個例子，跟 design pattern 沒有任何關係，僅僅只不過是讓 Dog 和 Cat 這兩個類別不用重複打 run 的實作碼而己。

把 Liskov Substitution Principle 這個概念導入會不會就是 strategy pattern？

int main() {
    Mammalia *mammalia = new Dog();

    mammalia->run();
    delete(mammalia);

    mammalia = new Cat();

    mammalia->run();
    delete(mammalia);

    return 0;
}   

看起來真的很像 strategy pattern，如果沒有再仔細看 Mammalia 的 implementation，真的就會誤以為這是 strategy pattern 了。

2001 年的時候我真的誤以為這樣就是 strategy pattern，甚至也把這個當成 template method pattern，當時我完全沒有意識到我己經從根本上就誤會了 strategy pattern 和 template method pattern 在設計上的初衷。接著我將重新來審視一下我錯在什麼地方。

先問自己一個問題，設計 Mammalia 這個 class 的時候，會不會知道每一個哺乳動物是怎麼跑的？甚至是不是可以假設每一個哺乳動物都會跑？

/*
 * 哺乳動物
 */
class Mammalia {
    public:
        void run(){
            std::cout << "run with four legs" << std::endl;
        }
};

顯然，設計 Mammalia 這個 class 的時候並沒有辦法得知每一個哺乳動物都是怎麼跑的，所以直接在 class Mammalia 實作 run 這個 function 是不合適的。雖然對於用兩隻腿跑的哺乳動物可以用 override，但對於鯨魚，由於鯨魚不會跑，所以也是要用 override。

於是，base class 的實作是 "run with four legs"，某些哺乳類另外 override 成 "run with two legs"，某些哺乳類另外 override 成 "no legs to run"。

這意味著每個繼承 Mammalia 的 class 都要去思考 run() 要不要 override，而思考要不要 override 的時候，就要想一下 Mammalia class 所實作的 run() 符不符合 derived class 的 run() 的需求。

這也 意味著每個繼承 Mammalia class 的 derived class 要確保正確執行就要看一下 Mammalia class 的 run 的實作碼。

於是，問題來了，這樣設計繼承體系到底有什麼意義？原本你不需要 run() 的時候你只需要不實作 run() 就可以了，現如今不管你需不需要 run() 你都需要去看 Mammalia class 的 run 的實作碼，更糟糕的是，需要去看 Mammalia class 的 run 的實作碼 只是第二步，不是第一步。為什麼只是第二步而不是第一步？因為第一步是 你要先知道你需要去看 Mammalia class 的 run 的實作碼。

至此，再重新問自己一個問題，這樣設計繼承體系到底有什麼意義？

沒有意義！一點意義都沒有！

這樣設計繼承體系是沒有意義的！這只是為繼承而繼承，以後在維護的時候還要去評估哪些 function 必須要 override、哪些 class 需要 override 哪些 function。而且在評估這些東西之前，你還得先知道有哪些東西需要評估。

這也不是 strategy pattern，這只是增加無謂的複雜性、無謂的增加維護的痛苦和困難度而己。

很遺憾的是，在 2001 年的時候，我並沒有意識到我對 strategy pattern 的誤解，我也完全沒有意識到我對於繼承和 override 的誤用會對日後進行維護工作的工程師造成多大的痛苦。

不過慶幸的是，當時我還只是一個沒有工作的學生，所以我並沒有把這種東西上線，頂多只是讓錯誤的知識跟著我好幾年而己。因此，這次透過重新審視過去的觀念，讓未來可以避免犯下害人害己的錯誤。

要不要 override 並不是 「這不是 strategy pattern」的主要原因，所以，我們先看一下 strategy pattern 的本意是要解決什麼類型的問題：

[reference, w3sdesign]

• How can a class be configured with an algorithm at run-time instead of implementing an algorithm directly?
• How can an algorithm be selected and exchanged at run-time?

把一開始的例子重寫，看看怎麼在 run-time 的時候，選擇執行不一樣的 run

#include <iostream>

/*
 * 哺乳動物
 */
class Mammalia {
    public:
        virtual ~Mammalia() = default;
};

class Dog : public Mammalia {
    
};

class Cat : public Mammalia {

};

void run(Mammalia *mammalia){
    if(dynamic_cast<Dog *>(mammalia) != nullptr) {
        std::cout << "run with two legs with dog-style" << std::endl;
    } else if(dynamic_cast<Cat *>(mammalia) != nullptr) {
        std::cout << "run with two legs with cat-style" << std::endl;
    }
}

/*
 * gcc wrong-2.cpp -lstdc++ -o wrong-2
 */
int main() {
    Dog dog;
    Cat cat;

    run(&dog);
    run(&cat);

    return 0;
}

我們看一下這一段

void run(Mammalia *mammalia){
    if(dynamic_cast<Dog *>(mammalia) != nullptr) {
        std::cout << "run with two legs with dog-style" << std::endl;
    } else if(dynamic_cast<Cat *>(mammalia) != nullptr) {
        std::cout << "run with two legs with cat-style" << std::endl;
    }
}

這段允許在 run-time 的時候選擇執行不一樣的實作碼，雖然語法正確，但是違反了物件導向設計的 SOLID 五大基本原則之一的 OCP (Open–Closed Principle)。怎麼說呢？假如今天新增了一個類別 Cow，那 run 這個 function 就要再進行修改，要改成這樣，增加第 6, 7 行。

void run(Mammalia *mammalia){
    if(dynamic_cast<Dog *>(mammalia) != nullptr) {
        std::cout << "run with two legs with dog-style" << std::endl;
    } else if(dynamic_cast<Cat *>(mammalia) != nullptr) {
        std::cout << "run with two legs with cat-style" << std::endl;
    } else if(dynamic_cast<Cow *>(mammalia) != nullptr) {
        std::cout << "run with two legs with cow-style" << std::endl;
    }
}

也就是說，每增加一個類別，run 就要修改一次，而 Open–Closed Principle 這個原則講的是 should be open for extension, but closed for modification
[reference, wiki]

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

如果這種 if-else 只有四五個，其實還算好維護，然而，當 if-else 成長到十幾個、幾十個的時候，後續的維護人員真的可以單純只要加一個 if-else 而不用去看其他的 if-else 嗎？

要如何做到每次在擴充的時候不用去改原本己經寫好的程式？在這個範例裡，我們可以使用 strategy pattern。

回到一開始的範例，我們看一下 Mammalia 的實作碼錯在什麼地方

/*
 * 哺乳動物
 */
class Mammalia {
    public:
        void run(){
            std::cout << "run with four legs" << std::endl;
        }
};

我們希望能在 run-time 的時候選擇執行不一樣的實作碼，但 Mammalia 身為 base class，直接就把實作碼寫在 base class 。這裡的問題不在於 derived class 要不要 override，而是在於這個情境的 base class 不應該假設知道 run-time 的時候會執行什麼。

最後，我們把一開始的範例做一個修改

#include <iostream>

/*
 * 哺乳動物
 */
class Mammalia {
    public:
        virtual void run() = 0;  // pure virtual function
};

class Dog : public Mammalia {
    public:
        void run() override {
            std::cout << "run with two legs with dog-style" << std::endl;
        }
};

class Cat : public Mammalia {
    public:
        void run() override {
            std::cout << "run with two legs with cat-style" << std::endl;
        }
};

/*
 * gcc correct.cpp -lstdc++ -o correct
 */
int main() {
    Mammalia *dog = new Dog();
    Mammalia *cat = new Cat();

    dog->run();
    cat->run();

    return 0;
}

$ ./correct 
run with two legs with dog-style
run with two legs with cat-style

在這個版本，如果新增一個 class Cow，不用改到原本己經寫好的程式。不過，每一個 derived from Mammalia 的 class 都必須要 override run 這個 function，因為 run 是 pure virtual function。

But，這裡仍舊沒有用到 strategy pattern，感謝 @rayshih 的提醒，這個範例換掉的是整個 object，還是只用到繼承而己。
我們看以下這個範例

class Test {
    public:
        void run(Mammalia *animal){
            animal->run();
        }
};

/*
 * gcc correct.cpp -lstdc++ -o correct
 */
int main() {
    Dog *dog = new Dog();
    Cat *cat = new Cat();

    Test *test = new Test();
    test->run(dog);
    test->run(cat);

    return 0;
}

比較這兩個範例的差別，A 是以整個 object 為單位做替換，B 的替換卻是為了 使用不同的 run 的實作。
A

    dog->run();
    cat->run();

B

    Test *test = new Test();
    test->run(dog);
    test->run(cat);

References

• Design Patterns: Elements of Reusable Object Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
• The Strategy design pattern - Problem, Solution, and Applicability. w3sDesign.com. Retrieved 2017-08-12.

tags: design patterns strategy pattern