Question

我有一个团队领导者对象，团队成员拥有很多团队成员对象。团队领导和团队成员都有一个名为“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;

设计1可以将writingDB逻辑集中到一个单独的类中，如果在编写DB时遇到任何问题，我只需要更改DBUtility类，如果我想更改DB，我只需要更改一个地方

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

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

Answer 1

暂且不关心任何模型级别类都有一个名为writeDB的显式公共方法，我会选择选项1

应该认为持久性与这些类的核心职责正交。

好处有几个部分

干净地分离责任将导致更多面向对象的设计。更多面向对象意味着更容易理解，更容易管理。
在大型团队中，您可能会有一个明确在持久层上工作的子组，他们可以全权负责管理和优化代码。
当你不可避免地发布数据库X比数据库Y好（或者确实认为SQL是个坏主意）时，持久性逻辑不会分散在代码库中

那个讨厌的writeDB（）方法

回到我的第一点，你不应该有一个名为writeDB的公共方法。您可能也不想要更通用的名称，例如save。更好的设计将允许类本身决定何时需要持久化

Answer 2

为什么TeamMember和TeamLeader必须完全了解数据库？我认为这会更好：

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

更好的是，如果DBUtility不是静态的，那么你可以看到它真正依赖的东西。静态与全局相同。全球公司提出了一个只有一种做法的假设，这通常会导致问题。

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

然后，您可能需要以XML格式写入磁盘。您应该可以在不更改TeamLeader和TeamMember的情况下添加此功能。

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

Answer 3

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

Answer 4

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

通过这种方式，我将拥有我的对象Leader / Member的界面，并将在类上分组的动作知道如何执行操作。

Answer 5

这取决于。从分离关注原则来看，这不应该在班级本身，但是有一个知道所有其他人的班级违反了开放 - 关闭原则。

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

Answer 6

第二个选择肯定是mor OO。 Eache类型实现了writeDB接口。如果在编写teamLeader时也会编写每个teamMember，那么teamLeader的writeDB implomentation可以在每个teamMember上调用writeDB。

这将是最OO的解决方案。

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

哪个更好的设计？

6 个答案:

暂且不关心任何模型级别类都有一个名为writeDB的显式公共方法，我会选择选项1

那个讨厌的writeDB（）方法