对象规范化

Question

与数据库规范化相同的是，是否有一种对象规范化的方法，而不是设计模式，而是标准化对象创建的相同的数学方法。例如:第一个范式:没有重复字段.以下是到DB规范化的一些链接：

归一化 http://databases.about.com/od/specificproducts/a/normalization.htm

这会使对象创建和自文档化更好吗？

下面是一本关于类规范化的书的链接(我猜我们实际上是在谈论类)，http://www.agiledata.org/essays/classNormalization.html

Answer 1

规范化在谓词逻辑中有一个数学基础，并且有一个明确而具体的目标，即同一条信息永远不会在单个模型中被表示两次；该目标的目的是消除数据模型中不一致信息的可能性。通过数学证明可以看出，如果一个数据模型具有某些特定的性质(它通过了第一范式(1NF)、2NF、3NF等的测试)它没有冗余的数据表示，也就是说它是规范化的。

对象定向没有这样的数学基础，事实上，也没有明确和具体的目标。它只是一个引入更多抽象的设计思想。DRY原则、命令-查询分离、Liskov替换原则、开-闭原则、告诉-不要-询问、依赖反转原则和其他提高代码质量的启发式(其中许多都适用于一般的代码，而不仅仅是面向对象的程序)本质上不是绝对的；它们是程序员发现在提高代码的可理解性、可维护性和可测试性方面有用的指南。

对于关系数据模型，您可以绝对肯定地说它是否“规范化”，因为它必须通过所有正常形式的测试，而且它们是非常具体的。另一方面，对于对象模型来说，由于“可理解、可维护、可测试等”的目标相当模糊，因此您无法确定您是否达到了该目标。对于许多设计启发式方法，您甚至无法确定您是否遵循了它们。如果你将模式应用到你的设计中，你是否遵循了干燥原则？重复使用模式肯定不是干的吗？此外，这些启发或原则中的一些并不总是总是好的建议。我确实尝试遵循命令-查询分离，但是堆栈或队列等有用的东西违反了这个概念，以便给我们一个相当优雅和有用的结果。

Answer 2

我想单一责任原则至少与此相关。或者至少，违反SRP在某些方面类似于缺乏正常化。

(很可能我说的是垃圾。我很累。)

Answer 3

有意思的。

您也可能对查看德米特定律感兴趣。

您可能感兴趣的另一件事是c2's FearOfAddingClasses，因为可以说，导致程序员去还原数据库的推理也会导致上帝类和其他代码气味。对于OO和DB正常化，我们想要分解所有的东西。对于数据库，这意味着更多的表，对于OO，更多的类。

现在，值得记住的是对象关系阻抗失配，也就是说，并不是所有的东西都能清晰地翻译出来。

对象关系模型或“持久化层”，通常在对象属性和数据库字段之间有1到1的映射。我们能恢复正常吗？假设我们有employee1，employee2的部门对象.等等。属性。显然，这应该用一份员工名单来代替。所以我们可以说1NF有效。

在考虑到这一点之后，让我们直接来看看6NF数据库的设计，一个很好的例子是锚建模，(忽略命名约定)。锚建模/6NF提供高度分解和灵活的数据库模式；如何将其转换为OO“规范化”？

锚建模有以下几种关系：

• 锚-唯一的对象ID。
• 属性，转换为对象属性：(锚点、值、元数据)。
• 联系-两个或多个对象(本身锚)之间的关系：(锚，锚.、元数据)
• 结，可归因的联系。

属性元数据可以是任何东西--谁更改了属性、何时、为什么等等。

它的OO翻译看起来非常灵活：

• 锚提示没有属性的占位符，就像一个知道如何处理属性组合的代理。
• 属性建议表示属性及其所属的类。这建议将重用应用于属性的查找和处理，例如自动约束检查等。由此，我们为通用实现GOF风格的结构模式奠定了基础。
• 领带和结表示表示对象之间关系的类。行为设计模式的通用实现基础？

Anchor模型的有趣和可取的特性也被转换为：

• 所有这一切都需要用公开对象中的组合(很好)代替继承。
• 属性有所有者，而不是所有者有属性。尽管这使得属性查找更加复杂，但它巧妙地解决了某些别名问题，因为只有一个所有者。
• 不需要零。这转化为更清晰的空处理。空用例属性类可以提供方法来处理缺少特定属性的问题，而不是到处执行空检查。
• 属性元数据属性级别的完全历史化和指责：“播放”对象回到过去，查看更改的内容、时间和原因等等(如果需要，元数据完全是可选的)。

可能会有很多非常简单的类(这很好)，以及非常声明性的编程风格(也很好)。

谢谢你这样一个发人深省的问题，我希望这对你有用。