• <menu id="gyiem"><menu id="gyiem"></menu></menu>
  • <menu id="gyiem"><code id="gyiem"></code></menu>

    Java設計模式(十三) 別人再問你設計模式,叫他看這篇文章

    原創文章,轉載請務必將下面這段話置于文章開頭處(保留超鏈接)。
    本文轉發自技術世界原文鏈接 http://www.luozeyang.com/design_pattern/summary/

    OOP三大基本特性

    封裝

    封裝,也就是把客觀事物封裝成抽象的類,并且類可以把自己的屬性和方法只讓可信的類操作,對不可信的進行信息隱藏。

    繼承

    繼承是指這樣一種能力,它可以使用現有的類的所有功能,并在無需重新編寫原來類的情況下對這些功能進行擴展。

    多態

    多態指一個類實例的相同方法在不同情形有不同的表現形式。具體來說就是不同實現類對公共接口有不同的實現方式,但這些操作可以通過相同的方式(公共接口)予以調用。

    OOD大原則

    面向對象設計(OOD)有大原則(是的,你沒看錯,是七大原則,不是六大原則),它們互相補充。

    開-閉原則

    Open-Close Principle(OCP),即開-閉原則。開,指的是對擴展開放,即要支持方便地擴展;閉,指的是對修改關閉,即要嚴格限制對已有內容的修改。開-閉原則是最抽象也是最重要的OOD原則。簡單工廠模式工廠方法模式抽象工廠模式中都提到了如何通過良好的設計遵循開-閉原則。

    里氏替換原則

    Liskov Substitution Principle(LSP),即里氏替換原則。該原則規定“子類必須能夠替換其父類,否則不應當設計為其子類”。換句話說,父類出現的地方,都應該能由其子類代替。所以,子類只能去擴展基類,而不是隱藏或者覆蓋基類。

    依賴倒置原則

    Dependence Inversion Principle(DIP),依賴倒置原則。它講的是“設計和實現要依賴于抽象而非具體”。一方面抽象化更符合人的思維習慣;另一方面,根據里氏替換原則,可以很容易將原來的抽象替換為擴展后的具體,這樣可以很好的支持開-閉原則。

    接口隔離原則

    Interface Segration Principle(ISP),接口隔離原則,“將大的接口打散成多個小的獨立的接口”。由于Java類支持實現多個接口,可以很容易的讓類具有多種接口的特征,同時每個類可以選擇性地只實現目標接口。

    單一職責原則

    Single Responsibility Principle(SRP),單一職責原則。它講的是,不要存在多于一個導致類變更的原因,是高內聚低耦合的一個體現。

    迪米特法則/最少知道原則

    Law of Demeter or Least Knowledge Principle(LoD or LKP),迪米特法則或最少知道原則。它講的是“一個對象就盡可能少的去了解其它對象”,從而實現松耦合。如果一個類的職責過多,由于多個職責耦合在了一起,任何一個職責的變更都可能引起其它職責的問題,嚴重影響了代碼的可維護性和可重用性。

    合成/聚合復用原則

    Composite/Aggregate Reuse Principle(CARP / CRP),合成/聚合復用原則。如果新對象的某些功能在別的已經創建好的對象里面已經實現,那么應當盡量使用別的對象提供的功能,使之成為新對象的一部分,而不要再重新創建。新對象可通過向這些對象的委派達到復用已有功能的效果。簡而言之,要盡量使用合成/聚合,而非使用繼承。《Java設計模式(九) 橋接模式》中介紹的橋接模式即是對這一原則的典型應用。

    設計模式

    什么是設計模式

    可以用一句話概括設計模式———設計模式是一種利用OOP的封閉、繼承和多態三大特性,同時在遵循單一職責原則、開閉原則、里氏替換原則、迪米特法則、依賴倒置原則、接口隔離原則及合成/聚合復用原則的前提下,被總結出來的經過反復實踐并被多數人知曉且經過分類和設計的可重用的軟件設計方式。

    設計模式十萬個為什么

    為什么要用設計模式

    • 設計模式是高級軟件工程師和架構師面試基本必問的項目(先通過面試進入這個門檻我們再談其它)
    • 設計模式是經過大量實踐檢驗的安全高效可復用的解決方案。不要重復發明輪子,而且大多數時候你發明的輪子還沒有已有的好
    • 設計模式是被主流工程師/架構師所廣泛接受和使用的,你使用它,方便與別人溝通,也方便別人code review(這個夠實在吧)
    • 使用設計模式可以幫你快速解決80%的代碼設計問題,從而讓你更專注于業務本身
    • 設計模式本身是對幾大特性的利用和對幾大設計原則的踐行,代碼量積累到一定程度,你會發現你已經或多或少的在使用某些設計模式了
    • 架構師或者team leader教授初級工程師設計模式,可以很方便的以大家認可以方式提高初級工程師的代碼設計水平,從而有利于提高團隊工程實力

    是不是一定要盡可能使用設計模式

    每個設計模式都有其適合范圍,并解決特定問題。所以項目實踐中應該針對特定使用場景選用合適的設計模式,如果某些場景下現在的設計模式都不能很完全的解決問題,那也不必拘泥于設計模式本身。實際上,學習和使用設計模式本身并不是目的,目的是通過學習和使用它,強化面向對象設計思路并用合適的方法解決工程問題。

    設計模式有時并非最優解

    有些人認為,在某些特定場景下,設計模式并非最優方案,而自己的解決方案可能會更好。這個問題得分兩個方面來討論:一方面,如上文所述,所有設計模式都有其適用場景,“one size does not fit all”;另一方面,確實有可能自己設計的方案比設計模式更適合,但這并不影響你學習并使用設計模式,因為設計模式經過大量實戰檢驗能在絕大多數情況下提供良好方案。

    設計模式太教條化

    設計模式雖然都有其相對固定的實現方式,但是它的精髓是利用OOP的三大特性,遵循OOD七大原則解決工程問題。所以學習設計模式的目的不是學習設計模式的固定實現方式本身,而是其思想。

    我有自己的一套思路,沒必要引導團隊成員學習設計模式

    設計模式是被廣泛接受和使用的,引導團隊成員使用設計模式可以減少溝通成本,而更專注于業務本身。也許你有自己的一套思路,但是你怎么能保證團隊成員一定認可你的思路,進而將你的思路貫徹實施呢?統一使用設計模式能讓團隊只使用20%的精力決解80%的問題。其它20%的問題,才是你需要花精力解決的。

    Java設計模式系列

    郭俊 Jason wechat
    歡迎關注作者微信公眾號【大數據架構】
    您的贊賞將支持作者繼續原創分享
    速赢彩app 兴化 | 慈溪 | 娄底 | 寿光 | 漯河 | 湖南长沙 | 泉州 | 枣阳 | 黄石 | 宁波 | 象山 | 建湖 | 桐城 | 中卫 | 徐州 | 中卫 | 佳木斯 | 亳州 | 清远 | 承德 | 正定 | 四川成都 | 基隆 | 七台河 | 灌云 | 仁寿 | 潮州 | 永州 | 沛县 | 燕郊 | 琼中 | 改则 | 开封 | 遂宁 | 中山 | 铁岭 | 湛江 | 宝鸡 | 阿勒泰 | 龙岩 | 金坛 | 保亭 | 钦州 | 燕郊 | 陕西西安 | 黄山 | 锡林郭勒 | 珠海 | 雄安新区 | 中山 | 黔南 | 诸暨 | 云南昆明 | 瑞安 | 衡阳 | 晋中 | 南通 | 北海 | 琼海 | 石河子 | 澳门澳门 | 南充 | 天长 | 海宁 | 台中 | 台湾台湾 | 邯郸 | 保定 | 黔南 | 舟山 | 阿勒泰 | 济源 | 海门 | 延边 | 曲靖 | 株洲 | 柳州 | 赣州 | 阿拉尔 | 台山 | 雄安新区 | 象山 | 宁德 | 淮南 | 昌都 | 福建福州 | 清远 | 乐平 | 杞县 | 景德镇 | 永康 | 宁夏银川 | 西藏拉萨 | 镇江 | 果洛 | 杞县 | 黑龙江哈尔滨 | 宿州 | 吉林长春 | 宜春 | 佳木斯 | 河北石家庄 | 伊犁 | 黔南 | 玉树 | 南安 | 绵阳 | 烟台 | 铜仁 | 邳州 | 嘉兴 | 南通 | 通化 |