高效設計類之間的關係

-2

我想知道類之間的以下關係模型是否可以改進。我使用MongoDB作爲數據庫層。高效設計類之間的關係

public class TodoItem { 
private String description; 
private Person person; 
} 

public class Person { 
private List<TodoItem> items; 
}

我的問題又是針對像一對多和雙向關係的類的設計而設計的。謝謝。

來源

2012-02-09 jsf

員工是否屬於一個部門？在很多公司中情況並非如此。 – JonH 2012-02-09 15:59:00

部門層次結構如何？ – 2012-02-09 16:05:23

您應該提供有關背景的更多信息 – 2012-02-09 16:33:22

這真的取決於你的需求/環境。

例如你有雙向依賴關係。他們很難維護，但對於使用此功能的客戶來說很好。什麼更重要？你是否真的需要或多或少同時經常地瀏覽兩種方式？

存儲完整的對象。也許你應該存儲代理，或者ID和一個存儲庫。直到我們知道您的要求，無論是功能性的還是非功能性的，都無法分辨。

其實如果你沒有要求，設計是錯誤的，因爲你不應該有一類，如果它不能幫助滿足要求。

軟件設計沒有絕對的正確或錯誤。如果這樣的決定是可能的，我們不需要手動做出決定，它將作爲每種現代語言的語言特徵提供。設計是關於理解需求和理解效果設計決策對這些需求滿足程度的影響。

所以，如果你想了解設計嘗試以下操作：

採取簡單的功能需求，並考慮如何設計改動而不斷變化的非功能性需求：它有一個芯片卡上運行;它必須每秒處理數千個請求。很多寫道，很少有讀物;很多的閱讀，很少寫道。 ...

來源

2012-02-09 21:22:05

你真的需要雙向聯想嗎？例如，部門是否知道它屬於哪個公司？

對於單向聯繫，聯接更少，Department不必知道任何關於Company（或者如果Company更改，則更改）。 Project，Employee，...

沒有更多的信息，這就是我所看到的。

來源

2012-02-09 16:04:55

更新我的代碼，並在上面留下評論。 – jsf 2012-02-09 16:39:25

你完全改變了你的問題，現在我的回答並不意味着什麼。如果你想問另一個問題，你應該創建另一個問題（也可以在這裏鏈接）。 – 2012-02-09 16:49:26

那麼，正如我所說我的問題是特定於設計。我已經修改它以縮小到雙向關聯。所以，現在它正在打擊你的第一句話：「你真的......」我們怎麼能沒有緊密耦合的簡單設計？只包含ID？再次，我很抱歉，我第一次太含糊。將來會記住。 – jsf 2012-02-09 17:16:26

簡單的答案是

public class Company { 
private List<Department> departments; 
} 

public class Department { 
    private List<Employee> employees; 
    private List<Project> projects; 
    private Map<Employee, Project> employeeProject; 
} 

public class Employee { 
    private String name; 
}

來源

2012-02-09 16:23:54 yadab

項目可能包括來自多個部門的人員。國際海事組織這個任務不應該過於簡單化。 – 2012-02-09 16:26:05

我和Alex在這個項目上，我們不知道項目如何與員工或部門相關，除非用戶有很多項目。這*可能*與原始設計不兼容。 – 2012-02-09 16:32:28

我已經簡化了我的代碼，專注於一個問題，即Person是否需要存儲項目的ID或維護完整的TodoItems的列表。這是雙向關係。對不起，我第一次不清楚。 – jsf 2012-02-09 16:38:27

高效設計類之間的關係

回答

相關問題