java設計模式、框架、架構、平臺之間的關係

    設計模式<框架<架構<平臺，從複用角度講，設計模式是代碼級複用、框架是模塊級複用、架構是系統級複用、平臺是企業應用級複用。

 

一、設計模式

爲何要先說設計模式？由於設計模式在這些概念中是最基本的，並且也比較簡單。那麼什麼是設計模式呢？說的直白點，設計模式就是告訴你針對特定問題如何組織類、對象和接口之間的關係，是前人總結的經驗。好比我要在代碼中實現一個全局惟一的配置類，那麼就使用Singleton模式。設計模式在實際編碼工做和設計框架時會被使用到，而更高層的架構和平臺則不會太關注它。

二、框架

作WEB開發接觸到最多的框架可數ORM框架，ORM框架只是全部數據關係映射框架的統稱，具體的如NHibernate、ActiveRecord等，框架是爲了解決特定問題而存在的，其它諸如模板框架、緩存框架，框架不能直接使用，須要二次開發。

三、架構

從大的層面來講，好比針對公司業務的B2C網站系統架構，裏面可能會用到多種解決各方面問題的框架，關注的是技術整合、擴展、可維護性。換個角度，在框架中也會涉及到架構問題，好比開發NHibernate框架，也須要考慮如何進行設計。

四、平臺

平臺的概念相似框架，但又結合的架構的考慮，它是更高層面上的「框架」，準確說是一種應用。它是針對企業用戶，爲解決企業業務須要而造成的產品。

1、設計模式（Design Patterns）

           模式：模式詳解—點擊打開連接                       

       設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石同樣。項目中合理的運用設計模式能夠完美的解決不少問題，每種模式在如今中都有相應的原理來與之對應，每個模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被普遍應用的緣由。

 

 

    設計模式的分類

整體來講設計模式分爲三大類：

建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行爲型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

其實還有兩類：併發型模式和線程池模式。用一個圖片來總體描述一下：

 

     設計模式的六大原則

一、開閉原則（Open Close Principle）

開閉原則就是說對擴展開放，對修改關閉。在程序須要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。因此一句話歸納就是：爲了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，咱們須要使用接口和抽象類，後面的具體設計中咱們會提到這點。

二、里氏代換原則（Liskov Substitution Principle）

里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類能夠出現的地方，子類必定能夠出現。 LSP是繼承複用的基石，只有當衍生類能夠替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。—— From Baidu 百科

三、依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，具體內容：真對接口編程，依賴於抽象而不依賴於具體。

四、接口隔離原則（Interface Segregation Principle）

這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。仍是一個下降類之間的耦合度的意思，從這兒咱們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，爲了升級和維護方便。因此上文中屢次出現：下降依賴，下降耦合。

五、迪米特法則（最少知道原則）（Demeter Principle）

爲何叫最少知道原則，就是說：一個實體應當儘可能少的與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。

六、合成複用原則（Composite Reuse Principle）

原則是儘可能使用合成/聚合的方式，而不是使用繼承。

 

（二）框架的基礎知識

 

(1)：框架是什麼？

java框架：三大框架詳解，其發展過程及掌握的Java技術慨括-點擊打開連接

簡單點說：框架就是能完成必定功能的半成品軟件，如今的結構是，Struts負責顯示層，Hibernate負責持久層，Spring負責中間的業務層，這個結構是目前國內最流行的Java Web應用程序架構了。

就其本質而言，框架是一個軟件，並且是一個半成品的軟件。所謂半成品，就是還不能徹底實現用戶須要的功能，框架只是實現用戶須要的功能的一部分，還須要進一步加工，才能成爲一個知足用戶須要的、完整的軟件。所以框架級的軟件，它的主要客戶是開發人員，而不是最終用戶。

有些朋友會想，既然框架只是個半成品，那何須要去學習和使用框架呢？學習成本也不算小，那就是由於框架能完成必定的功能，也就是這「框架已經完成的必定的功能」在吸引着開發人員，讓你們投入去學習和使用框架。

(2)：框架能幹什麼？

能完成必定功能，加快應用開發進度

        因爲框架完成了必定的功能，並且一般是一些基礎的、有難度的、通用的功能，這就避免咱們在應用開發的時候徹底從頭開始，而是在框架已有的功能之上繼續開發，也就是說會複用框架的功能，從而加快應用的開發進度。

給咱們一個精良的程序架構

        框架定義了應用的總體結構，包括類和對象的分割，各部分的主要責任，類和對象怎麼協做，以及控制流程等等。如今Java界大多數流行的框架，大都出自大師手筆，設計都很精良。基於這樣的框架來開發，通常會遵循框架已經規劃好的結構來進行開發，從而讓咱們開發的應用程序的結構也相對變得精良了。

 

(3)：對框架的理解

基於框架來開發，事情仍是那些事情，只是看誰作的問題

對於應用程序和框架的關係，能夠用一個圖來簡單描述一下，如圖1所示：

        若是沒有框架，那麼客戶要求的全部功能都由開發人員本身來開發，沒問題，一樣能夠實現用戶要求的功能，只是開發人員的工做多點。

        若是有了框架，框架自己完成了必定的功能，那麼框架已有的功能，開發人員就能夠不作了，開發人員只須要完成框架沒有的功能，最後一樣是完成客戶要求的全部功能，可是開發人員的工做就減小了。

        也就是說，基於框架來開發，軟件要完成的功能並無變化，仍是客戶要求的全部功能，也就是「事情仍是那些事情」的意思。可是有了框架事後，框架完成了一部分功能，而後開發人員再完成一部分功能，最後由框架和開發人員合起來完成了整個軟件的功能，也就是看這些功能「由誰作」的問題。

 

