Java語言編程學習之Lambda表達式設計和架構的原則[圖]

Java語言編程學習之Lambda表達式設計和架構的原則[圖]：
大家都知道，Lambda表達式是對Java語言的一點簡單改進，在JDK標準類庫中，運行它的方式各種各樣。但是大多數的Java代碼都不是由開發JDK的程序猿寫的，而是像我們這樣的普通程序猿。
很多人都會碰到過這樣的情況：你實現了一個新功能或修復了一個缺陷，並且對自己的修改很滿意。但其他人看了你的代碼後——也許發生在代碼審查環節，完全不買賬！對於什麼是好代碼，什麼是壞代碼，存在分歧很正常！
設計模式的改變
設計模式是人們熟悉的另一種設計思想，它是軟件架構中解決通用問題的模板。如果碰到一個問題，並且恰好熟悉一個與之適應的模式，就能直接應用該模式來解決問題。從某種程度上來說，設計模式將解決特定問題的最佳實踐途徑固定了下來。
當然的了，沒有永遠的最佳實踐。以曾經風靡一時的單例模式爲例，該模式確保只產生一個對象實例。在過去十年中，人們批評它讓重新變得更脆弱，且難於測試。敏捷開發的流行，讓測試顯得更加重要，單例模式的這個問題把它變成了一個反模式：一種應該避免使用的模式。
所以我們應該知道的是，正確的使用Lambda表達式，讓現有的設計模式變得更好、更簡單，或者在某些情況下，有了不同的實現方式。

常見的一些設計模式：
命令者模式：
命令者是一個對象，它封裝了調用另一個方法的所有細節，命令者模式使用該對象，可以編寫出根據運行期條件，順序調用方法的一般化代碼。命令者模式中有四個類參與其中，如圖：
2.策略模式：
策略模式能在運行時改變軟件的算法行爲。如何實現策略模式根據你的情況而定，但其主要思想是定義一個通用的問題，但是不同的算法來實現，然後將這些算法都封裝在一個統一接口的背後。
文件壓縮就是一個很好的例子：
3.觀察者模式：
觀察者模式是另一種可被Lambda表達式簡化和改進的行爲模式。在觀察者模式中，被觀察者持有一個觀察者列表。當被觀察者的狀態發生改變，會通知觀察者。觀察者模式被大量應用於基於MVC的GUI工具中，以此讓模型狀態發生變化時，自動刷新視圖模塊，達到二者之間的解耦。
4.模板方法模式：

開發軟件時一個常見的情況是有一個通用的方法，只是步驟上略有不同，我們希望不同的實現能夠遵守通用模式，保證他們使用了同一個算法，也是爲了讓代碼更加易讀。窗邊的小豆豆（http://www.simayi.net/dushubiji/6111.html）讀書筆記摘抄好詞好句及感悟賞析,一旦你從整體上理解了算法，就能更容易理解其各種表現。

模板方法模式是爲這些情況而設計的：整體算法的設計是一個抽象類，它有一系列抽象方法，代表算法中可被定製的步驟，同時這個類中包含了一些通用代碼。算法的每一個變種由具體的類實現，它們重寫了抽象方法，提供了相應的實現。
使用Java編寫DSL
領域專用語言(DSL)是針對軟件系統中某特定部分的編程語言。他們通常比較小巧，表達能力也不如Java這樣能應對大多數編程任務的通用語言強。DSL高度專用：不求畫面俱到，但求有所專長。
Java BDD框架：下面的例子描述了一個Stack的某些行爲。
（左右滑動可以查看）
public class StackSpec{{
describe("a stack", it -> {
it.should("be empty when created",expect -> {
expect.that(new Stack()).isEmpty();
});
it.should("push new elementsonto the top of the stack", expect -> {
Stack<Integer> stack = new Stack<>();
stack.push(1);
expect.that(stack.get(0)).isEqualTo(1);
});
it.should("pop the last element pushed onto the stack", expect -> {
Stack<Integer> stack = new Stack<>();
stack.push(2);
stack.push(1);
expect.that(stack.pop()).isEqualTo(2);
});
});
}):
首先我們使用動詞 describe 爲套件起頭，然後定義一個名字表明這是描述什麼東西的行爲，這裏我們使用了 "a stack"。
每一條規則讀起來儘可能接近英語中的句子。它們均以 it.should 開頭，其中 it 指正在描述的對象。然後用一句簡單的英語描述行爲，最後使用 expect.that做前綴，描述期待的行爲。
檢查規則時，會從命令行得到一個簡單的報告，表明是否有規則失敗。你會發現 pop 操作期望的返回值是 2，而不是 1，因此“pop the last element pushed onto the stack” 這條規則就失敗了：
a stack
should pop the last element pushed onto the stack[expected: but was: ]
should be empty when created
should push new element onto the top of the stack
好了，我們本期就到這裏了！再見！