天亮了 昨晚是平安夜
洛神:10號玩家請繼續發言
10號: 我跟5號的想法也蠻像的,其實我也沒有立馬站邊9,我是說我先站邊9,那時候到4號發言的時候我確實心裡有小小掙扎,投票到底要不投還是要怎樣,看大家的狀態,但是他撞了嘛,所以我覺得以這樣子的操作來說的話,因為剛第一晚殺非常久,一定是有人下指導棋,叫7號去跳狼王,這件事情,會下指導棋我覺得3號是蠻高機率,那他是打2號,然後8號順著5號講懷疑到我身上我也覺得是順的,關於投票的部分我順著9號講,是因為你頭異形票我覺得你就是狼。6號走感覺像是好人走,現在如果剩下兩狼我覺得是3或8,我會投8,過。
洛神:請決定要放逐的對象,3 2 1 請投票
投3:2 5
投8:3 10
投10:8
洛神:3號 8號平票,進入PK環節,3號開始發言
待續..
今天先由設計模式領軍
我們這邊要套用策略模式
什麼是策略模式呢?
最基本的解釋方式是將某一個行為(接口)通過不同的方法/算法實現,方便需要實現該接口對應行為
The basic idea is to delegate tasks to encapsulated algorithms which are interchangeable at runtime.
先舉個小例子
比方說我們希望鴨鴨擁有不同的技能,包含呱呱叫
與飛起來
我們就可以透過策略模式這樣實現
class Duck
{
swim();
}
class MallardDuck : IFlyable
{
fly();
}
class RedheadDuck : IFlyable, IQuackable
{
fly();
quack();
}
策略模式的一般思想是通過在它們之間放置一個抽象層來將對象及其不同的行為(也就是策略)彼此分開。
再舉個完整一點的例子
我們有兩個對象,方形盤或是六邊形盤。這兩個對像都是繼承 BasicPlate 類的類,後者是一個抽像類。目標是為板物體提供彩色積木。積木的顏色將像徵這種情況下的策略。我們希望在運行時可以使用所有盤子和彩色積木的組合,但我們不確定哪種方法是最好的。
因此,我們正在研究兩種可能的解決方案:繼承母類別和策略模式。
傳統物件導向如果要實作圖中的方形盤或是六邊形盤
最初的物件對象 (OO) 方法是為盤子和彩色積木的所有變體創建獨立的類別。以這種方式創建的每個類都將擴展 方形盤或是六邊形盤並指定它們的積木顏色。乍一看,這解決了目標,但這種方法也帶來了一些問題。
首先,程式編譯執行後無法更改積木的顏色。這不是一個有好的做法,因為我們可能希望在未來添加換顏色的功能。因此,具有在運行時更改對象策略的靈活性對我們來說很有價值。
其次,它創建了更多的類別為了實現不同形狀或顏色的盤子,目前,類別的數量很少。但是,將來可能會添加更多的盤和彩色積木就會造成比較多重複出現的程式碼
因此我們多加入一層抽象層讓積木可以在這個類別裡面變化顏色
這麼一來就可以透過抽象讓要達成目標或是擁有技能的物件更加具有彈性
reference:
$xvg
天黑請閉眼