軟件的架構與模式之經典架構模式簡介
根據Linda Rising的《Pattern Almanac》一書，已知的架構模式有七十多種。這是一個只多不少的統計，其中包括了很多通常認爲是設計模式的模式，比如Bridge，Facade，Interpreter，Mediator等模式通常認爲是設計模式，但是在許多情況下，也可以作爲架構模式出現，因此也常常被當作架構模式。
Layers架構模式
在收集到用戶對軟件的要求之後，架構設計就開始了。架構設計一個主要的目的，就是把系統劃分成爲很多"板塊"。劃分的方式通常有兩種，一種是橫向的劃分，一種是縱向劃分。
橫向劃分將系統按照商業目的劃分。比如一個書店的管理系統可以劃分成爲進貨、銷售、庫存管理、員工管理等等。
縱向劃分則不同，它按照抽象層次的高低，將系統劃分成"層"，或叫Layer。比如一個公司的內網管理系統通常可以劃分成爲下面的幾個Layer:
一、網頁，也就是用戶界面，負責顯示數據、接受用戶輸入；
二、領域層，包括JavaBean或者COM對象、B2B服務等，封裝了必要的商業邏輯，負責根據商業邏輯決定顯示什麼數據、以及如何根據用戶輸入的數據進行計算；
三、數據庫，負責存儲數據，按照查詢要求提供所存儲的數據。
四、操作系統層，比如Windows NT或者Solaris等
五、硬件層，比如SUN E450服務器等
有人把這種Layer叫做Tier，但是Tier多帶有物理含義，不同的Tier往往位於不同的計算機上，由網絡連接起來，而Layer是純粹邏輯的概念，與物理劃分無關。
Layers架構模式的好處是：
第一、任何一層的變化都可以很好地侷限於這一層，而不會影響到其他各層。
第二、更容易容納新的技術和變化。Layers架構模式容許任何一層變更所使用的技術
Fa?ade架構模式
外部與一個子系統的通訊必須通過一個統一的門面（Facade）對象進行，這就是Facade模式。
現代的軟件系統都是比較複雜的，設計模式的任務就是協助設計師處理複雜系統的設計。
設計師處理複雜系統的一個常見方法便是將其"分而治之"，把一個系統劃分爲幾個較小的子系統。但是這樣做了以後，設計師往往仍然會發現一個子系統內仍然有太多的類型要處理。而使用一個子系統的使用端往往只關注一些特定的功能，卻要同時與子系統內部的許多對象打交道後才能達到目的，請見下面的對象圖。
 圖4、Facade架構模式的結構圖。 |
這就是一種不便，它使得系統的邏輯變得不必要的複雜，維護成本提高，複用率降低。
用一個範例說明，中國大陸的醫院便是一個子系統，按照部門職能，這個系統可以劃分爲掛號、門診、劃價、化驗、收銀、取藥等。看病的病人要與這些部門打交道，就如同一個子系統的使用端與一個子系統的各個類型打交道一樣，不是一件容易的事情。
首先病人必須先掛號，然後門診。如果醫生要求化驗，病人必須首先劃價，然後繳款，才能到化驗部門做化驗。化驗後，再回到門診室，請見下面的對象圖。
 圖5、描述病人在醫院裏的體驗。圖中的方框代表醫院。 |
解決這種不便的方法便是引進Facade模式。仍然通過醫院的範例說明，可以設置一個接待員的位置，由接待員負責代爲掛號、劃價、繳費、取藥等。這個接待員就是Facade模式的體現，病人只接觸接待員，由接待員負責與醫院的各個部門打交道，請見下面的對象圖。
Facade模式要求一個子系統的外部與其內部的通訊必須通過一個統一的門面（Facade）對象進行。Facade模式提供一個高等級的接口，使得子系統更易於使用。
使用了Facade模式之後，本章的第一個圖中所描述的一個子系統的使用端對象所面對的複雜關係就可以簡化爲下面這個樣子。
 圖7、Facade架構模式的結構圖 |
