Oop 哪个设计更好？

我有一个团队负责人对象，并且有很多团队成员反对团队负责人拥有的对象。 团队领导和团队成员都有一个名为“writeDB”的函数

因此，设计1：

Have a common writeDB function in DBUtility:
teamLeader.writeDB(); //calling DBUtility like this DBUtility.insert(self);
teamMember.writeDB(); //calling DBUtility like this DBUtility.insert(self);

设计2：

Both implementing a writeDB Interface:
teamLeader.writeDB(); //implement the write DB itself;
teamMember.writeDB(); //implement the write DB itself;

design 1可以将writingDB逻辑集中到一个类中，如果在编写DB时出现任何问题，我只需要更改DBUtility类，而且，如果我想更改DB，我只需要更改一个位置

设计2可以将代码分为两个位置。如果一个开发人员编写了关于teamLeader逻辑的代码，他不需要更新DBUtility，而且，如果代码移动到其他地方，他也不需要复制无用的函数，例如，DBUtility的teamMember writeDB函数是不需要的

---

您认为如何更好地维护？或者你的设计3。多谢各位

我更喜欢使用第二种设计，因为它更面向对象，您将从分离代码中获益。

我应该使用设计2，它将强制我的所有类都使用writeDB方法，我将使用设计1来提供此功能

这样，我将为我的对象负责人/成员提供接口，并将操作分组到知道如何执行操作的on类下。

抛开我对任何模型级类都会有一个名为writeDB的显式公共方法的担忧，我选择选项1 持久性应该被认为与这些类的核心职责是正交的

好处分为几个部分

• 明确划分责任将导致更大的风险 面向对象设计。随着时间的推移，更面向对象意味着更易于理解和管理

• 在更大的团队中，您可能会有一个子团队明确地在持久性层上工作，他们可以全权负责管理和优化代码

• 当您不可避免地发布数据库X优于数据库Y（或者SQL确实是个坏主意）时，持久性逻辑不会分散在代码库中

那个讨厌的writeDB（）方法

---

回到我的第一点，您不应该有一个名为writeDB的公共方法。您可能也不希望使用更通用的名称，例如save。更好的设计将允许类自己决定何时需要持久化，这取决于。从关注点分离原则来看，这不应该出现在类本身中，但拥有一个了解所有其他类的类违反了开-关原则

---

此类操作还有第三种选择（例如写入数据库），即使用类中的一些元数据，然后使用一些代码，使用元数据信息将对象写入数据库。

为什么团队成员和团队领导必须了解数据库？我认为这样会更好：

DBUtility.write( teamMember );
DBUtility.write( teamLeader );

更好的方法是，如果

DBUtility

不是静态的，那么您可以看到它真正依赖于什么。静态与全局相同。Global提出了一个假设，即只以一种方式进行，这通常会在以后引发问题

DBUtility dbUtility = new DBUtility( dbConnection );
dbUtility.write( teamMember );
dbUtility.write( teamLeader );

之后，您可能需要将XML写入磁盘。您应该能够添加此功能，而无需更改您的

团队领导

和

团队成员

XMLUtility xmlUtility = new XMLUtility( stream );
xmlUtility.write( teamMember );
xmlUtility.write( teamLeader );

---

第二种选择是明确的mor OO。每个类型都实现writeDB接口。 如果在编写teamLeader时有必要同时编写每个teamMember，那么针对teamLeader的writeDB Implementation可以对每个teamMember调用writeDB

这将是最面向对象的解决方案

然而，这并没有考虑到持久层的限制和效率