您是否经常需要在日常编程中创建真正的类层次结构?

时间:2008-12-14 16:21:31

标签: language-agnostic oop

我使用大量数据库创建业务应用程序。大多数编程工作只是将组件连接到数据库并修改组件以适应一般的接口行为。我主要使用Delphi及其丰富的VCL库,并且通常购买所需的组件。我将大部分业务逻辑保留在数据库中。我很少有机会从下往上构建一个好的类层次结构,因为根本没有必要。其他人有这种经历吗?

9 个答案:

答案 0 :(得分:4)

对我而言,有时候子类化问题更清晰或更容易,但不常见。

在给定的设计中,由于它被重构,这也会发生很大的变化。

我最大的问题是编程课程和文本通过基类(与接口或动态类型相比)对继承,层次结构和多态性给予了很大的重视。这有助于创建大量程序员,将所有事物和他们的母亲分类。

答案 1 :(得分:3)

这个问题的答案并非完全与语言无关;

像Java这样的语言有一套相当有限的语言特性,这意味着子类化经常被使用,因为它是一种方便的重用方法,技术继承。

C#的闭包和lambda由于技术原因而不太相关。因此,正常继承用于语义原因(如cat扩展动物)。

我工作的最后一个C#项目,我们或多或少在几周内制作了所有类层次结构。之后它或多或少地结束了。

在我当前的java项目中,我们一直在创建新的类层次结构。

其他语言将具有其他类似影响此构图的功能(混合素会浮现在脑海中)

答案 2 :(得分:1)

我戴上我的建筑/设计帽子大概每月一到两次。它可能是我戴的最好的帽子,也是最有趣的。

取决于您的项目所处的生命周期的哪个阶段。

答案 3 :(得分:1)

当您熟悉并且已经拥有可用的公共代码库时,您通常无需创建新的类层次结构。当你遇到问题时,你没有现成的解决方案,你开始建立自己的解决方案。

它还非常依赖于您开发的应用程序类型。如果您的域已经有广泛接受的约定和库可供使用,那么可能没有必要重新发明轮子(除了个人/学术兴趣)。有些地区本来就有较少的可用资源可供使用,在那些地方,你会发现自己在大多数时间都是从头开始构建一切。

答案 4 :(得分:1)

大多数应用程序,尤其是业务应用程序,至少包含某种业务逻辑。我认为业务不应该在数据库中,而应该在应用程序中。您可以将引用完整性放在数据库中,因为我认为这是一个不错的选择,但业务逻辑应该只在应用程序中。

通过类层次结构,我想你的意思是你总是必须在对象模型中得到一些继承,然后答案是否定的。但是很有可能你经常可以找到一些公共代码,将其考虑在内并创建一个包含公共代码的基类。

如果您同意我的观点,即业务逻辑不应该在数据库中,而应该在应用程序中,那么我建议您查看MVC设计模式来指导您的设计。您会发现您的设计包含类或对象。您的VCL将代表您的View,您可以让您的Model类直接映射到数据库表,即模型中类中的每个成员对应于数据库表中的一个字段(同样,这是常态但会有异常,这种简单性不适用)。然后,您将需要一个层来处理Model类到数据库表的CRUD(创建,读取,更新,删除)。您最终会得到一个更易于维护和增强的“分层”应用程序。

答案 5 :(得分:1)

这取决于层次结构的意思 - 继承或分层?

当面向对象的语言首次出现时,继承被过度使用。复杂的层次结构很常见。现在,接口(如在Java和C#中)提供了一种更简单的方法来获得多态性的好处而没有继承的复杂性。我很少再使用继承了。

然而,分层在创建大型应用程序时至关重要。分层可以防止一般的低级类(如列表)直接引用特定的高级类(如Web浏览器窗口)。据我所知,没有一种正式的方法来描述分层,但有一般指导原则(模型 - 视图 - 控制器(MVC),与业务逻辑分离的GUI逻辑,单独的数据与表示等)。

答案 6 :(得分:0)

这实际上取决于您正在处理的项目的类型/阶段。我碰巧每天都这样做,因为我正在为新数据库创建数据库内部,创建相关的库/框架。如果我使用其他人的库在一个成熟的框架内工作,我想这样做会少得多。

答案 7 :(得分:0)

我正在为我们公司的产品做基础设施,所以我写了很多代码,以后其他团队的人员会使用它们。所以我最终写了很多抽象类,接口,层次结构等等。大多数情况下,它只是“抽象/虚拟类中的默认行为,其他程序员可能会覆盖”的模式。

非常具有挑战性,我必须说。

答案 8 :(得分:0)

我发现类层次结构最有用的时间是对象之间的关系实际上与域中的真正“is-a”关系匹配。

但是,如果我可以避免使用大型层次结构,那么我将会因为映射到关系数据库时更加棘手,并且可能会使数据库设计复杂化。由于您说大多数应用程序都大量使用数据库,因此需要考虑这一点。