I want to fly higher
          programming Explorer
          posts - 114,comments - 263,trackbacks - 0
          示例切入(鴨子游戲)
          • 游戲中會(huì)有各種鴨子,一邊游泳,一邊咕咕叫
          • 設(shè)計(jì)了一個(gè)鴨子的抽象基類,并讓各種鴨子繼承此基類

          • 如果讓鴨子飛,怎么辦?
          • 問題
            • 并非所有的鴨子都能飛,在基類中增加fly會(huì)導(dǎo)致所有的子類都具備fly,連那些不該具備fly的子類也無法排除
            • 非常粗暴的解決辦法就是每個(gè)子類都要仔細(xì)判斷是否要覆寫相關(guān)邏輯,比如不會(huì)飛的鴨子那么覆寫fly方法,什么事情都不做即可;如果遇到不是咕咕叫的鴨子,則覆寫quack方法
            • 繼承的缺點(diǎn)
              • 代碼在多個(gè)子類中重復(fù)
              • 很難知道所有鴨子的全部行為
              • 運(yùn)行時(shí)的行為不容易改變
              • 改變會(huì)牽一發(fā)動(dòng)全身
            • 每當(dāng)新增新的鴨子子類,需要被迫檢查并可能需要覆蓋fly和quack方法--噩夢(mèng)啊
          • 使用接口
            • 把fly從基類中抽出來,放進(jìn)一個(gè)Flyable接口,只有會(huì)飛的鴨子才實(shí)現(xiàn)此接口;同樣的方式,設(shè)計(jì)一個(gè)Quackable接口,因?yàn)椴⒎撬续喿佣紩?huì)叫
            • 問題
              • 解決了一部分問題,不會(huì)再有“會(huì)飛的橡皮鴨(繼承方式)”
              • 但無法進(jìn)行代碼復(fù)用-如后續(xù)幾十個(gè)能飛的鴨子的飛行邏輯一致,不但每一個(gè)子類都需要寫一遍(大量重復(fù)的代碼)而且如果修改飛行邏輯的話,則需要全部都修改一遍
          • 歸零
            • 使用繼承不能很好的解決問題,鴨子的行為在子類不斷的改變并且讓所有的子類都有這些行為是不恰當(dāng)?shù)?/span>
            • 使用Flyable和Quackable接口解決了一部分問題,只有會(huì)飛的鴨子才會(huì)實(shí)現(xiàn)Flyable.但是Java接口不具有實(shí)現(xiàn)代碼,所有實(shí)現(xiàn)接口無法達(dá)到達(dá)到代碼的復(fù)用
            • 設(shè)計(jì)原則
              • 找出應(yīng)用中可能需要變化之處,把他們獨(dú)立出來,不要和那些不需要變化的代碼混在一起
              • 把變化的部分取出并封裝起來,以便以后可輕易的改動(dòng)或擴(kuò)充此部分而不影響不需要變化的的其他部分
              • 分開變化和不會(huì)變化的部分
              • 面向接口編程,而不是面向?qū)崿F(xiàn)編程
            • 飛行行為和咕咕叫行為已經(jīng)和鴨子類無關(guān)了
            • 整合
            • 最終版本
            • 多用組合,少用繼承
          S.O.L.I.D 面向?qū)ο笤O(shè)計(jì)五大基本原則
          • S-單一職責(zé)原則
            • 一個(gè)類應(yīng)該只有一項(xiàng)工作
            • 如計(jì)算類只負(fù)責(zé)計(jì)算,而不負(fù)責(zé)展示,展示需要交由單獨(dú)的展示類進(jìn)行處理
          • O-開放封閉原則
            • 對(duì)擴(kuò)展開放,對(duì)修改關(guān)閉
            • 一個(gè)類無需修改類本身卻容易擴(kuò)展
            • 如計(jì)算類中的計(jì)算圖形面積方法大量的if/else,增加圖形要增加大量的if/else-改由圖形本身去計(jì)算
          • L-里氏替換原則
            • 每一個(gè)子類或派生類應(yīng)該可以替換它們基類或父類
          • I-接口隔離原則
            • 不應(yīng)強(qiáng)迫客戶端實(shí)現(xiàn)一個(gè)它用不上的接口,或是說客戶端不應(yīng)該被迫依賴它們不使用的方法
          • D-依賴反轉(zhuǎn)原則
            • 依靠抽象而不是具體實(shí)現(xiàn)。它表示高層次的模塊不應(yīng)該依賴于低層次的模塊,它們都應(yīng)該依賴于抽象
          面向模式的軟件架構(gòu)
          • 架構(gòu)模式
            • Layers/Pipes and Filters/Blackboard/Microkernel/BrokerMVC/PACReflection
            • Whole-Part/Master-Slave/Proxy/Command Processor/View Handler/Forwarder-Receiver/Client-Dispatcher-Server/publisher-subscriber/
            • Reactor/Proactor/Acceptor-Connector/Aysnchronous Completion Token/Active Object/Thread-Speific Storage
            • Loopup/Lazy Acquisition/Caching/Pooling/Resouce Lifecycle Manager/
          • 設(shè)計(jì)模式
            • The 23 Gang of Four Design Patterns
            • Creational Patterns
              • Abstract Factory/Builder/Factory Method/Prototype/Singleton
            • Structural Patterns
              • Adapter/Bridge/Composite/Decorator/Facade/Flyweight/Proxy
            • Behavioral Patterns
              • Chain of Resp/Command/Interpreter/Iterator/Mediator/Memento/Observer/State/Strategy/Template/Visitor
          • 成例
            • 特定語言的,如引用計(jì)數(shù)(CounterPointer)
          • 抽象、封裝、信息隱藏、模塊化、分離關(guān)注點(diǎn)、耦合與內(nèi)聚、充分-完整-簡單、策略與實(shí)現(xiàn)分離、接口與實(shí)現(xiàn)分離、單個(gè)引用點(diǎn)、分而治之
          • landon:抽象(個(gè)人認(rèn)為寫代碼最高境界就是抽象)、解耦、開閉
          JDK源代碼淺析
          • 經(jīng)典的集合框架
          ref
          • 《Head First Design Patterns》
          • 《Pattern-Oriented Software Architecture》
          posted on 2016-11-04 11:31 landon 閱讀(2446) 評(píng)論(0)  編輯  收藏 所屬分類: ServerFramework
          主站蜘蛛池模板: 英德市| 金坛市| 介休市| 保康县| 钦州市| 鄂温| 方城县| 偏关县| 东莞市| 秦安县| 衢州市| 平武县| 勐海县| 鸡东县| 海林市| 铜山县| 涡阳县| 宜兴市| 嵊泗县| 朝阳市| 澜沧| 大埔区| 平谷区| 和田县| 崇州市| 东山县| 丰台区| 县级市| 泰宁县| 高陵县| 化州市| 鄂托克旗| 永仁县| 蓬莱市| 庆城县| 交口县| 漯河市| 荥经县| 航空| 南京市| 滨海县|