小談子物件中介面的設計原則

今天和同事在討論介面的設計原則的時候，總結了乙個原則點。雖然簡單，也拿出來和大家一起分享。

物件在實現介面的同時，由於需要提供訪問子介面的服務。最正常的設計可能是下面的。

但是，如果是另外乙個情況呢？看看下面的組合方式吧：

事情變得有點有趣了。往往就是這樣，只有乙個的時候，沒有人會懷疑。只有出現多個的時候，爭吵才開始了。所謂乙個和尚挑水喝，兩個和尚抬水喝，三個和尚沒水喝。要我看來，乙個和尚是多麼的孤獨？三個和尚雖然沒水喝，可是有得吵鬧，豈不是正得設計的樂趣？

初步看起來，這兩種設計中，第二種有著明顯的不合理。因為這樣，層次就變得混亂。而且父物件若是要越過子介面，訪問一些實現上的細節，那麼就更加麻煩了！

前一段時間，我花很大時間去尋找方法，來通過介面指標返回物件指標(delphi)，現在想來，這個技術剛好是第二種設計的技術補充啊。反過來，我卻忽略了設計上的原則。第二種方式既然存在，那麼它是不是也有存在的理由。

那麼，什麼時候適合第一種方式，什麼時候適合第二種方式呢？

我們討論的時候，總結了乙個簡單的原則：

如果子物件是父物件聚合的，且這個子物件公布的介面服務中，不存在更新服務。說白了，就是說這個介面的屬性是唯讀的。那麼建議使用第一種方式設計。

反過來，如果這個介面屬性，存在「寫方法」，那麼父物件一定不能引用物件，因為父物件並不知道子介面到底是由哪個類來實現的。跨越介面去訪問介面，那是必然有問題的。所以這個時候應該採用第二種方式。當然了，這個時候，往往就需要對介面的設計提出很高的要求。

說到最後，就是介面本身的設計了，那一定是乙個非常艱難的過程了。一定不是簡單原則所能解決的了。