試圖將uml合成轉換成代碼[uml]

我想了解uml合成到代碼的轉換。我有三個代碼狗有內存的例子的問題。這三個例子可以被認爲是一個組成（uml含義的組成）？試圖將uml合成轉換成代碼[uml]

實施例1

class Memory { 
    // CODE 
} 

class Dog { 
    private Memory variable; 

    Dog(Memory variable) { 
     this.variable = variable; 
    } 
} 

class Factory { 
    Dog createDog() { 
     Memory memory = new Memory() // memory contains reference to object Memory only moment and after create dog don't use it 
     return new Dog(memory); 
    } 
}

實施例2

class Memory { 
    // CODE 
} 

class Dog { 
    private Memory variable; 

    Dog(Memory variable) { 
     this.variable = variable; 
    } 
} 

class Factory { 
    Dog createDog() { 
     return new Dog(new Memory()); 
    } 
}

實施例3

class Memory { 
    // CODE 
} 

class MemoryFactory { 
    Memory createMemory() { 
     return new Memory(); 
    } 
} 

class Dog { 
    private Memory variable; 

    Dog(MemoryFactory memoryFactory) { 
     this.variable = memoryFactory.createMemory(); 
    } 
} 

class Factory { 
    Dog createDog() { 
     MemoryFactory factory = new MemoryFactory() 
     return new Dog(factory); 
    } 
}

有點不同的示例：

class Memory { 
    // CODE 
} 

class Dog { 
    private Memory variable; 

    Dog() { 
     this.variable = new Memory(); 
     Other other = new Other(); 
     other.method(variable); 
    } 
} 

class Other { 
    void method(Memory memory) { 
     // code which don't save reference to memory 
    } 
}

這是進一步組合物？

來源

2017-07-10 Cos Siek

除了您還有一個關聯之外，您的最後一個示例基本上沒有區別。請先嚐試理解答案。 –

是的;所有的例子在對於相同的組合物：

class Dog { 
    private Memory variable; 
}

這相當於

創建狗的方式/內存在這裏無關緊要的類之間的連接，這總是最終同樣的。（組成爲約結構;創建它的方式是關於行爲。）

關於例如臨時存儲存儲器實例：

這將最有可能由編譯器的示例，而不臨時變量進行優化，但更有趣的問題將是如果你保留參考文獻;在這種情況下，擋塊內存關係將不再是（UML）的複合凝聚，但在最好的任一相關聯或共享的聚集（也What is the difference between association, aggregation and composition?見）

關於最後一個例子：這很好，只要如Thomas所解釋的那樣，您堅持生命週期管理。

來源

2017-07-10 09:04:49

似乎你在此期間添加了缺失的點:-)無論如何，我會留下我的答案（或附錄），但是這會得到最高票數。 –

我在輸入時看到了您的答案，但您仍然在更詳細地解釋它。 –

基本上我贊同彼得的回答。然而，組合（或者是正式的複合聚合與共享聚合幾乎沒有語義）是關於對象的生命週期。所以你有一個簡單的關聯，並顯示通常就足夠了。根據所需語言的運行時實現方式，Memory對象將會或將不會在對象死亡時消失。從實施（直接）看不出這個事實。例如。在某些語言中，如果在運行時在其他地方使用Memory對象，則會有對象引用計數，但它仍將繼續運行，但Dog已死亡。

在UML圖中顯示一個組合聚集，告訴編碼器要小心，一旦主對象死亡，沒有引用留給組合，並且內存管理也會將它帶入比特嚴重。就數據庫實現而言，它是需要設置的外鍵約束。 RDBMS將刪除其主人被刪除時的彙總（如果程序員/ DBA已爲複合彙總設置了正確的限制：ON DELETE CASCADE）。

來源

2017-07-10 09:11:32

只有在數據庫開發人員已經定義了ON DELETE CASCADE規則時，您纔會聲明「一個RDBMS將刪除它們的主集合時刪除集合」，對應於不可分離組件的情況（請參閱https://stackoverflow.com/a/35214676/2795909） –

@GerdWagner你可能是對的（我不是DBA）。重點在於之前的2個句子（這意味着你需要ON DELETE CASCADE）。 –

試圖將uml合成轉換成代碼[uml]

回答

相關問題