处理所有对象 T 的空父 T
基本单位>单位> BaseUnit是ContainerUnit的
- 核心类。
- Unit 添加一个名为 Parent 的 ContainerUnit 属性。
- ContainerUnit 添加一个 List
称为“儿童”的财产。
因此,所有 Unit 类型(包括 ContainerUnit)都必须有一个 ContainerUnit 父级。 ContainerUnit 类型可以具有 ContainerUnit 类型或只是 Unit 类型的子代。
所以你可以有一盒物品,其中一些是一盒物品。
我希望有一个主 ContainerUnit,它被视为所有 Unit 类型的最高级别父级。但这会使其 Parent 属性为空。意思是,我想说“谁是你爸爸?”任何东西,而不知道它在层次结构中的位置,但是如果我询问(例如,在循环中)主容器的父级是谁,它会得到优雅的处理。
我正在寻找其他人已经采取的方法来解决这个问题。我确实搜索过这个,但我的查询运气不佳。
BaseUnit > Unit > ContainerUnit
- BaseUnit is the core class.
- Unit adds a ContainerUnit property called Parent.
- ContainerUnit adds a List<Unit> property called Children.
So, all Unit types (including ContainerUnit) must have a parent that is a ContainerUnit. ContainerUnit types can have children that are ContainerUnit types or just Unit types.
So you can have a box of items, some of which are boxes of items.
I want to have a master ContainerUnit that is treated as the highest level parent of all Unit types. But that would make its Parent property null. Meaning, I want to say "who's your daddy?" to anything, without being aware of its position in the hierarchy, but then if I ask (say, in a loop) who the master container's parent is, it gets handled gracefully.
I'm looking for approaches that others have taken to solve this. I did search for this, I just didn't have much luck with my queries.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
让最外层的“宇宙”容器为其容器返回 null 是传统的做法。这样做的优点是容易。它的缺点是你不知道自己已经越过了宇宙的边缘,直到回来时为时已晚。正如您在评论中所说:使用“null”作为标志是很弱的。
我见过的另外两个解决方案是:
1) Universe 对象是它自己的容器。这样做的好处是没有什么是空的;缺点是走容器链时容易陷入死循环,而且不直观;宇宙实际上并不包含自身。基本上,您使用相等性作为标志,而不是可空性作为标志;这似乎也很弱。
2)当你请求容器时,universe对象抛出异常。这迫使调用者不检查空容器,而是检查“你是整个宇宙吗?”在索要容器之前。也就是说,到了顶峰就停下来,而不是越过顶峰就停下来。这实际上是一种很好的解决方案,因为它迫使人们编写防御性代码。除非你知道有一个容器,否则你不能只是索要一个容器。当然,它要求调用者能够以某种方式识别 Universe 对象,而无需检查其父对象。你需要一个“我是整个宇宙吗?”方法,或要比较的众所周知的单例对象,或用于识别哪个是最顶层容器的其他机制。
第三种方法是否认问题的前提;是否可以构造您的数据类型,以便不需要知道容器,或者最小化了解容器的重要性?
例如,在编译器中,我们当然有很多“容器”链要走,并且我们通过使其包含符号为空(并且它是一个众所周知的单例对象)来向全局命名空间发出信号。现在我们不需要检查父级是否为空,因为我编写了在其之上构建抽象的代码:
太棒了。现在我有了这个辅助方法,我不再需要检查事物的 Container 属性。如果我想知道,“有没有这个东西的容器包含另一个东西?”然后我可以说:
使用 LINQ 的强大功能来移动机械实现细节,例如“我如何确定何时处于顶部?”进入更高级别的辅助方法。然后在“业务”级别编写您的逻辑,而不是在“机制”级别。
Having the outermost "universe" container return null for its container is the traditional thing to do. This has the advantage that it is easy. It has the disadvantage that you don't know that you've gone past the edge of the universe until it is too late to get back. As you said in a comment: using "null" as a flag is weak.
Two other solutions that I've seen employed are:
1) The universe object is its own container. This has the advantage that nothing is null; it has the disadvantage that it is easy to go into an infinite loop when walking the container chain, and it is unintuitive; the universe does not actually contain itself. Basically you're using equality as a flag instead of nullability as a flag; this seems weak too.
2) The universe object throws an exception when you ask for the container. This forces the caller to, instead of checking for null container, check instead for "are you the entire universe?" before asking for the container. That is, stop when you get to the top, instead of stopping when you get beyond the top. This is actually a kind of nice solution because it forces people to write defensive code. You can't just ask for a container unless you know there is one. Of course, it requires that the caller be somehow able to identify the universe object without inspecting its parent. You need an "Am I the entire universe?" method, or a well-known singleton object to compare against, or some other mechanism for identifying which is the topmost container.
A third approach is to deny the premise of the question; is it possible to construct your data type so that the container need not be known, or such that the importance of knowing it is minimized?
For example, in the compiler of course we have lots of "container" chains to walk, and we signal the global namespace by having its containing symbol be null (and by it being a well-known singleton object.) But a lot of the time we don't need to ever check for whether the parent is null because instead I write code that builds an abstraction on top of it:
Great. Now that I have that helper method, I don't ever need to check the Container property of a thing. If I want to know, "is there any container of this thing that contains this other thing?" then I can say:
Use the power of LINQ to move mechanistic implementation details like "how do I determine when I'm at the top?" into higher-level helper methods. Then write your logic in at the "business" level, not at the "mechanism" level.
我能想到的最好的方法就是处理你的 null 情况。也就是说,当您查看
ContainerUnit
并尝试获取其Parent
时,您只需添加一个 null 检查。例子可能是:
另一个例子
The best way I can think of is just to handle your null case. That is, when you're looking at a
ContainerUnit
and trying to get itsParent
you just add a check for null.And example might be:
Another example
我认为当
Parent
属性是层次结构中最高的对象时返回null
是最有意义的,也是最优雅的解决方案。I think having the
Parent
property returnnull
when it is the highest object in the hierarchy makes the most sense and is the most graceful solution.