聚集打破封裝

我一直在看書試圖瞭解我碰到一個點，我覺得聚集能增強鬆散耦合來聚集和composition.However的各個方面，但也可以打破封裝。聚集打破封裝

增強鬆散耦合。

public class Car{ 
    private Engine engine; 
    Car(Engine e){ 
     this.engine=e; 
    } 
}

在上述引擎類的任何實現可以創建並在創建時間推至汽車的對象，因爲引擎實例可以沒有車因此它聚集的一個很好的例子。（這個例子可能不是一個偉大的現實世界的例子，但我認爲我的觀點）

現在客戶端代碼可以完全控制引擎對象，因此它可以改變傳遞給汽車的引擎對象的幾個狀態並且Car的實現會打破封裝，因爲它的對象或狀態（即Engine）不再具有Car中的正確完整性。

我的理解是否正確？

來源

2012-12-11 The Neo Noir Developer

它種取決於與封裝你不想改變一個對象的狀態，而不是你想要操作的對象，所以用引擎代替engine.setOn（boolean）你有engine.turnOn（）。如果你只想讓汽車能夠在引擎上運行，然後在這個構造函數可以克隆這個對象以限制訪問權限this.engine =（Engine）e.clone（）;其他的操作可以是removeEngine然後你可以訪問引擎但是汽車不再有這個引擎 – BevynQ

IMO，I不要認爲客戶端對Engine對象有控制權，我會想象會有更高層的clas稱爲製造商，它將創建正確的引擎對象並將其設置爲特定汽車對象的引擎。 –

我認爲他所指的是創造汽車的過程在發動機不應該有的時候會引用它。 – BevynQ

只有Car可變時，Engine纔會被破壞，即汽車可以改變發動機的狀態。然而，你可以定義不可變類Engine（只具有干將訪問狀態和商業方法不改變狀態），或者通過創建類EngineImpl執行的界面Engine。 EngineImpl不是不可變的。它包括可以改變其狀態的功能。然而它實現的接口Engine只向客戶端公開「不可變」的方法。所以，汽車不能改變隱藏在只讀接口Engine後面的EngineImpl的狀態。在這種情況下，封裝不會被破壞。

你是對的：這是不是真實的例子：在現實世界中的驅動程序通過控制接口引擎由他的車提供，可以打破發動機:(

來源

2012-12-11 07:58:15 AlexR

同意，爲你+1。只有一個疑問，非常微不足道的，一個可變的實現會打破汽車，而不是引擎，對嗎？ –

在這裏，鬆耦合是針對汽車發動機之間的關係。

雖然汽車通過其構造函數接受任何引擎，但我相信汽車不會通過getter方法暴露引擎。

此構造函數應具有適當的訪問控制/級別，並由工廠或其他創建模式使用，該模式負責將引擎與汽車集成。

允許汽車的客戶端訪問引擎應該通過汽車的界面。

來源

2012-12-11 07:56:49

我想你錯過了我的觀點，讓我這樣說吧。 Engine e = new EngineImpl（）; 汽車c =新車（e）; e.setSomethingOnEngine（）; //這可能會破壞汽車的行爲 –

e.setSomethingOnEngine（）將不會被通常由任何工廠或創建模式來完成。也許，Builder可以構建引擎，但它不會在引擎創建並將其注入汽車後改變引擎。如果它確實存在，那麼創建模式代碼就違反了原則。 –

聚集打破封裝

回答

相關問題