寻找孩子

发布于 2024-09-29 13:18:05 字数 526 浏览 2 评论 0 原文

我有 A 类。A 类负责管理 B 对象的生命周期,它包含 B 对象的容器,即 map,每个 B 对象包含 C 对象的容器,即map。我为整个应用程序提供了一个全局 A 对象。

我有以下问题: 我有 CGuid 对象,我想用它来查找我的 C 对象。但为此我还需要知道 BGuid 对象,它会告诉我应该在哪个 B 对象中查看我的 C 对象。但我拥有的只是 CGuid,这意味着我必须检查每个 B 对象以查看它是否包含我的 C 对象。但我认为这很混乱。 我想也许我应该有另一个类 M ,它将包含我所有 C 对象的映射,并且我可以使用 CGuid 直接在其中进行搜索,但这仍然意味着我需要维护额外的映射以用于搜索。

另外,我将来除了包含 map 的 C 类之外,因此对于 D 对象我也会遇到同样的问题,这次更糟糕,我将需要 Bguid,Cguid,并且Dguid 找到我的 D 对象。

如何解决这个问题?

I have class A. Class A is responsible for managing the lifetime of B objects and it contains container of B objects that is map<BGuid,B>, and each B object contains container of C objects which is map<CGuid,C>.I have one global A object for the entire application.

I have the following problem:
I have CGuid object and I want to use it to find my C object. But to that I also need to know the BGuid object which will tell me in which B object I should look my C object. But all I have is the CGuid, which means that I have to check every B object to see if it contains my C object. However I think that this is messy.
I thought that maybe I should have another class say M which will contain map of all my C objects , and I can search directly in it just with CGuid, still this means that I need to maintain extra map just for searching.

Also I except in the future my C class to contain map<Dguid,D> so I will have the same problem for the the D objects , this time even worse, I will need Bguid,Cguid, and Dguid to find my D object.

How to solve this problem ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

风铃鹿 2024-10-06 13:18:06

你们有一种经典的父母-孩子关系。
我建议您通过不指定如何处理(即使用地图)来改进您的设计。
使用一个容器来存储children,并让children有一个指向Parent的指针。
这样就可以很容易地从任意点遍历到顶部。

对于这些情况,一个有用的 OOP 设计模式是 CompositePattern

You have a classic relationship of Parent - Children.
I suggest you to improve your design by not specifying how is handled (i.e. with maps).
use a container to store the childrens, and let the childrens have a pointer to the Parent.
In this way is easy to traverse from any point up to the top.

A useful OOP Design pattern for these cases is the CompositePattern

老子叫无熙 2024-10-06 13:18:06

内存有限制吗?如果没有,我会维护反向查找表(映射),所以你需要一个 C->B,当你添加 D 时,你需要第二个 D->C,所以如果你有 C,才能正确定位它,需要一次查找才能找到 B,然后从 A 开始再向下遍历两次。比遍历所有 B 寻找 C 快得多!

另一种选择是,您是否可以控制 Guid,如果可以,您可以尝试将“路径”信息编码到 Guid 中。例如,B guid 是“B.1”、“B.2”、“B.3”等。“.”后的后修复分隔符告诉您它是哪个 B。添加 C 时,您可以简单地添加一个额外的“.”,即 C 1 的 guid 是(假设它存储在 B 1 中)=“B.1.1”,所以现在要找到该对象,您需要解析密钥,瞧你有通向 C1 的“路径”。

Do you have any restrictions on memory? If not, I would maintain the reverse lookup tables (maps), so you need one for C->B, when you add D, you need a second D->C, so if you have C, to locate it correctly, you need one lookup to locate B, then from A you can traverse down with a further two lookups. A lot quicker than iterating through all Bs looking for C!

Another alternative, do you have control over the Guid, if so, you could try encondig the "path" information into the guid. Say for example the B guid is "B.1", "B.2", "B.3" etc. the post fix after '.' separator tells you which B it is. When you add C, you can simple add an extra '.', i.e. C 1's guid is (let's assume it's stored at B 1) = "B.1.1", so now to find the object, you parse the key, and voila you have your "path" to C1.

顾冷 2024-10-06 13:18:06

map, map>, map>< /code>

通过 GUID,您可以获得对象和对象的父对象。有了对象你就得到了GUID。从头开始递归。

map<BGuid,B>, map<CGuid,pair<B,C>>, map<DGuid,pair<C,D>>

With GUID you get the object and object's parent. With object you get GUID. Recurse from beginning.

夏九 2024-10-06 13:18:06

您可以将子 GUID 的范围分配给每个父 GUID。假设 BGuid 在区间 [0, 9] 内,CGuid 在区间 [0, 99] 内。您现在可以使用如下函数将十个 CGuid 映射到每个 BGuid

mapGuids(B): CGuid => BGuid = B % 10

现在您将始终知道在树中采用哪条路径。当有很多节点时,您需要保持树平衡以获得更好的性能。

You could assign ranges of the children's GUIDs to every parent GUID. Suppose BGuid is in the interval [0, 9], and CGuid in the interval [0, 99]. You could now map ten CGuids to every BGuid with a function like this:

mapGuids(B): CGuid => BGuid = B % 10

Now you will always know which path to take through the tree. You will want to keep your tree balanced for better performance when there are many nodes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文