介面為OO中不可或缺的標準化規範，當有類別需要共同遵循每些規範時，我們變可以使用介面來制訂出這些規則，之後再交由下層的類別實做以確保這些類別會共同遵循介面所開之規範。如此，以後就可以利用介面來操作物件。這也就是design pattern中一直強調的『針對介面撰寫程式，避免針對具象類別撰寫程式』。
快速瀏覽的標準規範。在上一篇中說過abstract class，其關鍵在於類別內會有abstract method，在interface中有點類似，但介面中的method全部都是abstract method，簡單來說就是『只定義不實做』，它只規範了要有什麼，但並不實做這些東西。另外，介面中的屬性全部都會在開頭加上static final，static代表屬性是屬於class level也就是介面所有，而非instance level(因為介面跟抽象類別一樣都沒辦法產生實體物件，既然沒辦法產生，當然也就不可能有instance level的屬性出現)；而final代表屬性一定是常數，其內容不能再更動，為什麼會是常數呢？試想既然介面是大家要共同實做遵循的規範，那其中的資料就是大家要共同參考或存取的資訊，當然不能被其他人修改而影響到他人囉！用這樣的觀點來想或許會比較容易一點。
對介面撰寫程式，是彈性化的好幫手。在寫程式的過程請記得針對介面寫程式，避免去面對到底層的具象類別(concrete class)，為什麼要如此呢？原因很簡單，這樣對底層的抽換會比較容易，舉例而言如果今天要將資料輸出，在介面中只要有一個outputData的函式，而底層可以實做一個是將資料存到資料庫的類別，另一個是將資料存到檔案的類別，如此當底層的模式抽換時，並不會影響外部的使用者的操作方式，對他們而言就是呼叫outputData就可以了，這種方式在設計模式中我們通常可以稱為依賴性注入(Dependency Injection)。以下例而言：
interface DataProcessor {
bool outputData(String data);
}
class DBProcessor implements DataProcessor {
//override
bool outputData(String data) {
write to DB code…
}
}
class FileProcessor implements DataProcessor {
//override
bool outputData(String data) {
write to file code…
}
}
class Test {
public static void main(String[] args) {
Test t = new Test();
t.outputData(“hello world”);
}
//針對介面操作，避免直接操作實體
public outputData(DataProcessor dp) {
dp.outputData();
}
}
清楚的規範介面是複雜大型系統必要的溝通之道！在一個大型系統中，往往會牽連到很多的函式呼叫或資料溝通，我想一開始應該從整的面向來考量，把互相溝通的介面跟接口的api訂清楚是很重要的事情。雖然，這裡所說的介面跟上述java中的介面不太一樣。但道理想同也就是先把大家該遵循的規格開出來，這樣就可以依據這個規格開始做許多的測試，並且可針對這些內容先製作假資料開始進行自己的程式撰寫。只要介面的定義夠明確，自己內部的運作方式並不會影響到整體的系統運作，所以介面的規範對大系統的整體輪廓的檢視跟確認有極大的幫助，先從大處著眼，在細分到小處著手。一個好的程式設計師或架構師應該能快速的將程式介面開立完畢，並且清楚的分配到不同的實做工程師去把內部的程式細節加以處理。換個角度想，像google maps也有抽出許多api讓其他人去介接，其實對外部使用者而言，這就是跟google maps底層溝通的介面，所以介面定義夠清楚時一切的運作將會變得更輕鬆，如此google maps底層的效能若改良，對外不而言只會感受到速度變快，其它的實做一個字也不需要更動，概念跟OO的封裝有點相似。很多概念其實都是相通的，讀者可以自己體會看看，許多名詞都只是幫助我們理解而已，但不同領域或不同章節中會用不同的名詞來形容，其實核心的概念都差不多，如果一昧的將定義背熟而已那其實是沒有多大意義存在～～
communication with interface, this world will be more clear and simple.
留言列表
