在数据库编程中,有一种称为“规范化”的技术可以对要存储的数据进行处理。
有没有人尝试将此概念应用于对象设计?你怎么样 效果如何?
编辑:为了扩展/阐明,数据库规范化不仅仅是减少冗余的一组原则。实际上,您需要经历一些步骤和阶段,并且至少要有一些适度的客观指标来告诉您所处的阶段。对象设计有其自身的原理,并且有嗅觉的概念,但是有什么办法可以做类似的事情来告诉您您是否处于XX-form0,1,2 ...等...以及移至下一个“标准化”级别的方法?
在数据库编程中,有一种称为“规范化”的技术可以对要存储的数据进行处理。
有没有人尝试将此概念应用于对象设计?你怎么样 效果如何?
编辑:为了扩展/阐明,数据库规范化不仅仅是减少冗余的一组原则。实际上,您需要经历一些步骤和阶段,并且至少要有一些适度的客观指标来告诉您所处的阶段。对象设计有其自身的原理,并且有嗅觉的概念,但是有什么办法可以做类似的事情来告诉您您是否处于XX-form0,1,2 ...等...以及移至下一个“标准化”级别的方法?
Answers:
虽然一些导致数据库标准化的潜在压力在OO系统中不存在,但其中一些压力却存在。这些已经引起了OO设计模式和原理,它们在某种程度上类似于规范化,至少是因为OO系统类似于关系数据库。例如:
换句话说,有人试图将数据库规范化技术应用于OOP吗?否,因为OOP已经有针对标准化解决关系数据库的共享问题的解决方案。
我在这个话题上已经沉默了很长时间。是时候说出来了。
是。我从事对象规范化(以及由此而来的面向对象理论)的形式化工作已有20多年了。
通过意识到至少在理论上数据和代码是可互换的。这意味着规范化和关系运算的原理可以应用于代码以及数据。
到目前为止,效果非常好-我相信所获得的见解一直是我设计,分析和重构能力的“秘密武器”。
在此之前,我没有公开谈论过任何事情,因为我认为最终我将有时间自己完成研究-并生产隐含工具。
但是我得出的结论是,随着我生命中其他所有更重要,更有趣和/或更有利可图的事情的进行,我将没有时间自己完成研究。曾经 还有很可能我根本没有必要的CS理论基础来独自完成工作。
我曾在当地大学询问是否赞助一两个博士学位候选人是否愿意承担起这项事业,但是可惜,我们的当地大学没有为编程语言语义学提供足够的基础。
在这方面已经进行了一些有趣的研究,但是我所知道的所有研究都没有达到预期的目标。它要么错误地假定由于规范化来自关系背景,否则就不适用于面向对象的模型,或者假定规范化仅适用于对象定义的数据。但是,有一些非常有趣的未遂项目...
当您对代码应用规范化时,会发生真正有趣的事情-我认为这是所有重构的基础。
因此,现在我想最好的办法就是说出这句话,也许是要求在DC的DevDays 2011上发表演讲,并找出是否有像我一样对这件事感到兴奋的社区。
这是先睹为快:规范化是使某些内容最少且不冗余的过程。因此,面向对象编程的“不要自己重复”(DRY)原理清楚地体现了标准化的目标。我相信我可以证明所有众所周知的面向对象的设计/编程/重构原理都是对象规范化的逻辑结果。我想我也可以证明,使用对象普通形式(ONF)的系统可以完成的工作不仅仅是重构。
开始时是对Rein Henrichs出色答案的评论,但时间太长...
归一化适用于关系数据。它用于避免重复,由于每个数据仅存储在一个位置,因此可以更轻松地确保数据完整性。您可以通过查找规范化形式的违规并进行更正来规范化数据库。
面向对象编程适用于数据操作。它旨在将处理数据的方式组合在一起。您可以将类似的技术应用于类,以消除重复的方法,也许可以通过查看操作操作或依赖于哪些数据来实现。例如,从面向对象的角度看,1NF在类内将没有任何重复的操作。3NF可能与良好的继承结构相对应,在继承结构中,常用代码位于超类中。我相信您也可以在其中找到适合依赖注入的地方。通过发现违反良好设计原则并进行重构的方法,可以达到更好的设计(尽管还没有发现正常形式的东西)。
在这两个世界中,实际上都没有任何算法可以达到良好的设计。正如Rein Hendrichs指出的那样,有许多原则可以识别潜在的问题(即代码气味)。设计模式和最佳实践是人们试图解决它们的一些方法。测试驱动的开发试图通过在外部执行代码来及早找到它们。就像在数据库开发中一样,通过经验和分析可以找到最佳的解决方案。
UML Modeling in Color是类似于标准化的一种非常好的设计业务模型对象的方法。
这是Peter Coad发现的一种设计策略,可以帮助抽象业务模型对象。
不幸的是,《用UML进行彩色Java建模:企业组件和流程》一书售罄,您只能购买二手书。
互联网上有几篇有关此技术的文章。
如果您熟悉关系设计,您会发现Color中的UML建模对指导您很有用: