怎樣設計合適的介面(1) (轉)

怎樣設計合適的介面(1) (轉)[@more@]怎樣設計合適的介面(1)

[ 作者: 李煒   新增時間: 2001-9-3 8:06:50 ]


作者：李煒 北京傑合偉業公司產品技術部經理
來源:

摘要：我們在設計介面時，經常會遇到這樣的問題：
我們的介面應該提供多少方法才合適？
我們的介面應該提供"原子方法"還是"複合方法"？
我們的介面是否應該封裝（或者，能否封裝）所有的細節？
介面的設計需要考慮的使用習慣、使用的方便程度、使用的程度，根據我的，下面會詳細討論介面設計的2個需要權衡的方面：介面的單一化 & 複合化。
介面
介面提供了不同系統之間或者系統不同之間的界定。在軟體中，介面提供了一個屏障，從而從實現中分離目標，從具體中分離抽象，從作者中分離使用者。

站在使用者的角度看，一個介面建立並命名了一個目標的使用方法。一些（例如：編譯時的型別系統、執行時的異常機制及返回值）使得類作者的目的得以體現和加強。供給（affordances）指事物的被感知的真實的屬性，這些屬性可以決定事物使用的可能方法，供給提供了對事物操作的線索。

類設計者的一個職責便是在介面中減小約束與供給之間的隔閡、匹配目標以及一定程度上的自由度，儘可能減小錯誤使用目標物件的可能。

封裝
對於封裝來說，遠不止資料私有那麼簡單。在設計中，封裝往往會涉及到自我包含（self-containment）。如果一個類需要你知道如何它方法（e.g. 在一個執行緒的環境中，在一個方法呼叫後呼叫另一個方法，你必須明確地同步物件），那麼它的封裝性就不如將所有這些全部包含並隱藏的類（e.g. 這個類是thread-safe的）好。前一個設計存在著設計的，它的許多限定條件是模糊的，而且把部分責任推給了使用者，而不是讓類提供者做這些工作來完成類的設計。

在空間或者時間上分離方法的（例如，執行緒，方法呼叫，訊息佇列），能夠對設計的正確性和產生意義深遠的影響。這種分離帶來的結果是不可忽視的：

併發引入了不確定性和環境（context）選擇的開銷；
分佈引入了回撥的開銷，這些開銷可能不斷增加，而且會導致錯誤。
這些是設計的問題，修改它們可不是象修改那樣簡單。

如果一個介面主要由存取方法（set和get方法）組成，每個方法都相應的直接指向某個私有域，那麼它的封裝性會很差。介面中的域存取方法通常是不會提供資訊的：他們在物件的使用中不能通訊、簡單化和抽象化，這通常會導致程式碼冗長，並且容易出錯。

所以，我們首先考慮介面設計的第一個原則：

命令與查詢分離（Command-Query Separation）
要求：保證一個方法不是命令（Command）就是查詢（Query）

定義：
　　查詢：當一個方法返回一個值來回應一個問題的時候，它就具有查詢的性質；
　　命令：當一個方法要改變物件的狀態的時候，它就具有命令的性質；

通常，一個方法可能是純的Command或者是純的Query模式，或者是兩者的混合體。在設計介面時，如果可能，應該儘量使介面單一化，保證方法的行為嚴格的是命令或者是查詢，這樣查詢方法不會改變物件的狀態，沒有副作用（s effects），而會改變物件的狀態的方法不可能有返回值。也就是說：如果我們要問一個問題，那麼就不應該影響到它的答案。實際應用，要視具體情況而定，語義的清晰性和使用的簡單性之間需要權衡。

例如，在.util.Iterator中，hasNext可以被看作一種查詢，remove是一種命令，next合併了命令和查詢：
public interface Iterator{
boolean hasNext();
next();
void remove();
}




這裡，如果不將一個Iterator物件的當前值向前到下一個的話，就不能夠查詢一個Iterator物件。如果沒有提供一個複合方法next，我們將需要定義一系列的命令方法，例如：初始化（initialization）、繼續(continuation)、訪問(access)和前進(advance)，它們雖然清晰定義了每個動作，但是，客戶程式碼過於複雜：
for(initialization; continuation condition; advance){
... access for use ...
}




將Command和Query功能合併入一個方法，方便了客戶的使用，但是，降低了清晰性，而且，可能不便於基於斷言的設計並且需要一個變數來儲存查詢結果：
Iterator iterator = collection.iterator();
while(iterator.hasNext();){
Object current = iterator.next();
... use current...
}


下面，我們考慮介面設計的第二個原則：

組合方法（Combined Method）
組合方法經常線上程和分佈環境中使用，來保證正確性並改善效率。

一些介面提供大量的方法，起初，這些方法看來是最小化的，而且相關性強。然而，在使用的過程中，一些介面顯現得過於原始，它們過於簡單化，從而迫使類使用者用更多的工作來實現普通的任務，並且，方法之間的先後順序及依賴性比較強（即，暫時耦合）。這導致了程式碼重複，而且非常麻煩和容易出錯。

一些需要同時執行成功的方法，在多執行緒、異常、和分佈的情況下會遇到麻煩。如果兩個動作需要同時執行，它們由兩個獨立的方法進行描述，必須都完全成功的執行，否則會導致所有動作的回滾。

執行緒的引入使這種不確定性大大增加。一系列方法同時呼叫一個易變的(mutable)物件，如果這個物件線上程之間共享，即使我們假設單獨的方法是執行緒安全的，也無法確保結果是意料之中的。看下面對Event 的介面，它允許安置控制程式碼和對事件的查詢：
interface EventSource{
Handler getHandler(Event event);
void installHandler(Event event, Handler newHandler);
}




執行緒之間的交叉呼叫可能會引起意想不到的結果。假設source域引用一個執行緒共享的物件，物件很可能在1、2之間被另一個執行緒了一個新的控制程式碼：
class EventSourceExample{
public void example(Event event, Handler newHandler){
oldHandler = eventSource.getHandler(event);    // 1
//物件很可能在這裡被另一個執行緒安裝了一個新的控制程式碼
eventSource.installHandler(event, newHandler);  // 2
}
private EventSource eventSource;
private Handler oldHandler;
}