設計原則6大原則解讀--
deadLine和榮譽感是最大推動力.
模組劃分,職責清晰. 做的好不好.
P7,P8要求 :
規劃能力-抓手(有時候抓手都可以讓對應的同學完成. 頭腦風暴一下, 溝通,分贓會) : 設計原則,設計模式. 抽象出來幾個字. 需求方要求,準,快.
需求分析能力: 人,系統, 流程,(功能性,非功能性),做一個最擔憂什麼? 技術方案,邊界互動,可靠性(巨集觀上的). 細節欄位(業務上的)
優化能力: 結構化異常資訊的分析歸類,拆分能力.
架構師角度,面梳理,依賴工具見下治理,統籌安排.
普通開發角度,基礎知識
管理角度:流程管理,人員培養,內部 case 學習,每日值班制度.
軟性:
職責明確能力:
鼓勵能力:
高內聚,低耦合:
選型能力: - 可靠性,擴充套件性,可用性,壓測和效能瓶頸.
改進能力: 錯誤問題
比賽虛擬隊伍組織:
0. 建了個群. 保證溝通渠道.
1. 第一次開會, 明確目標:每個人都理解這些設計原則. 下週二來,然後定期跟蹤. 承諾和壓力
2. 第二次達成一致,對各個細節點.見如下問題. 每個人領取兩個原則.原則模板,和框架.
3. 最後一次,各自討論對方的,然後修改
4. 上場,演練口號,夢想,目標等. 諮詢每個人是否已經看過.
補充: 分模組分層(facade或內聚業務隔離變化), 分層封裝(降低變數數).
門面模式
1.職責單一
結合工作經驗
方法: A. 按業務流分.1.水平切分(更難,最後review下模組的存在是為了隔離變化.) 2.垂直切分. 3.支撐切分. (這種變化一個層面是多個系統比如多個支付方式,另外一個層面的內部業務的變化,比如費用)
B. 按表分: 1.將一些表的業務剝離出去.如果夠穩定就剝離走. 2.將表拆分後將對應的業務剝離走.
一旦切分完之後,下層要關注是否還需要和最上層溝通.( 分潤模組不需要直接呼叫訂單獲取費用,分析各種費用型別. 業務隔離,技術棧和繁瑣的費用型別隔離. 系統的作用遮蔽技術棧和業務變化. 雖然包含了兩種業務,但是遮蔽了變化)
同一類的職責還是一個職責. 一個類一個方法,一個功能.
按流程角度來職責,按垂直領域去單一. 最終到不可拆原則.
介面隔離是方法(面向的是業務方),職責單一是目的
2.里氏替換(用的少)
子類替換父類,而不是子類替換子類. 做法: 所有父類的方法都是final.
3.依賴倒置.
結合業務知識: 把業務型別和支付型別變成類,介面化. 同時也引入了開閉原則.
抽象不能依賴具體. 對於java來說介面不可能依賴具體.
抽象類的方法必須是抽象的,通用的. 抽象具體是相對的.
怎麼對倒置進行理解: 倒置 原來是直接依賴實現的,一開始就知道調什麼,現在不知道依賴的是什麼倒過來了.(現在服務端的介面都是通過autowired注入,一開始都是明確的,不屬於依賴隔離)
怎麼對抽象進行理解: 商務單,普通單. 你可以抽象為訂單,也可以將發單動作抽象為一個介面. 更加符合單一原則.
難點是什麼? 關鍵是要把共用的部分給抽象出來.
blog.csdn.net/mariofei/article/details/23778661
難點: 具體是對應著物, 抽象對應著行為業務功能.
將具體的東西抽象出行為. 所有的都是service.
http://www.uml.org.cn/sjms/201211023.asp#3
實現一個很大的問題是 實現的依賴的實現也可以被上層看到.
4. 介面隔離原則..
客戶端不應該依賴它不需要的介面;一個類對另一個類的依賴應該建立在最小的介面上。
實現不一定會隔離,可以依賴拆分後的介面.
但是從單一職責的角度不應該同時依賴多個類,應該有組裝成組合組裝.
難點: 隔離是相對呼叫者來說的. 介面隔離本身是方法,目的是為了對外面最小可見.
介面隔離原則跟之前的單一職責原則很相似,其實不然。其一,單一職責原則原注重的是職責;而介面隔離原則注重對介面依賴的隔離。其二,單一職責原則主要是約束類,其次才是介面和方法,它針對的是程式中的實現和細節;而介面隔離原則主要約束介面介面,主要針對抽象,針對程式整體框架的構建
介面隔離: 介面的含義是檔案,然後dubbo jar可以切成多隔.
介面最小化,分開.不然實現類就要多實現.
使用多個專門的介面比使用單一的總介面要好.
不動實現,介面拆分.
舉例: 支付,先根據職責單元拆分成 微信支付,支付寶支付. 然後再拆成n個介面.
虛線是依賴, 三角形是剪頭.
5.迪米特法則 ( 最少知道原則,減少對內部的瞭解. 自己補充:隔離變化原則.)
定義:一個物件應該對其他物件保持最少的瞭解。
方法: 1. 單一職責 能儘量避免這個.
2. 和直接朋友,不要越層呼叫.
3. 降低對外和整體的依賴度. 而不是個體之間的.
舉例: 快遞員.
網狀拓撲,變成星型拓撲. 銀行清算系統.
為什麼可以直接找對方: 每個功能不一樣, 有些service可以直接呼叫.
6. 開閉原則:
對擴充套件開發,對修改封閉.
工程經驗: 將type欄位變成type介面.降低對內部的變化. 應對新的業務場景. 而不是採用門面模式,沒有依賴導致.
評估方法: 1. 因變化導致變動行數越少
2. 因為變化導致變動程式碼行/原有程式碼行的比率.
3. 原有程式碼行數越多越差
改進: 具有前瞻性,把變化的地方提取出來.可配置.