1.1spec基本概念：
spec，全稱爲specification，即規約，其規約的是使用者（client）和實現者（implementor）之間的妥協與契約，即是一種在使用時必須要遵循的要求的說明，也是一種在在實現時需要遵循的原則。
1.2spec一般被書寫在：
（1）每一個類前面，（2）每一個方法前面
1.3spec組成與分類
spec從annotation上由@parameter、@throws、@return組成。完整的spec其需要涵蓋若干對於前置條件和後置條件的說明，包括基本使用方法、immutable/mutable、類型限制、實用可能出現問題的情況的描述。
書寫規範舉例
/**
* Get the target vertices with directed edges from a source vertex and the
* weights of those edges.
*
* @param source a label
* @return a map where the key set is the set of labels of vertices such
* that this graph includes an edge from source to that vertex, and
* the value for each key is the (nonzero) weight of the edge from
* source to the key
*/
約定俗成的規矩是使用者需要在滿足前置條件的情況下，才能得到正確的結果，
所以要求使用時需要認真閱讀spec。當然出於程序員的良心，可能會幫client多考慮一些事情，或者是額外處理一些情況，或者是拋出相應的異常使其fall fast。
分類有確定的規約和欠定的規約。
1.4.1行爲等價性
行爲等價（Behavioral equivalence）意思是，
不同的代碼實現，對於用戶來講，是否是等價的，即相對於提供的同一個spec，是不是都被滿足了，如果都滿足那麼就算做等價。
所以重點就是要站在用戶端看待問題，只要同一個spec被滿足，則說明實現了相同的功能，即同一個spec所有實現是等價的。
不能單看代碼的結果不一樣就說兩個實現是不等價的。
1.4.2spec的強弱的判斷和比較方法
前置條件越弱，一方面，對於用戶更加的友好，其不用考慮太多的情況即可放心使用。另一方面，對於程序員的要求就越高，因爲這意味着他需要考慮到更多的情況，使得程序員不能隨便實現了。使得規約變強。
後置條件越強，對於用戶來講得到的信息越具體，這樣就需要程序員使用更加具體的實現方式，限制了實現的手段，使得程序員不能隨便實現了。使得規約變強。
這裏面值得注意的是，因爲前置條件必須被滿足，所以後置條件的比較是在前置假設成立的條件下進行的，在很多情況下，前置條件的限制使得後置條件從不同變爲相同
規約越強，實現的手段就越少。所以我們在實現了一個規約之後，代碼可以直接適用於比這個規約弱的規約，但是不再能適用於比這個強的規約了。
to be continued…
不要慌張，軟件構造的概念有時候就是這麼讓人頭禿…