邊界

使用第三方軟體的程式碼

在 介面的提供者 & 介面的使用者 之間，存在一股張力。 第三方套件、框架努力讓自己本身更泛用，更能夠建立在不同環境中，吸引更多的使用者。 而另一方面，使用者希望介面專注於需求上。 這種張力會導致問題。

以java.util.Map 為例，它是個有豐富功能的介面，並且可以存放任何型態的內容，但有時我們只想使用部分功能或存放特定的型態。

關於型態的部分，可以利用泛型(generics)去處理。

關於功能的限制，可以另外將Map 封裝起來，只將想提供的功能介面給放出來。

在使用這樣的介面時，建議放在類別裡，或是放在附近的類別家族裡。避免在公用API裡回傳介面，或將介面當參數傳遞給API。

探索及學習邊界

為了使用第三方軟體，我們可能會花很多時間在閱讀文件上，然後才決定要如何使用。 接著我們在原來的程式中，使用第三方的軟體，看是否如預期執行。

但如果換一種方式呢?

學習式測試

雖然測試第三方軟體並不是我們的工作，但為了確認API的功能，和增加對其的了解，撰寫這樣的測試是有幫助的。 利用這樣的測試，去探索、了解第三方軟體，就叫做學習式測試(learning tests)。

在學習式測試裡，我們比照在應用程式裡呼叫的用法，來呼叫第三方的軟體API。 我們實質上是在做控制實驗，以檢驗我們對這個API的了解程度。 測試的重點在於，我們想要利用API獲得怎樣的結果。

建置測試案例

關於測試的部分，請去看 Test > JUnit 的部分，那邊有教學如何建置測試案例。 https://wujincheng.gitbooks.io/brian/content/junit.html

學習式測試比不花功夫好

學習式測試並不花什麼功夫。因為不管怎樣，都必須學會這個API，而寫測試來了解，是一種簡單又沒有壞處的方式。 學習式測試是一種很精準的試驗，可以幫助我們對API的瞭解。

學習式測試不僅沒花什麼功夫，還是個正向投資，當第三方套件有版本更新的時候，可以執行這些學習式測試，來觀察這些套件有沒有行為上的改變。

學習式測試可以幫助我們驗證第三分軟體是否按照預期執行。一旦整合進來，沒有人可以擔保該軟體會一直相容於我們的需求。倘若第三方套件的修改，無法通過我們的測試，我們就能馬上發現出問題了。

不管是否使用學習式測試，還是需要有一套「與生產程式碼採用相同方式的邊界測試」來支援整潔的介面。 如果沒有這些邊界測試，來減輕升級整合帶來的負擔，那會使停留在舊版本的時間，本應該停留的時間還長。

使用尚未存在的程式

還有一種邊界，一種將已知和未知分開的邊界。

例如:要使用還沒開發出來的子系統。

這種狀況，我們就只觀察到已知的邊界就好。

但在工作上，我們可以想像、希望那個邊界的介面長什麼樣子。 為了避免我們因為其他未完成的部分而受困，我們可以定義自己的介面，規劃出我們的主要功能，並規劃出一個拿來介接的接縫(seam)。 採用這樣的設計，也對測試很方便，它可以用一個假的物件，就可以測試我們的東西。當我們獲得完成的介面時，也可以產生邊界測試，確保我們有正常使用。

簡潔的程式邊界

有趣的事情會發生在邊界上，改變 就是其中一項。 好的軟體設計可以適應這些改變，而不需要大規模的投入或重新撰寫。 當使用我們無法控制的程式碼時，要特別花功夫去保護已經投入的心力，確保不用花太多功夫，就能因應未來的改變。

在邊界的程式碼必須分割清楚，並定義預期的測試。最好是依靠在自己可以控制的程式上，去利用第三方套件，將其封裝起來。