關於面向對象的問題

自從我瞭解面向對象編程的時候，我就有了這個問題。現在，我想到了一個很好的論壇。關於面向對象的問題

假設我們正在實施一個使用EJB的員工管理應用程序。

現在，有兩種方法可以做到這一點。

通常，我們創建實體（POJO），這些實體代表僱員。然後我們通過添加，刪除，更新，檢索，檢索所有方法創建一個EJB接口'EmployeeManager'。這樣我可以使用'員工'實體作爲數據傳輸對象。
我們稱EJB接口本身爲'Employee'。可以將實現稱爲'EmployeeImpl'，其具有字段以及方法實現（添加，刪除，更新，檢索，檢索全部）。如果我在業務邏輯需要訪問員工詳細信息時使用分層方法，則需要傳遞'EmployeeImpl'（因爲它包含值）。

你認爲哪一個更好？

我更喜歡第一個，因爲它看起來很好，不會覺得尷尬。像

EmployeeMgr empMgr = // JNDI lookup; 
Employee emp = new Employee(); 
empMgr.add(emp); 
Employee employees[] = empMgr.retrieveAll();

凡爲第二個看起來像（雖然我不知道），

Employee emp = // JNDI lookup; 
emp.setName(); //set the properties 
emp.add(); 
Employee employees[] = emp.retrieveAll();

正如你所看到的，第二個看起來很笨拙。

我請你們在這方面給我提意見。

感謝饅頭

2008-09-22 mmh

第一個肯定是更清晰，清晰度當然應該是你的代碼的目的。但是，就第一個問題而言，我會指導您here：傑夫阿特伍德將其稱爲「SomethingManager」 - 不推薦。

2008-09-22 22:42:27 Smashery

在你的例子中，我不會推薦＃2，因爲它給了Employee類太多的責任。

儘管沒有給出直接答案，但我可以誠摯地推薦Martin Fowler的書Patterns of Enterprise Application Architecture。對我個人而言，這一點讓我大開眼界，並且介紹了幾種不同的方法。

我也認爲開源Hibernate是持久實體的一個很好的工具。我相信你會在那裏找到很多有用的信息。

2008-09-22 22:50:05 SteinNorheim

擁有separare類堅持員工看起來更OO。而且更加靈活，因爲您可能想要使用DBEmployeeMrg，FileSystemEmployeeMrg，InMemoryEmployeeMgr和MockEmployeeMgr進行測試 - 所有這些類都可以以不同的方式實現與EmployeeMrg的接口。

爲了讓您的代碼更短，您可能希望員工能夠自行保存 - employee.save（）而不是employeeMrg.save（employee）當員工保存自己，更新甚至刪除時，我可以理解設計，但絕對不需要一名員工通過ID加載另一名員工並加載員工名單。

2008-09-22 23:00:30

努力進行適當的設計，而不是「OO合規性」。

順便說一下，EJB根本不是面向對象的。

使用EJB的最佳做法是：

EJB通常沒有字段，除非要將它們部署爲無狀態，而這種情況很少需要。

如果您使用的是大多數人會期望的設計的EJB。這顯然不是面向對象的，因爲DataContainer不包含真正的方法，並且EJB/DAO不包含真實數據。

這不是壞事;它將問題分離出來，使您的系統更易於變更和維護。

2008-09-23 19:34:03 davetron5000

回答