1.1 設計模式怎樣解決設計問題
1.1.1 尋找合適的對象
面向對象設計最困難的部分是將系統分解為對象的集合。
設計的許多對象來源于現實世界的分析模型,這里和領域驅動設計有點關聯。分析所得到的類,很多事現實中并不存在的類。這是抽象的結果。設計中的抽象對于產生靈活的設計至關重要。就像我設計的一個流程調度模型。
1.1.2 決定對象的粒度
記筆記可以讓我達到沉流的狀態。
1.1.3 指定對象接口
1.1.4 描述對象實現
OMT表示法:
1、 對象:最上面的黑體表示類名,下面依次是操作,數據。
2、 實例化:虛線箭頭表示一個類實例化另外一個對象。
3、 繼承:豎線和三角表示繼承關系。
4、 抽象類:類名以黑體斜體表示,操作也用斜體表示。
5、 引用
箭頭加黑點表示一個類引用另外一個類。
重點:
1、 類的繼承和接口繼承的比較
對象的類和對象的類型的區別:
對象的類定義了對象是怎樣實現的,同時也定義了對象內部狀態和操作的實現。對象的類型只與它的接口有關。一個對象可以由多個類型(支持多個接口),不同類的對象可以有相同的類型。
類和類型緊密相連,類定義了對象的操作,也定義了對象的類型。
類的繼承和接口的繼承的差別:
c++中接口繼承接近于公有繼承純抽象類。純實現繼承或純類繼承接近于私有繼承。
2、 對接口編程,而不是對實現編程——面向對象設計的第一個原則
1.1.5 運用復用機制
1、 繼承和組合的比較
繼承是一種白箱復用,父類的內部細節對子類可見。
對象組合彼此不知道對方內部細節,成為黑箱復用。
繼承的優缺點:
1) 子類可以直接重定義父類的操作。
2) 編譯時刻決定了,無法在運行期間更改。
3) 子類要知道父類的實現細節,這樣就部分破壞了封裝性。子類和父類依賴過于緊密,父類的某些變化必然導致子類的變化。開發過程中遇到過類似的問題。這種依賴,限制了靈活性以及復用性。比如,服務體系中經常出現這樣的問題,導致代碼拷貝。
組合(通過獲得對象的引用而在運行時刻動態的定義)的優缺點:
1) 對象間通過接口彼此交互。
2) 對象只能通過接口訪問,不要也不能知道對方細節,這樣不會破壞封裝性。
3) 運行時刻可以使用另外一個對象替換這個對象,提高了靈活性。
4) 對象的實現基于接口編寫,所以實現上存在較少的依賴關系。
5) 優先使用組合有助于保持每個類被封裝,并被集中在單個任務上,提高整體內聚性。類和類的層次都維持一個較小的規模,
6) 基于對象組合的設計會有更多的對象(而又較少的類),且系統的行為依賴于對象間的關系而不是定義在某個類的內部。
理想的情況下,應該通過組合原有構件實現新的功能,而不是創建新的構件。
面向對象設計的第二個原則:優先使用對象組合,而不是類繼承。
2、 委托
委托時一種組合方法,它是組合具有與繼承同樣的能力。
委托的主要優點在于它便于在運行時刻組合對象操作,以及更改操作的組合方式。它是軟件更加的靈活。
和其他的技術方案相同,它也存在不足之處:增加了軟件的復雜度——動態的,高度參數化的軟件比靜態的軟件更難于理解。
3、 繼承和參數化類型的比較
1.1.6 關聯運行時刻的結構和編譯時刻的結構
1.1.7 設計應支持變化
設計應該支持變化——所說的是,一個設計方案,對變化要有一定的適應性,即封裝變化。
變化是導致重新設計的原因。設計要對一定范圍內的變化友好。
4、
對于程序的分層設計,對于處于同一分層的模塊,對外應保持一定的抽象,并且,使用同種類型的通信協議。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
