1. 程式人生 > >23種設計模式-依賴、關聯、聚合和組合之間區別的理解

23種設計模式-依賴、關聯、聚合和組合之間區別的理解

 在學習面向物件設計物件關係時,依賴、關聯、聚合和組合這四種關係之間區別比較容易混淆。特別是後三種,僅僅是在語義上有所區別,所謂語義就是指上下文環境、特定情景等。他們在程式語言中的體現卻是基本相同的,但是基本相同並不等於完全相同,這一點在我的前一篇博文《設計模式中類的關係》中已經有所提及,下面就來詳細的論述一下在java中如何準確的體現依賴、關聯、聚合和組合。

首先看一看書上對這四種關係的定義:

  • 依賴(Dependency)關係是類與類之間的聯接。依賴關係表示一個類依賴於另一個類的定義。例如,一個人(Person)可以買車(car)和房子(House),Person類依賴於Car類和House類的定義,因為Person類引用了Car和House。與關聯不同的是,Person類裡並沒有Car和House型別的屬性,Car和House的例項是以參量的方式傳入到buy()方法中去的。一般而言,依賴關係在Java語言中體現為局域變數、方法的形參,或者對靜態方法的呼叫。
  • 關聯(Association)關係是類與類之間的聯接,它使一個類知道另一個類的屬性和方法。關聯可以是雙向的,也可以是單向的。在Java語言中,關聯關係一般使用成員變數來實現。
  •  聚合(Aggregation) 關係是關聯關係的一種,是強的關聯關係。聚合是整體和個體之間的關係。例如,汽車類與引擎類、輪胎類,以及其它的零件類之間的關係便整體和個體的關係。與關聯關係一樣,聚合關係也是通過例項變數實現的。但是關聯關係所涉及的兩個類是處在同一層次上的,而在聚合關係中,兩個類是處在不平等層次上的,一個代表整體,另一個代表部分。
  •  組合(Composition) 關係是關聯關係的一種,是比聚合關係強的關係。它要求普通的聚合關係中代表整體的物件負責代表部分物件的生命週期,組合關係是不能共享的。
    代表整體的物件需要負責保持部分物件和存活,在一些情況下將負責代表部分的物件湮滅掉。代表整體的物件可以將代表部分的物件傳遞給另一個物件,由後者負責此物件的生命週期。換言之,代表部分的物件在每一個時刻只能與一個物件發生組合關係,由後者排他地負責生命週期。部分和整體的生命週期一樣。

——摘自《Java面向物件程式設計》,作者:孫衛琴

       以上關係的耦合度依次增強(關於耦合度的概念將在以後具體討論,這裡可以暫時理解為當一個類發生變更時,對其他類造成的影響程度,影響越小則耦合度越弱,影響越大耦合度越強)。由定義我們已經知道,依賴關係實際上是一種比較弱的關聯,聚合是一種比較強的關聯,而組合則是一種更強的關聯,所以籠統的來區分的話,實際上這四種關係、都是關聯關係。

        依賴關係比較好區分,它是耦合度最弱的一種,在java中表現為局域變數、方法的形參,或者對靜態方法的呼叫,如下面的例子:Driver類依賴於Car類,Driver的三個方法分別演示了依賴關係的三種不同形式。

  1. class Car {  
  2.     publicstaticvoid run(){  
  3.         System.out.println("汽車在奔跑");  
  4.     }  
  5. }  
  6. class Driver {  
  7.     //使用形參方式發生依賴關係
  8.     publicvoid drive1(Car car){  
  9.         car.run();  
  10.     }  
  11.     //使用區域性變數發生依賴關係
  12.     publicvoid drive2(){  
  13.         Car car = new Car();  
  14.         car.run();  
  15.     }  
  16.     //使用靜態變數發生依賴關係
  17.     publicvoid drive3(){  
  18.         Car.run();  
  19.     }  
  20. }  

        關聯關係在java中一般使用成員變數來實現,有時也用方法形參的形式實現。依然使用Driver和Car的例子,使用方法引數形式可以表示依賴關係,也可以表示關聯關係,畢竟我們無法在程式中太準確的表達語義。在本例中,使用成員變量表達這個意思:車是我自己的車,我“擁有”這個車。使用方法引數表達:車不是我的,我只是個司機,別人給我什麼車我就開什麼車,我使用這個車。

  1. class Driver {  
  2.     //使用成員變數形式實現關聯
  3.     Car mycar;  
  4.     publicvoid drive(){  
  5.         mycar.run();  
  6.     }  
  7.     ...  
  8.     //使用方法引數形式實現關聯
  9.     publicvoid drive(Car car){  
  10.         car.run();  
  11.     }  
  12. }  

        聚合關係是是一種比較強的關聯關係,java中一般使用成員變數形式實現。物件之間存在著整體與部分的關係。例如上例中

  1. class Driver {  
  2.     //使用成員變數形式實現聚合關係
  3.     Car mycar;  
  4.     publicvoid drive(){  
  5.         mycar.run();  
  6.     }  
  7. }  


        假如給上面程式碼賦予如下語義:車是一輛私家車,是司機財產的一部分。則相同的程式碼即表示聚合關係了。聚合關係一般使用setter方法給成員變數賦值。

