兩種不同的程式碼行為模式

雖然不知道這是什麼,但是在程式碼行為上很明確地可以被區分成二種不同的"行為模式"(行為模式is?).舉例來說的話一個主介面包含多個子介面,當顯示不同的子介面的時候,要求主介面的某些屬性也要發生改變.所以應該怎麼來處理這樣的情況呢?   

1. 通知主介面,讓主介面自己管理
   在這種情況下,子介面無需知曉主介面任何API,當子介面被開啟顯示的時候,僅是告訴主介面該子介面被顯示了,然後主介面根據當前的介面來改變自己的屬性;當子介面被關閉隱藏的時候,同樣的道理,也僅是告訴主介面該子介面被關閉了,然後主介面根據當前被關閉的介面來改變自己的屬性.
   這樣做的好處是:程式碼剝離會很清楚,程式碼耦合低,但是可能寫起來需要系統地考慮之後再來組織程式碼,後續維護的時候也需要多盯一下程式碼,因為子介面開啟時顯示的元素並不是由自己直接控制的,而是由主介面直接控制的.
   
2. 主介面提供介面,子介面來管理
   這種情況下,主介面需要暴露大量的API給子介面,子介面顯示或隱藏的時候,自己呼叫主介面方法控制主介面的元素變化.這是大多數情況下信手拈來的行為模式.
   這樣寫的好處是:邏輯比較清楚,子介面顯示/隱藏都是在由子介面來管理,所以邏輯上感覺很順.但是這樣的程式碼耦合高,並且當子介面較多時會比較亂,尤其是多個人在維護一份程式碼的時候.
3. 兩種模式之比較
   在我看來,如果用吃飯打比方的話,主介面好比餐廳,子介面好比不同的顧客,在第一種模式下,顧客只用進入餐廳吃飯(開啟顯示子介面),吃完飯之後付賬走人(關閉隱藏子介面),其他的諸如提供餐具,食物,打掃之類的都由餐廳來負責.而在第二種情況下,好比吃自助餐,每個顧客要自己拿盤子,拿食物,最後打掃.第一種模式體驗好,但是要付出更高的花費,第二種模式靈活直接,但是多人就餐之後可能會比較雜亂.
   除此之外,也可能有二種模式混用的情況,比如有些元素是主介面來控制,而有些元素是子介面來靈活排程,但二種模式不控制好的話,我想更容易產生糟糕的程式碼吧.
   最後一點,要說的是無論是哪種情況都要在子介面關閉隱藏之後做好清理和還原工作,清理和還原無論是在UI上還是在邏輯中,無論在何種情況下都是有必要去進行的.