对象规范化

Question

与数据库规范化相同的行 - 是否存在对象规范化的方法,而不是设计模式,而是用于规范化对象创建的相同数学方法.例如:第一个普通形式:没有重复字段....这里是DB规范化的一些链接:

http://en.wikipedia.org/wiki/Database_normalization http://databases.about.com/od/specificproducts/a/normalization.htm

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

这是一本关于类规范化的书的链接(猜测我们真的在谈论类) http://www.agiledata.org/essays/classNormalization.html

Answer 1

规范化在谓词逻辑中具有数学基础,并且明确且具体的目标是同一条信息永远不会在单个模型中表示两次; 此目标的目的是消除数据模型中信息不一致的可能性.可以通过数学证明证明,如果数据模型具有某些特定属性(它通过第一范式(1NF),2NF,3NF等的测试),则它没有冗余数据表示,即它是标准化的.

面向对象没有这样的潜在数学基础,事实上,没有明确和具体的目标.它只是引入更多抽象的设计理念.DRY原则,命令查询分离,Liskov替换原则,开放闭合原则,Tell-DO-Ask,依赖性倒置原则,以及其他用于提高代码质量的启发式方法(其中许多适用于一般代码,而不仅仅是面向对象的程序)本质上不是绝对的; 它们是程序员发现有助于提高代码的可理解性,可维护性和可测试性的指南.

使用关系数据模型,您可以绝对肯定地说它是否"正常化",因为它必须通过所有正常形式的测试,并且它们非常具体.另一方面,对于对象模型,由于"可理解,可维护,可测试等"的目标相当模糊,您无法确切地说是否已达到该目标.有许多设计启发式,你甚至无法肯定地说是否跟随过他们.如果您在设计中应用模式,您是否遵循DRY原则？当然重复使用模式不是DRY？此外,其中一些启发式或原则并不总是一直是好的建议.我尝试按照命令查询分离,

Answer 2

我认为单一责任原则至少与此有关.或者至少,违反SRP类似于在某些方面缺乏正常化.

(我可能会说垃圾.我很累.)

Answer 3

有趣的。

您可能还对迪米特法则感兴趣。

您可能感兴趣的另一件事是c2 的 FearOfAddingClasses，因为可以说，导致程序员对数据库进行非规范化的相同推理也会导致上帝类和其他代码异味。对于 OO 和 DB 规范化，我们希望分解所有内容。对于数据库，这意味着更多的表，对于 OO，意味着更多的类。

现在，值得牢记的是对象关系阻抗失配，也就是说，可能并非所有内容都能清晰地转换。

对象关系模型或“持久层”通常在对象属性和数据库字段之间具有一对一的映射关系。那么，我们可以正常化吗？假设我们有带有employee1、employee2 ...等属性的部门对象。显然，这应该替换为员工列表。所以我们可以说 1NF 有效。

考虑到这一点，让我们直接去看看 6NF 数据库设计，一个很好的例子是Anchor Modeling，（忽略命名约定）。Anchor Modeling/6NF 提供高度分解和灵活的数据库模式；这如何转化为面向对象的“规范化”？

Anchor Modeling 有以下几种关系：

• 锚点 - 唯一的对象 ID。
• 属性，转换为对象属性：（锚点、值、元数据）。
• 关系 - 两个或多个对象（自身锚点）之间的关系：（Anchor, Anchor... , metadata）
• 结，归因于领带。

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

这个的面向对象翻译看起来非常灵活：

• 锚点建议使用无属性占位符，例如知道如何处理属性组合的代理。
• 属性建议代表属性的类以及它们属于什么。这建议将重用应用于如何查找和处理属性，例如自动约束检查等。由此我们有了通用实现 GOF 风格的结构模式的基础。
• 关系和结建议表示对象之间关系的类。行为设计模式的通用实现的基础？

锚建模的有趣和理想的属性也可以转换为：

• 所有这些都需要在暴露的对象中用组合（良好）替换继承。
• 属性有所有者而不是所有者有属性。尽管这使得属性查找更加复杂，但它巧妙地解决了某些别名问题，因为永远只能有一个所有者。
• 不需要NULL。这转化为更清晰的 NULL 处理。Empty-case 属性类可以提供处理缺少特定属性的方法，而不是在任何地方执行 NULL 检查。
• 属性元数据。属性级完整的历史记录和责备：“播放”对象回到过去，查看更改的内容、时间和原因等（如果需要 - 元数据完全是可选的）

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

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