假如賦予如下語義:車是司機的必須有的財產,要想成為一個司機必須要先有輛車,車要是沒了,司機也不想活了。而且司機要是不幹司機了,這個車就砸了,別人誰也別想用。那就表示組合關係了。一般來說,為了表示組合關係,常常會使用構造方法來達到初始化的目的,例如上例中,加上一個以Car為引數的構造方法

  1. public Driver(Car car){  
  2.     mycar = car;  
  3. }  


        所以,關聯、聚合、組合只能配合語義,結合上下文才能夠判斷出來,而只給出一段程式碼讓我們判斷是關聯,聚合,還是組合關係,則是無法判斷的。

相關推薦

23設計模式-依賴關聯聚合組合之間區別理解

 在學習面向物件設計物件關係時,依賴、關聯、聚合和組合這四種關係之間區別比較容易混淆。特別是後三種,僅僅是在語義上有所區別,所謂語義就是指上下文環境、特定情景等。他們在程式語言中的體現卻是基本相同的,但是基本相同並不等於完全相同,這一點在我的前一篇博文《設計模式中類的關係

UML中依賴關聯關聯聚合組合區別

在UML中,依賴和關聯經常無法進行區分,在類圖中,不知道什麼時候使用依賴,什麼時候使用關聯,來定義兩個類之間的關係。 今天看了一篇帖子,對這兩種關係做了比較生動的區分 依賴指的是兩個類之間發生的關係輸入偶然發生的,例如人和船之間的關係就是這種,人偶爾才會坐船,因此屬於依賴關係,這種例子還包括

