軟件接口設計
讀後記：接口--->對象之間建立連接，指的是進行連接而設計的指定方法；
java中的interface是爲了更好的完成這種連接【多態連接】而定義的一種語法支持；
相對於抽象類，抽象類一般在多重繼承結構下，抽象類去實現接口並具體實現部分方法..
《構建可擴展的Web站點》主要介紹了Web應用程序的概念、體系結構、硬件需求、開發環境的原則及國際化、本地化和Unicode等基本內容，本文是軟件接口設計。
軟件接口設計
Software Interface Design
將軟件分層意味着我們需要完成額外的工作——設計層次之間的接口。我們原來擁有的是一大塊代碼，現在則會有三處不同的代碼塊（業務邏輯、交互邏輯和標記），它們當中的每一塊都需要和下一塊交流。但是仔細考慮一下這樣做是否的確造成了額外的工作？答案十有八九是否定的：分析一下我們現在僅有的那一層代碼，會發現這些附加勞動早就完成了，只有邏輯層和標記層之間的交流還不是很明確，和其他剩餘代碼混在了一起。
爲什麼要花心思在分層上呢？不管怎麼說，在某種程度上，原來的那種所有代碼都粘在一起的程序風格還是可以工作的。然而，有幾個決定性的因素，它們將我們引向分層實現，而且隨着系統規模逐步擴大，這些因素會一個比一個地變得更爲重要。層次分離，讓不同的工程師或工程師小組可以同時工作在系統的不同層次，而不用擔心無意中影響了他人的工作。除了工作對象變成了不同的物理文件之外，這些小組也不再需要對其他層次有深入瞭解。標記層的工作人員不必理解數據是如何從數據存儲中取出，並且傳給模板系統的，他們只需要知道一旦這些數據交付給了他們，應該如何去使用這些數據。
類似的，工作重點在交互層邏輯的工程師也不需要理解在取得一條數據的背後，系統邏輯層是如何運作的，而只需要知道用相應的函數調用就可以了。在這些例子中，工程師們惟一需要關注的元素就是自己所在層次的內容和所在層次與上層和下層的接口。那麼，我們一直談論的接口到底是什麼呢？要知道當我們談的是軟件層次之間的接口時，所指的並不是Java中的面向對象概念上的接口。我們所說的接口，描述的是允許一個層次和另一個層次之間交換請求和響應的一組特性。對數據層與系統邏輯層而言，接口包括對原始數據的存儲和抽取。對交互邏輯層與系統邏輯層，接口包括對特定類型數據源的修改。接口僅僅定義一個層次如何向另一個層次發出請求，要求它執行一個任務，而不管這個任務如何執行。
我們的應用程序中最爲頂端的層次是比較不一樣的，因爲標記層與表現層之間的接口已經由我們所採用的技術定義好了。標記層到樣式表的鏈接使用的是鏈接標記符或者@import語句，通過它們獲得class和id屬性，以及樣式表中的命名的標記符序列，根據這些可以應用特定的樣式規則。爲了保持良好的層次分離，在標記層中應儘量避免直接使用樣式屬性。本書並不包含前端工程的內容，但前端分層的原因和後端分層的原因是相同的——分離樣式層與標記層，才能讓不同團隊可以獨立地工作於項目的不同方面，並且開發人員可以進行層次內部修改，而不用擔心影響相鄰層次。
交互邏輯層和標記層進行交流的典型方式是模板系統。在PHP和Smarty參考實現中，Smarty爲PHP交互邏輯層提供若干功能。我們可以調用 Smarty的方法來將數據導出到模板（繼而用於輸出），也可以調用Smarty的方法來提供在模板內執行的展現函數，甚至還可以自己直接渲染模板。在某些情況下，我們需要的並不是直接得到模板的輸出，然後將輸出發送給終端用戶。比如在發送電子郵件的時候，我們可以在模板系統中爲它創建一個模板，導出所需要的數據和功能，把這個模板渲染到交互邏輯層的一個變量中，然後發送這封郵件。採用這種做法時，要注意到數據與控制不僅是單向流動的，控制在所有層次之間都可以雙向傳遞。
兩個邏輯層之間的接口，根據具體實現，很可能是最容易理解的，也是最難以設計的。如果兩個層次使用的是同一種語言，接口可能只是一組函數。這時，接口的設計包括決定命名方案（用於函數命名）、調用方案（用於加載正確的庫，以使函數可用），以及數據方案（用於將數據向前或向後傳輸）。所有這些方案都算在系統邏輯層邏輯模型的概要設計中。我喜歡將可能的設計選擇畫成一個連續的光譜圖，稱之爲網絡應用犯傻程度：
OGF <---------- 心智健全----------> 面向對象程序設計
這個光譜往左是單個的巨型函數，往右則接近面向對象程序設計。老式的、單一的Perl系統在光譜中非常靠左，而Zope和Plone的位置在右邊。更爲有趣的一些模型則沿光譜分佈，其中MVC羣體集中在中心三分之一處。像Struts和Rails這一類的框架，則分佈在右側靠近Zope的地方（這提醒了你接下來會發生什麼）。Flickr在中間稍偏左，它採用類似MVC的方式，但沒有使用框架，隨着時間的推移和系統的越來越複雜，它也逐漸向右偏移。
你選擇定位在光譜上的哪一個位置進行工作，那完全是個人偏好問題。往右走，就以靈活性爲代價，獲得可維護性。往左走，就喪失可維護性，獲得靈活性。偏離中心越遠，優化系統就會越困難，但系統架構就會越簡單。當前趨勢是明確地遠離左側，而中右側的框架越來越受到歡迎。但始終要牢記，你往一個方向移動，並獲得某種好處的同時，也會失去一些別的東西。
堆棧最底部的層次總有定義比較完美的接口，因爲它們物理上是分離的——你總不會想用PHP來實現自己的數據庫吧？所以這一塊的接口定義和層次分離總是以抽象層次的形式發生在應用程序代碼內部。業務邏輯層沒有必要知道物理上如何連接到數據庫集羣，但是建立連接的代碼需要知道如何連接。分離的數據庫與存儲層從系統邏輯層獲取指令，連接到數據存儲，執行指令並返回結果。例如，業務邏輯層可能知道它需要執行一些SQL語句，並知道需要在哪個集羣上執行這些語句，它就可以進行如下調用：
$result = db_query('my_cluster', 'SELECT * FROM Frobs;')
接下來就是存儲層的責任了，它的代碼要連接到正確的服務器，執行命令並返回結果。執行查詢的服務器可能發生變化（交換硬件時），可能被複制（也許用於冗餘故障轉移），可能被記入日誌並進行基準測試（參閱第8章中的MySQL小節），或者執行任何我們決定的操作。這個例子中的接口是db_query( )函數和它的夥伴們。對於文件存儲層而言，接口中可能包含store_file( )函數，給它傳入文件名後，接着就由它來表演魔術了。這個魔術本身怎樣和系統邏輯層無關，我們只要執行了需要的調用，就能得到需要的結果。
接口設計在Web應用程序體系結構中扮演着最主要的角色。接口會隨着時間而演變，接口變動時，負責不同層次工作的團隊必須得進行協商，但是這些更改應該只牽涉到小部分當前開發的內容。在不會無意中破壞其他部分的情況下，我們能在單個層次內做的越多，生產效率就越高，靈活性也越高。