深层类继承层次结构 - 坏主意? [英] Deep class inheritance hierarchy -- bad idea?

查看:175
本文介绍了深层类继承层次结构 - 坏主意?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

希望大师能够散发一些光芒。非常高的概述是,我不是初学者编码,但仍然是新的OOP。这组消息类是我们正在编写的大型模拟应用程序的核心,我不想这么做 - 这个接口将应用程序从顺控程序切换到执行程序,反之亦然。



我的问题是,这是一个继承层次结构这是一个糟糕的主意(图像还没有充实,可能会在最后5或6深)。这是相对于有一些子类只是有一个有向的关联到他们的父类,而不是继承。



我读过一个深层继承层次结构是不是一个好主意,如果一个子类只继承父类的数据,那么你应该将父类作为数据包含在子类中,但是我很难把我的头围绕为什么。如果我决定做一个继承层次7层或类似的东西,我们会发生什么坏事?显然,这是一个小的性能打击,改变在层次结构顶部的东西将有巨大的波纹在整个应用程序,但除此之外,我没有看到一个问题。除此之外,我对性能上的细微差异很少。





(奖励问题:是否有一个现成的包来处理这种东西?我们大多数低级物理模拟处理,但是我们要写的测序程序,我只是怀疑我的布局是非常类似于我之前的10000个模拟开发者)。



(奖励问题#2:仿真系统和OOP程序设计的任何主人都不会讨厌住在洛杉矶?我们在招聘。)

解决方案


如果子类继承的只是具有父类的数据


这是一个坏主意。有这样的理解,你定义基类作为一组(具体)类将要遵守的最通用的合同。这通常意味着您的合同是关于行为而不是实施。


会发生什么坏事我们如果我决定继承层次7层或类似的东西?


这里的主要问题是平凡:




  • 脆弱的基类(对base的更改是衍生的噩梦)

  • 增加耦合基本类紧耦合)

  • 封装弱化

  • 测试问题(叶级别覆盖方法不能被测试才能正确再现最终用户行为

  • 维护(来自强耦合)



(您很想在为什么选择Ada不受欢迎阅读本文,特别是第6题,第6段。)


有现成的包装可以处理这种东西吗?


我不知道你在找什么,但是如果你正在寻找一个自动化的层次结构简单化,知道任何。此外,如果这样的包存在,它将高度依赖于您的选择的语言,你没有提到一个。



请注意,大多数时候,这些问题可以通过查看聚合或traits或依赖注入或其他方式来解决。这些是设计时间问题,通常(IMO)在白板上最好的解决方案,而不是编译器和数百万的LOC。


hoping a grandmaster can shed some light. Very high overview is that I am no beginner to coding, but still new to OOP. This set of message classes is at the heart of a large simulation application we're writing, and I don't want to do it stupidly--this interface cuts the application in half, from sequencer to executer and vice-versa.

My question is whether or not it's a bad idea to have an inheritance hierarchy this deep (image is not yet fleshed out, might go 5 or 6 deep in the end). This is as opposed to having some of the child classes just have a directed association to their parent class, instead of inheriting.

I've read that a deep inheritance hierarchy is not a good idea, and that if a child class is inheriting simply to have the parent's data, then you should simply include the parent as data in the child, but I'm having a hard time wrapping my head around why. What bad thing is going to happen to us if I decided to make an inheritance hierarchy 7-deep or something like that? Clearly there's a small performance hit, and changing things at the top of the hierarchy is going to have huge ripples throughout the app, but other than that I don't see an issue. Aside, I care little about minor differences in performance.

(bonus question: Is there an off-the-shelf package that handles this kind of stuff? We have most of the low level physical simulations handled, but the sequencing program we're going to have to write. I just have this suspicion that what I've laid out is very similar to what about 10,000 simulation developers before me did.)

(bonus question #2: any masters of both simulation systems and OOP programming, that would not hate living in Los Angeles? We're hiring.)

解决方案

that if a child class is inheriting simply to have the parent's data

This is a bad idea. There's this understanding that you define base classes as the most generic of contracts that a set of (concrete) classes are going to honor. This typically means that your contract is about behavior and not implementation.

What bad thing is going to happen to us if I decided to make an inheritance hierarchy 7-deep or something like that?

The major issues here are mundane:

  • Fragile base classes (changes to base are a nightmare for the derived)
  • Increased coupling (with too many base classes comes tight coupling)
  • Encapsulation weakens
  • Testing issues (leaf level overridden methods can't just be tested to reproduce end-user behavior correctly always due to multiple chained calls here and there)
  • Maintenance (comes from strong coupling)

(You many want to peruse this paper on Why Ada isn't popular, particularly, Item 6, para 6.)

Is there an off-the-shelf package that handles this kind of stuff?

I'm not sure what you are looking for, but if you're looking for an automated hierarchy simplifier then I don't know of any. Also if such a package exists it'll be highly dependent on your language of choice and you haven't mentioned one.

Note that most of the times such issues can be resolved by looking at alternatives like aggregation or traits or dependency injection or whatever. These are design time issues and are typically (IMO) best ironed out on a whiteboard than with a compiler and millions of LOC.

这篇关于深层类继承层次结构 - 坏主意?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