再使用性/發佈等價原則
The Reuse/Release Equivalence Principle, REP
The granule of reuse is the granule of release.
重複使用的粒度就是發佈的粒度。
那些被拿來重複使用的程式碼，需透過發佈程序並賦予版本編號。
便於我們追蹤、確保重用的元件是彼此兼容的。
開發人員很常收到新版本的提醒。
會根據該版本所作的修改，來決定是否繼續使用舊版本。
組合到元件中的類別和模組應該一起被發佈。
它們共享了相同的版本編號與版本追蹤，並被包含到同一版本的文件中。
共同封閉原則
The Common Closure Principle, CCP
Gather into components those classes that change for the same reasons and at the same times. Seperate into different components those classes that change at different times and for different reasons.
收集那些在相同時間、因相同理由改變的類別到元件之中。
分離那些在不同時間、因不同理由改變的類別到不同的元件之中。
共同重複使用原則
The Common Reuse Principle, CRP
Don’t force users of a component to depend on things they don’t need.
不要强迫使用者去依賴他們不需要的元件。
元件版本的介面隔離原則。
The Tension Diagram For Component Cohesion
三個内聚性原則彼此的關係像是互相拉鋸。
再使用性/發佈等價原則 (REP) 和 共同封閉原則 (CCP)
是包容性的原則，兩者都傾向把元件變得更大。
而 共同重複使用原則 (CRP) 則是排除性的原則，
它會使得元件變得比較小。
隨著專案的生命周期，位在元件内聚性張力圖的位置也會有所改變。
一般來説，初期時較傾向在三角形的右邊，此時犧牲的是重用。
隨著專案成熟度的提升，會開始向左滑動。
Conclusion
過去我們對於内聚性的觀點可能只是「一個模組只能執行一個功能」。
但元件内聚性的原則描述了一個更爲複雜的關係。
在選擇類別組合成元件時，必須考慮可重用性與可發展性的相對力量。
隨著專案的發展，這些組成是可能隨著時間推移而產生演變的。
ʕ •ᴥ•ʔ：重看無瑕程式碼架構篇，有了些與第一次看不一樣的感受。
最後的結論，就像是Shortie哥常說的：「任何事都有其trade-off」吧！