描述經過Facade模式的改裝後，一個子系統的使用端與子系統的關係。圖中的大方框代表一個子系統。
就如同醫院的接待員一樣，Facade模式的門面類型將使用端與子系統的內部複雜性分隔開，使得使用端只需要與門面對象打交道，而不需要與子系統內部的很多對象打交道。
Mediator架構模式
Mediator模式包裝了一系列對象相互作用的方式，使得這些對象不必互相明顯參照；從而使它們可以較鬆散地耦合。當這些對象中的某些對象之間的相互作用發生改變時，不會立即影響到其它的一些對象之間的相互作用；從而可以保證這些相互作用可以彼此獨立地變化。
在下面的示意圖中有大量的對象，這些對象既會影響別的對象，又會被別的對象所影響，因此常常叫做同事（Colleague）對象。這些同事對象通過彼此的相互作用形成系統的行爲。從圖中可以看出，幾乎每一個對象都需要與其它的對象發生相互作用，而這種相互作用表現爲一個對象與另一個對象的直接耦合。
 圖8、這是一個過度耦合的系統 |
通過引入調停者對象（Mediator），可以將系統的網狀結構變成以中介者爲中心的星形結構，如下圖所示。在這個星形結構中，同事對象不再通過直接的聯繫與另一個對象發生相互作用；相反地，它通過調停者對象與另一個對象發生相互作用。調停者對象的存在保證了對象結構上的穩定，也就是說，系統的結構不會因爲新對象的引入造成大量的修改工作。
 圖9、這是一個使用了Mediator架構模式之後的結構圖 |
比較傳統的設計方法，面嚮對象的技術可以更好地協助設計師管理更爲複雜的系統。一個好的面向對象的設計可以使對象之間增加協作性（Collaboration），減少耦合度（Coupling）。一個深思熟慮的設計會把一個系統分解爲一羣相互協作的同事對象，然後給每一個同事對象以獨特的責任，恰當的配置它們之間的協作關係，使它們可以在一起工作。
在Mediator模式中，所有的成員對象都可以協調工作，但是又不直接相互管理。這些對象都與一個處於中心地位的調停者對象發生緊密的關係，由這個調停者對象進行協調工作。這個協調者對象叫做調停者（Mediator），而調停者所協調的成員對象稱做同事（Colleague）對象。
在Colleague對象內部發生的事件會影響到所有的同事，但是這種影響不是以直接管理的方式直接傳到其它的對象上的。記住在小組的成員增加時，這樣的相互作用關係是以比指數更快的方式增加的。相反，這種影響僅僅直接影響到調停者對象，而調停者對象反過來會協調其它的同事，形成整個系統的行爲。
如果小組的成員增加時，調停者對象可能會面臨修改，而其它的同事則可以裝做不知道這個新的成員一樣，不必修改。反過來，如果小組的成員之一被從系統中刪除的話，調停者對象需要對此做出修改，而小組中其它的同事則不必改動。
Interpreter架構模式
給定一個語言之後，Interpreter模式可以定義出其文法的一種表示，並同時提供一個直譯器；使用端可以使用這個直譯器來解釋這個語言中的句子。
如果某一類型問題一再地發生的話，那麼一個有意義的做法就是將此類型問題的各個實例表達爲一個簡單語言中的語句。這樣就可以建造一個直譯器，通過解釋這些語句達到解決問題的目的。
例如，依照一個匹配模式搜尋字符串便是一個常見的問題。與其爲每一個匹配模式建造一個特定的算法，不如建造一個一般性的算法處理各種常規表達式。當接到一個指定的常規表達式時，系統使用一個直譯器解釋這個常規表達式，從而對字符串進行匹配。
再比如VBA（Visual Basic for Applications）就不僅僅出現在微軟的Office系列軟件中，並且可以供第三廠家出產的軟件嵌入使用；Crystal Reports報表生成軟件也包括了一個便於使用的宏語言，使用戶可以執行較爲複雜的命令操作。一般而言，將VBA或者其它的語言軟件嵌入到自己的軟件產品中，可以使產品定製化（Customization）能力大大增強，但是這些宏語言引擎往往都很昂貴。
現在要介紹的Interpreter模式將描述怎樣在有了一個簡單的文法後，使用模式設計解釋這些語句。熟悉了這個模式以後，一個沒有接收過形式語言和編譯器的正規訓練的設計師也可以自行設計一個簡單的直譯器，以便爲使用端提供一個簡單語言，或者在系統內部使用一個簡單語言描述一個合適的問題