数据库家伙问:面向对象的设计理论?

时间:2008-10-29 11:48:19

标签: oop solid-principles package-design

我在设计数据库方面做了很多时间,而且这些天我也在使用C#。 OO对我来说很有意义,但我并不觉得我对OO设计的深层理论有很好的基础。

在数据库领域,关于如何设计数据库结构有很多理论,主要概念是规范化。规范化直接控制数据库的结构,并在某种程度上决定如何在数据库中排列实体。

是否有任何类似的概念背后如何设计面向对象程序的结构?

我所要达到的是一个或多个潜在的理论原则,这些理论原则自然地指导开发人员针对特定问题解决方案的“正确”设计。

我在哪里可以找到更多信息?
我应该读一下上班的工作吗?

更新

感谢大家的回答。 我正在阅读的内容似乎没有“OO设计的大理论”,但是有许多重要的原则 - 主要是设计模式的例子。

再次感谢您的回答:)

14 个答案:

答案 0 :(得分:11)

小心一些设计模式文献。

有几种广泛的类定义。持久对象(类似于关系表中的行)和集合(类似于表本身)的类是一回事。

某些“Gang of Four”设计模式更适用于活动的应用程序对象,而不太适用于持久对象。当您通过抽象工厂之类的东西进行搏斗时,您将会遗漏OO设计的一些关键点,因为它适用于持久对象。

对象导师What is Object-Oriented Design?页面中有很多人需要知道从关系设计过渡到OO设计。

标准化,BTW,并不是始终适用于关系数据库的一揽子设计原则。当您有更新事务时,将应用规范化,以防止更新异常。这是一个黑客,因为关系数据库是被动的东西;你要么必须添加处理(比如类中的方法),要么必须传递一堆规则(规范化)。在数据仓库世界中,标准规范化规则并不那么罕见(或不存在)更新。

因此,对象数据模型没有“像这样规范化”。

在OO设计中,设计持久对象的最重要规则可能是Single Responsibility Principle

如果您设计的课程对现实世界的对象具有良好的保真度,那么会以非常集中的方式为这些课程分配职责,您会对对象模型感到满意。您将能够将其映射到具有相对较少复杂性的关系数据库。

事实证明,当你从责任的角度来看待事物时,你会发现2NF和3NF规则适合于合理的责任分配。独特的按键仍然很重要派生数据成为方法函数的责任,而不是持久属性。

答案 1 :(得分:6)

“设计模式”一书是您的下一步 http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612

但是,您不必使用OO方法来处理所有事情。不要虔诚于此。如果一个更程序化的方法感觉更加明确,那么就这样做吧。 OO新手倾向于暂时搁置一段时间。

答案 2 :(得分:4)

我认为Agile Software Development, Principles, Patterns, and Practices非常好。

它提供了很多深入讨论列出的OO原则here

  • 面向对象设计和依赖管理的原则
  • SRP - 单一责任原则
  • OCP - 开放封闭原则
  • LSP - Liskov替代原则
  • DIP - 依赖性倒置原则
  • ISP - 接口隔离原则
  • REP - 重用版本等效原则
  • CCP - 共同封闭原则
  • CRP - 共同重用原则
  • ADP - 非循环依赖原则
  • SDP - 稳定的依赖原则
  • SAP - 稳定抽象原则

答案 3 :(得分:2)

如果您习惯于构建规范化数据库,那么面向对象的设计应该是您自然而然的。您的类结构最终看起来很像您的数据结构,明显的例外是关联表变成列表,查找表变成类中的枚举。

总而言之,我会说你在关系数据库中进入OO设计要好得多,而不是向另一个方向发展。

答案 4 :(得分:2)

如果您想真正掌握O-O,请使用Smalltalk。 ST是一种 OO语言,非常适合它。一旦你克服了范式驼峰,你就已经学会了OO,因为如果没有它,你就无法真正做到Smalltalk。这就是我第一次学习OO。

答案 5 :(得分:1)

检查this的结果。从每个问题中学习。

答案 6 :(得分:1)

我真的很喜欢Head First Design Patterns非常平易近人,以及Arthur J. Riel的优秀Object oriented Design Heuristics

答案 7 :(得分:1)

David West的对象思维。一个有趣的阅读..
你是从黑暗的一面......按照这本书;)数据库思维一直是OO程序员的诅咒。它们是光谱的两端。例如

  • 数据库思维将数据归结为其他所有内容...根据它们如何适应DB模式或ER图来规范化和创建类型.OO思维根据行为和协作创建类型,并且不会将数据属性识别为一切都很重要
  • 数据库来自科学人,他们重视形式化和方法。 OO来自使用启发式和经验法则的人,并通过艰难而快速的过程重视个性和社会互动。

即使在转向OO语言之后,COBOL程序员也可以编写COBOL程序。看看像Thinking in Java这样的书,第一部分总是详细说明OO(学徒)的原则。跟进对象思维(熟练工)并及时......掌握。

答案 8 :(得分:1)

This site lists 101 title ...设计模式,重构等......看看吧......这将是一个很好的起点......

答案 9 :(得分:1)

通过记住现实世界对象来建模对象。

我们目前正在开发机器自动化软件。其中一台机器有两个装载端口用于供给原材料,而其他所有机器只有一个。到目前为止,在所有模块中,我们将端口信息(当前设置,当前分配给它的批号等)作为代表机器的类中的成员。

我们决定创建一个包含端口信息的新类,并为此MachineXY类添加两个LoadPort成员。如果我们之前已经考虑过,那么对于所有这些单端口机器我们都会做同样的事情......

答案 10 :(得分:0)

您应该查看UML,这是给OOD的整个过程。

我建议买一本书(或一对),因为理论很大,大多数人都会选择最适合手头项目的技术。

答案 11 :(得分:0)

开始阅读设计模式,来自Martin Fowler。 :)

它们是OOP最实际的用途。

答案 12 :(得分:0)

我猜你的意思是数据库世界中的OO。

存储对象的面向对象的数据库从未真正捕获过,因此您当前正在将对象映射到关系数据库。 ORM或对象关系映射是用于描述执行此映射的软件的术语。理想情况下,这为您提供了开发人员可以与对象进行交互的两个世界中的最佳选择,并且在数据库中,所有内容都存储在可以进行标准调整的关系表中。

答案 13 :(得分:0)

在DBA俚语中:面向对象的设计不过是安全操作界面背后的正确规范化数据,安全意义,看操作,而不是直接数据