靜兒就職的是新美大的基礎架構部門，做的是基於k8s的容器調度開發。k8s只是個工具，真正技術的上就是和網絡打交道要多些。需要對網絡中的數據流向有清晰的認識。大多數時間還是在做平台，事情很跟業務很相似，也主要是工程。
之前記得有同事說過，設計的東西都被框架封裝好了，設計模式基本用不上。但是靜兒怎么覺得天天在用設計模式呢？
舉個栗子🌰，這不快過年了嗎，近來年一過年各種運勢測算就來了。記得《花千骨》熱播那年有個根據姓名“測測你是《花千骨》里的誰？”。產品給了這個任務，對大多數程序員來說too easy。
先說說產品給的設計：
輸入：姓名
輸出：對應的人物和介紹
計算方法：模6，將姓名的ascii碼值除於6。得到的對應余數輸出下面答案。
0.花千骨
她是世間最后一個神，也是百年難得一見的天煞孤星，她善良而堅強執着，對待朋友真心實意。她是愛上了一個人，即使被傷的體無完膚，卻依然深愛的不肯放棄的人，但並不是要這個人，只是要得到對方的認可。她有這樣的執着，而你也有這樣的執着，所以性格上，有一點像花千骨。
1.白子畫
長留上仙白子畫，是一個超凡而孤高，冰涼而淡漠，溫潤如玉又雲淡風清的人。他本無情，卻最終為花千骨操碎了心。在花千骨放出妖神闖下大禍后，毅然為她承擔起大部罪責，花千骨囚禁海底，亦相伴左右16年。可是最終為了天下，辜負了愛情。你是白子畫，是因為你也會選擇事業，不會選擇愛情。
2.殺阡陌
他是妖魔之王，掌控整個妖界。長得極為好看，很自戀，是六界最美的人。他在開始只是把花千骨當做妹妹保護，但是最后和她相處久了，便喜歡上了她。仙界之戰中，曾為她殺上長留，對抗整個仙界。如果你愛上了一個人，也是會逆流而上，不會隱忍自己的感情的人哦。
3.輕水
輕水是一個很普通的女孩子，她溫柔賢淑，心地善良，簡直是在眾仙，眾妖中的一股清流。她對愛情也是比較堅持的，為了愛的人，願意放棄成仙的機會，雖然后來也嫉妒花千骨，差點做錯事，但是及時意識到自己的錯，總之是一個普通的常人，卻依然有自己的亮點。
4.東方彧卿
他氣質出塵，膚質白皙，擁有一雙月牙眼，笑起來春暖花開像只狐狸。他為人有一些風流不羈，幽默風趣，玩世不恭，為人豁達。只對花千骨萬般寵愛和溫柔深情，喜歡上花千骨，也願意為她做所能做的一切。最后為心愛的人擋下一掌，粉身碎骨。為人風趣的你，對愛有犧牲精神，正似東方彧卿。
5.夏紫薰
原本是仙界的紫薰仙子，上仙之一，卻因愛上白子畫而成為墮仙，墜入魔道。紫薰仙子是一個很有個性的角色，她只羡慕鴛鴦不羡仙，為了愛情，並不在乎是否是仙還是妖，最后成為墮仙，進入了魔道。雖然你現實生活中不可能這么極端，但是你也是這類有個性的人，不走尋常路啊。
最簡單粗暴的設計方法：在程序里switch case完工！
用設計模式的話，這里用工廠模式是比較合適的。每一個答案是一個類，定義一個方法，可以叫：requireFortuneTellingResult。
開發小哥哥抱怨說：明明這么簡單一件事情，用工廠模式我多寫好幾個類呢。看上去也沒什么好處啊。回憶一下設計模式的六大原則就可以知道設計模式解決的是維護性和擴展性的問題(也叫：寫出看的懂的代碼)，而不是多幾個少幾個復制粘貼的開發問題。這些開發成本是可以通過工具解決的。
用了工廠模式后，作為后來的開發者requireFortuneTellingResult里具體的內容可以不關心。只是主方法足以說明主題。
偽代碼如下：
Map fortuneTellings = {
0:花千骨.class,
1:白子畫.class,
2:殺阡陌.class,
3:輕水.class,
4:東方彧卿.class,
5:夏紫薰.class}};
String fortuneTellByName(String name) {
LOG.info("用戶的姓名:{}",name)//此行偽代碼相當重要，因為獲取到的信息是產品的價值之一！
return fortuneTellings.get(name.val/6).requireFortuneTellingResult();
}
看，主函數一行代碼足以說明整個意圖。
產品上線后，傳播很快。運營MM將這一報告反饋給產品，產品MM就想了：用這么一個低成本的產品獲取了大票流量，我真是太聰明了！不過有個問題，就是除了名字，用戶的其他信息沒有獲取到啊。我怎么能通過這個產品獲取用戶的一些個人偏好，有針對性對其進行推送呢？
於是，產品MM基於這個產品，需要在保留老產品的基礎上新開發一個產品。這個產品先讓用戶做幾個判斷題，根據選擇題的結果得到你是《花千骨》里的誰。設計如下：
輸入：選擇題答案
1.你喜歡粉色還是藍色？//判斷性別
A.粉色 B.藍色
2.隨着年齡增長，你從一個精神主義者變成了徹底的物質至上者了嗎？//判斷年齡
A.是 B.不是
3.旅游一般是選擇國內還是國外？//判斷收入
A.國內 B.國外
輸出：對應的人物和介紹
計算方法：題目1的答案A為1分，B為2分；題目2的答案A為3分，B為4分；題目3的答案A為5分，B為6分；將分數加和模6。
因為上面的工廠方法，我不用把一堆switch case拷貝一遍來改。而是非常簡單的再添加一條策略：
String fortuneTellByName(int anwser1, int anwser1, int anwser1) {
LOG.info("題目1答案:{},題目2答案:{},題目3答案:{}",anwser1,anwser2,anwser3)//此行偽代碼相當重要，因為信息是產品的價值之一！
int sum=anwser1+anwser2+anwser3；
return fortuneTellings.get(sum/6).requireFortuneTellingResult();
}
策略模式大功告成！策略模式封裝了不同的算法，根據需求靈活選用，很好的解決了邏輯的復用問題，是平時開發中的一個好幫手。
上面兩個測試如果比如用了同一個微信號測試的，那就能將名字和其他信息做一個關聯了。互聯網開發產品完成后一定要做的事情：大數據分析開始了。首先建立用戶畫像。
建立一個UserProfileBuilder。里面有withName、withGender、withAge、withIncome，最后有個build()方法，來完成整體信息的展示。
建造者模式完工！將UserProfileBuilder代替前面的log打印。在后台統計頁面可以生成漂亮的用戶畫像圖。
前些日子金庸老先生去世了。為了蹭個熱點，聰明的產品MM告訴開發小哥說再開發一個產品：把《花千骨》主題換下來，換成“測測你是金庸小說里的誰”。當然，互聯網原則：原產品不下線，繼續保留。只保留不維護。
用工廠模式，又生成了一堆requireFortuneTellingResult()方法的子類之后，怎么和策略模式里生成的兩個策略做銜接呢？
這時候只需要將 Map fortuneTellings 封裝一下。一個是《花千骨》工廠的map，一個是《金庸小說》工廠的map。另寫一個指揮官類。根據需要來指定是哪個工廠即可！
橋接模式就是這么簡單！
靜兒文中沒有對具體的設計模式內容對介紹，網上一大堆，這種場景下都不用糾結用谷哥還是度娘。本文的要點是設計模式應該是自己平時開發中時時刻刻都在用的。意識很重要。