讀了著篇文章之后發現真的是，你的思想，你的思維是真的比比你擁有什么技術要強的。

注?

開閉原則

開閉原則（Open-Closed Principle）是面向對象設計中的基本原則之一，它的定義是：一個軟件實體應該對擴展開放，對修改關閉。也就是說，在軟件的生命周期內，當需要對軟件進行修改時，應該通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。

開閉原則的目的是提高軟件的可復用性和可維護性。在軟件開發過程中，隨著業務需求的變化，軟件需求可能會發生變化，而開閉原則可以幫助我們避免對現有代碼的修改，從而減少引入新錯誤和重構整個功能的風險

迪米特法則

迪米特法則（Law of Demeter，LoD）是一種面向對象設計原則，也被稱為最少知識原則（Least Knowledge Principle，LKP）。它指出一個軟件實體應當盡可能少地與其他實體發生相互作用。如果一個系統符合迪米特法則，那么當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。

迪米特法則的核心思想是降低組件之間的耦合度，提高代碼的松耦合性，從而使得代碼更易于維護、擴展和重構。在迪米特法則的指導下，一個類應該盡可能少地與其他類發生相互作用，盡量避免直接相互依賴，而是通過接口、抽象類等機制來進行通信，使得類與類之間的聯系更加松散，易于維護和擴展。

迪米特法則的命名來源于古希臘神話中的人物狄米特（Demeter），她是希臘神話中的農業女神，也是宙斯的姐姐。在這個神話中，狄米特規定了農業的生產規律，類似于迪米特法則規定了軟件實體之間的通信規律。

圍繞高內聚和低耦合兩個方面，然后結合設計模式

獎勵發放策略

第一天，老師問小明：“你知道活動營銷嗎？”
“這我知道，活動營銷是指企業通過參與社會關注度高的已有活動，或整合有效的資
源自主策劃大型活動，從而迅速提高企業及其品牌的知名度、美譽度和影響力，常見
的比如有抽獎、紅包等。”
老師點點頭：“是的。我們假設現在就要做一個營銷，需要用戶參與一個活動，然后完
成一系列的任務，最后可以得到一些獎勵作為回報。活動的獎勵包含美團外賣、酒旅
和美食等多種品類券，現在需要你幫忙設計一套獎勵發放方案。”
因為之前有過類似的開發經驗，拿到需求的小明二話不說開始了編寫起了代碼：

?小明很快寫好了 Demo，然后發給老師看。
“假如我們即將接入新的打車券，這是否意味著你必須要修改這部分代碼？”老師
問道。

一眼就看出了端詳。這不滿足我們設計原則中的開閉原則，和迪米特原則。

那我們該如何進行優化呢？

這個案例就可以用適配器和策略模式來調優

策略模式 | 菜鳥教程?? 適配器模式 | 菜鳥教程

先通過這個策略模式優化了變成如下代碼

?然后，小明創建策略模式的環境類，并供獎勵服務調用：

小明的代碼經過優化后，雖然結構和設計上比之前要復雜不少，但考慮到健壯性和拓展性，還是非常值得的。

策略類是有狀態的模型嗎？如果不是是否可以考慮做成單例的？

環境類的獲取策略方法職責很明確，但是依然沒有做到完全對修改封閉

解決：可以將策略類單例化以減少開銷，并實現自注冊的功能徹底解決分支判斷

小明列出單例模式的要點：
單例模式? 設計模式屬于創建型模式，它提供了一種創建對象的最佳方式。
這種模式涉及到一個單一的類，該類負責創建自己的對象，同時確保只有單個對象被
創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該
類的對象。

?最終，小明在策略環境類中使用一個注冊表來記錄各個策略類的注冊信息，并提供接
口供策略類調用進行注冊。同時使用餓漢式單例模式去優化策略類的設計：

最終，小明設計完成的結構類圖如下：

如果使用了 Spring 框架，還可以利用 Spring 的 Bean 機制來代替上述的部分設計，
直接使用 @Component 和 @PostConstruct 注解即可完成單例的創建和注冊，代
碼會更加簡潔。

一些自己的思考

在設計你的業務邏輯的時候，或者寫你的邏輯的代碼，一定一定要思考設計模式-創造型模式，結構型模式，和行為型模式，還有下面的

J2EE 模式
這些設計模式特別關注表示層

我們該用什么。怎么調優

任務模型的設計

現在，我想讓你去完成任務模型的設計。你需要重點關注狀態的流轉變更，以及狀態變更后的消息通知。而上一個獎勵發放策略貌似是狀態的一個確定。

小明呢接下了難題，他首先定義了一套任務狀態的枚舉和行為的枚舉

然后，小明對開始編寫狀態變更功能

很明顯上述代碼依然存在有上一個例子的問題。

問題是什么

第一，方法中使用條件判斷來控制語句，但是當條件復雜或者狀態太多時，條件判
斷語句會過于臃腫，可讀性差，且不具備擴展性，維護難度也大。且增加新的狀態時
要添加新的 if-else 語句，這違背了開閉原則，不利于程序的擴展

第二，任務類不夠高內聚，它在通知實現中感知了其他
領域或模塊的模型，如活動和任務管理器，這樣代碼的耦合度太高，不利于擴展

優化