（三）架構

         軟件體系結構一般被稱爲架構，指能夠預製和可重構的軟件框架結構。架構尚處在發展期，對於其定義，學術界還沒有造成一個統一的意見，而不一樣角度的視點也會形成軟件體系結構的不一樣理解，如下是一些主流的標準觀點。
　　ANSI/IEEE 610.12-1990軟件工程標準詞彙對於體系結構定義是：「體系架構是以構件、構件之間的關係、構件與環境之間的關係爲內容的某一系統的基本組織結構以及知道上述內容設計與演化的原理(principle)」。
　　Mary Shaw和David Garlan認爲軟件體系結構是軟件設計過程當中，超越計算中的算法設計和數據結構設計的一個層次。體系結構問題包括各個方面的組織和全局控制結構，通訊協議、同步，數據存儲，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案之間進行選擇。Garlan & Shaw模型[1]的基本思想是：軟件體系結構={構件(component),鏈接件(connector)，約束(constrain)}．其中構件能夠是一組代碼，如程序的模塊；也能夠是一個獨立的程序，如數據庫服務器。鏈接件能夠是過程調用、管道、遠程過程調用(RPC)等，用於表示構件之間的相互做用。約束通常爲對象鏈接時的規則，或指明構件鏈接的形式和條件，例如，上層構件可要求下層構件的服務，反之不行；兩對象不得遞規地發送消息；代碼複製遷移的一致性約束；什麼條件下此種鏈接無效等。
　　關於架構的定義還有不少其餘觀點，好比Bass定義、Booch & Rumbaugh &Jacobson定義、Perry & Wolf模型[7]、Boehm模型等等，雖然各類定義關鍵架構的角度不一樣，研究對象也略有側重，但其核心的內容都是軟件系統的結構，其中以Garlan & Shaw模型爲表明，強調了體系結構的基本要素是構件、鏈接件及其約束（或者鏈接語義），這些定義大部分是從構造的角度來甚至軟件體系結構，而IEEE的定義不只強調了系統的基本組成，同時強調了體系結構的環境即和外界的交互。

        

 

（四）平臺

        java是一個能夠在不一樣操做系統（例如windows,unix等）上運行的編程語言，java平臺是指運行在各類終端（如pc、服務器、移動設備、嵌入式設備）的系統軟件。PC機上的java程序是用javaSE開發出來的，服務器端的java程序是用javaEE開發出來的，移動設備的java程序是用javaME開發出來的。

移動平臺：

        J2ME(Java 2 Micro Edition)是Java 2的一個組成部分，它與J2SE、J2EE並稱。根據Sun的定義：J2ME是一種高度優化的Java運行環境，主要針對消費類電子設備的，例如蜂窩電話和可視電話、數字機頂盒、汽車導航系統等等。J2ME技術在1999年的JavaOne Developer Conference大會上正式推出，它將Java語言的與平臺無關的特性移植到小型電子設備上,容許移動無線設備之間共享應用程序。

 

桌面應用平臺：

 

J2SE商業版本，標準版本 (Java2 Standard Edition) 定位在 客戶端，主要用於 桌面 應用軟件的編程。J2SE 包含那些構成Java語言核心的類。

 

企業級平臺：

       J2EE Java2平臺企業版（Java 2 Platform,Enterprise Edition），J2EE是一套全然不一樣於傳統應用開發的技術架構，包含許多組件，主要可簡化且規範應用系統的開發與部署，進而提升可移植性、安全與再用價值。J2EE核心是一組技術規範與指南，其中所包含的各種組件、服務架構及技術層次，均有共通的標準及規格，讓各類依循J2EE架構的不一樣平臺之間，存在良好的兼容性，解決過去企業後端使用的信息產品彼此之間沒法兼容，致使企業內部或外部難以互通的窘境。

（五）總

   

 1.框架與架構之間的關係

　　框架不是構架（即軟件體系機構）。體系結構肯定了系統總體結構、層次劃分，不一樣部分之間的協做等設計考慮。框架比架構更具體。更偏重於技術涉嫌。肯定框架後，軟件體系結構也隨之肯定，而對於同一軟件體系結構（好比Web開發中的MVC），能夠經過多種框架來實現。

2.框架與設計模式之間的關係　　設計模式和框架在軟件設計中是兩個不一樣的研究領域。設計模式研究的是一個設計問題的解決方法，一個模式可應用於不一樣的框架和被不一樣的語言所實現；而框架則是一個應用的體系結構，是一種或多種設計模式和代碼的混合體雖然它們有所不一樣，但卻共同致力於令人們的設計能夠被重用，在思想上存在着統一性的特色，於是設計模式的思想能夠在框架設計中進行應用。　　框架和設計模式存在着顯著的區別，主要表如今兩者提供的內容和致力應用的領域。　　1)從應用領域上分，框架給出的是整個應用的體系結構；而設計模式則給出了單一設計問題的解決方案，而且這個方案可在不一樣的應用程序或者框架中進行應用。　　2)從內容上分，設計模式僅是一個單純的設計，這個設計可被不一樣語言以不用方式來實現；而框架則是設計和代碼的一個混合體，編程者能夠用各類方式對框架進行擴展，進而造成完整的不一樣的應用。　　3)以第二條爲基礎，能夠得出設計模式比框架更容易移植：框架一旦設計成形，雖然尚未構成完整的一個應用，可是以其爲基礎進行應用的開發顯然要受制於框架的實現環境；而設計模式是與語言無關的，因此能夠在更普遍的異構環境中進行應用。　　總之，框架是軟件，而設計模式是軟件的知識體，提高框架的設計水平。