哪種設計模式適合車輛任務

Question

我有一輛車，它有任務。在這些任務中，這輛車消耗燃料。燃料消耗如下。

第一任務燃料消費公式如下

result = time * fuel * 60; 

第二

result = (startPoint-endPoint)/speed * fuel; 

第三

result = (endPoint-startPoint)/speed * fuel; 

和你第四

result += movement/speed * fuel; 

的方式

movement = startpoint - endpoint or endpoint - startpoint 

，用戶將選擇一個或多個任務。我的程序將執行總燃料消耗量。

根據這些信息。你認爲哪種設計模式最適合？

Answer 1

的車輛進入不同的任務......

State design pattern會適合你所要求的。在每種狀態下，您都可以使用不同的方式來查找結果。

Answer 2

哪個設計模式最適合？

看起來像Strategy模式可以滿足您所要做的最好的事情。

Answer 3

事實：

• Vehicle持有約fuel，speed信息，某種歷史的關於它的運動等。
• 你已經確定了4種不同類型的Mission消費fuel的
• 將取決於Mission的Vehicle

的類型和狀態我看到的是，你可以：

1. 充分利用多邊形〜>定義了一般class Mission，它將規定具體類型任務的接口（實現爲從Mission派生的類） 或
2. 給Mission在確定fuel會被消耗掉

第一種方式將使用成員type「感覺相當OO」，第二個「感覺相當的程序」，因爲你很可能會結束了類型代碼：

switch (type) { 
    case ONE: ... 
    case TWO: ... 
    ... 
} 

這也將是你的代碼的一部分，將有一次你發現，你需要的不僅僅是4種類型的Mission更要編輯......我想說的是如果你選擇多態性，在這種情況下，你最終會得到更乾淨的代碼。

那麼你最後的決定將只是你如何「混合」Vehicle的背景與Mission的類型。也許你會最終傳遞Vehicle的背景下Mission直接，是這樣的：

class Mission { 
public: 
    double getFuelConsumptionSpeedForVehicle(const Vehicle&); 
}; 

或什麼，一旦你到達那裏會感到...在最後，你會發現，你已經使用多個設計模式，而無需在編寫此代碼時實際瞭解/遵循它們。

...剛開始有一些代碼，不出汗的小東西太多;）