API 设计问题答案

【问题标题】：API Design QuestionAPI 设计问题
【发布时间】：2011-11-09 09:39:26
【问题描述】：

在设计我的 api 时，我正在考虑如何对以下行为进行建模。

选项 1 似乎更合乎逻辑，但随之而来的是强制执行不变量，例如检查电子表格是否确实属于工作簿。

选项 2 看起来很奇怪，电子表格知道如何删除自己，但实际上电子表格有对其父工作簿的引用，并且可以将调用直接委托给他。

或者这真的不是一个有效的案例，因为无论如何工作簿都需要验证它的电子表格？想法？

Workbook wb = new Workbook("Finances");
Spreadsheet ss = wb.CreateSpreadsheet("Bob's");

// option 1:
wb.RemoveSheet(ss);

// option 2:
ss.RemoveFromWorkbook();

谢谢大家

【问题讨论】：

为什么不两者兼而有之？在我看来，选项 2 可以简单地调用选项 1，反之亦然。

标签： c# .net domain-driven-design object-model

【解决方案1】：

我会使用 wb.Sheets.Remove(ss)。这允许职责分离，因为 Sheets 对象是电子表格的集合。这也允许稍后的概念，即一个工作表可能在多个工作簿中。

【讨论】：

Aaaaaah，选项 3...我没看到 :)
很合适，但我不会以这种方式公开收藏。
那么我推荐 wb.RemoveSheet(ss) 方法。
我建议公开您的表格集合，以便您的工作簿具有单独的工作簿方法和工作表管理方法。
+1 The Book 不负责知道有多少张或如何处理它们，只知道它有 Sheets。 Sheets 集合应该对工作表本身负责。

【解决方案2】：

我认为 选项 1 更好用，因为每次您需要从某个容器中删除某些子实体时，首先您将引用该容器，然后您才会搜索一些实体本身的成员。

【讨论】：

【解决方案3】：

我会选择选项 1。将工作簿视为集合或可枚举。与任何集合一样，工作簿的部分工作是管理其中的项目。在工作簿中添加和删除工作表是工作簿的责任，而不是工作表的责任。

【讨论】：

【解决方案4】：

我个人会留在option 1，因为工作簿是包含工作表的东西，所以它是某种容器。因此，要从中删除工作表，使用工作簿对象是合乎逻辑且更自然的恕我直言。

【讨论】：

【解决方案5】：

对我来说绝对是 1。

你有 wb.CreateSpreadsheet，所以如果我已经使用过它，我肯定会在 wb 对象中寻找删除函数。

【讨论】：

【解决方案6】：

选项 1：

工作表根本不应该知道工作簿，您应该查找“解耦”！。

【讨论】：