UML類關係(依賴關聯聚合組合區別

UML Class Relationships 由於最近看一些java書涉及到了uml類圖,因此查閱資料,思考後整理總結寫成如下文章 注重於理解,沒有如何實現(畫圖)的部分 Generalization/specialization

23設計模式(概念原則場景優點缺點應用)簡述

《大話設計模式》中提到了 24種設計模式: 簡單工廠模式,策略模式、裝飾模式、代理模式、工廠方法模式、原型模式、模板方法模式、外觀模式、建造者模式、觀察者模式、抽象工廠模式、狀態模式、介面卡模式、備忘錄模式、組合模式、迭代器模式、單例模式、橋接模式、命令模式、職責鏈模式、中

23設計模式的總結~以及區別應用

簡介 設計模式目的:為了可重用程式碼,保證程式碼的可靠性,更容易被他人理解。 設計模式的六大原則: 總原則:開閉原則,即對擴充套件開放,對修改關閉。 1 單一職責原則:每個類應該實現單一的職責,否則應該把類拆分。 2 里氏替換原則:任何基類可以出現的地

23設計模式介紹以及單例模式的學習

單例模式 餓漢式 23種設計模式 gof23 1、GOF23 設計模式總共分成創建型模式、結構型模式和行為型模式三種: a、創建型模式: - 單例模式、工廠模式、抽象工廠模式、建造者模式、原型模式 b、構建型模式: - 適配器模式、橋接模式、裝配模式、組合模式、建造者模

23設計模式介紹(一)---- 創建型模式

接口 ret static 深復制 return 對象 相互 object c png 由於設計模式篇幅比較大,如果在一篇文章講完所有的設計模式的話不利於閱讀。於是我把它分為三篇文章 23種設計模式介紹(一)---- 創建型模式 23種設計模式介紹(二)---- 結構型模

【Unity與23設計模式】狀態模式(State)

unity public text 開始 sys 狀態模式 改變 val 繼承 定義: “讓一個對象的行為隨著內部狀態的改變而變化,而該對象也像是換了類一樣” 應用場景: 角色AI:控制角色在不同狀態下的AI行為 服務器連接狀態:開始連線、連線中、斷線等狀態 關卡進

轉:23設計模式的應用場景

橋模式 man 16px pop 表示 black strong art bstr 設計模式主要分三個類型:創建型、結構型和行為型。 其中創建型有: 一、Singleton,單例模式:保證一個類只有一個實例,並提供一個訪問它的全局訪問點 ;

【Unity3D與23設計模式】建造者模式(Builder)

產出 private 一個 gof 行為 並且 bstr reac 定義 GoF中定義: “將一個復雜的構建流程與它的對象表現分離出來,讓相同的構建流程可以產生不同的對象行為表現。” 建造者模式可以分為兩個步驟來實施: 1.將復雜的構建流程獨立出來,並將整個流程分成

23設計模式中的叠代器模式

pos over arr imp @override 一個 next() int position 叠代器模式:提供一種方法順序訪問一個聚合對象中的各個對象。 那麽如何提供一個方法順序呢? public interface Iterator<T>{   publ

23設計模式中的訪問者模式

功能需求 封裝 改變 擴展 數據結構 模式 困難 操作 如果 訪問者模式:對於一組對象,在不改變數據結構的前提下,增加作用於這些結構元素新的功能。 適用於數據結構相對穩定,它把數據結構和作用於其上的操作解耦,使得操作集合可以相對自由地演化。 優點: 符合單一職責原則 擴展性

23設計模式中的原型模式

1-1 ... 實例代碼 sets each png 為什麽 .get protect 原型模式:通過復制現有實例來創建新的實例,無須知道相應類的信息。 個人見解:在大量循環時,需要初始化對象,用 原型模式能節省大量的初始化所花費的時間,值得一談的是淺復制和深復制 淺復制:

java 23設計模式

代理 建造者 學習 article 適配器 htm ava arc 叠代 備註這是別人總結的本來想轉載可惜不會怎麽轉載(感謝) 以下是學習過程中查詢的資料,別人總結的資料,比較容易理解(站在各位巨人的肩膀上,望博主勿究) 創建型抽象工廠模式 http://www.cnblo

23設計模式之觀察者模式

主題 一個 server bsp 監聽 images 關系 .com 自動更新 觀察者模式(Observer):定義了一種一對多的關系,讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時,會通知所有觀察者對象,使它們能夠自動更新自己。 23種設計模式之

23設計模式之抽象工廠模式

tor turn sql數據庫 png insert face sign 相關 reat 抽象工廠模式(Abstract Factory):提供一個創建一系列相關或相互依賴對象的接口,而無需指定它們具體的類。 package designMode.abstractFa

23設計模式之模板方法模式

技術分享 cnblogs ati strac void package com rim div 模板方法模式(TemplateMethod):定義一個操作中的算法的骨架,而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。

(35)23設計模式研究之六【命令模式

獨立 場景 處理 針對 客戶端 抽象 軟件 comm mman 命令模式 一:定義 將一個請求封裝為一個對象(即我們創建的Command對象),從而使你可用不同的請求對客戶進行參數化; 對請求排隊或記錄請求日誌,以及支持可撤銷的操作。 二:實現 解決的問題   在軟件系統

23設計模式分類

以及 日誌 visitor 聚合 享元模式 不兼容 復雜 res ons 設計模式主要分三個類型:創建型、結構型和行為型。 其中創建型有: 一、Singleton,單例模式:保證一個類只有一個實例,並提供一個訪問它的全局訪問點 二、Abstract F

23設計模式--中介者模式-Mediator Pattern

ole 缺點 業務 -m ram -- 成了 ons 錯誤 一、中介者模式的介紹 中介者模式第一下想到的就是中介,房子中介,婚姻中介啊等等,當然筆者也希望來個婚姻中介給我介紹一個哈哈哈,,回歸正題中介者模式分成中介者類和用戶類,根據接口編程的方式我們再把中介和用戶類