在日常编程中,您需要多久创建一次真正的类层次结构?

对我来说,有时子类化会使问题更清楚或更容易,但并不经常。

我最大的问题是编程课程和文本通过基类(与接口或动态类型相比)对继承、层次结构和多态性给予了如此多的重视。这有助于创建一大批程序员,将所有东西和它们的母亲都分为子类。

这个问题的答案并不完全是语言不可知论;

有些语言(如Java)的可用语言功能集相当有限,这意味着子类化非常常用,因为它是一种方便的重用方法和技术继承。

在我参与的上一个C#项目中,我们差不多在几周内完成了所有的类层次结构。在那之后,差不多结束了。

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

其他语言也会有同样影响此组合的其他特性(我想到了混音)

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

当您处理您非常熟悉的问题域并且已经有了一个通用的代码库可以使用时,您通常不需要创建新的类层次结构。当你遇到你没有现成解决方案的问题时,你就开始建立自己的解决方案。

它还非常依赖于您开发的应用程序的类型。如果你的领域已经有了公认的惯例和图书馆,那么可能就没有必要重新发明轮子(除了个人/学术兴趣)。有些领域本来就没有那么多可用的资源可供使用,在这些领域中,你会发现自己大部分时间都在从头开始构建一切。

关于类层次结构,我想你的意思是,你总是必须在你的对象模型中得到某种继承,那么答案是否定的。但是你可能经常会找到一些公共代码,将其分解,并创建一个基类来包含公共代码。

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

这取决于你所说的层次结构——继承还是分层?

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

这实际上取决于你所从事项目的类型/阶段。我每天都会这样做,因为我正在为一个新数据库开发数据库内部构件,创建相关的库/框架。如果我在一个成熟的框架内使用其他人的库,我会想象这样做会少很多。

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

我发现类层次结构最有利的时候是当对象之间的关系确实匹配域中的真正“是-是”关系时。