继承数据/对象是否有任何模式或标准术语？
我有一个 A 类，其中包含 B 类对象的集合。 A 类还可以从 A 类的其他实例“继承”（由于缺乏更好的术语）B 类的对象集合。为了对此进行建模，A 类的实例指向 A 类的其他实例（我控制循环引用） ）。
一个简单的具体例子可能是，一个人有亲生孩子，但也“继承”了其配偶和前配偶的孩子。
我在运行时在应用程序中使用带有或不带有继承对象的 A 类实例。也就是说，在不同场景的应用程序上下文中，A 类实例的两个“投影”对我来说都是有意义的。
我的问题是，是否有编码此类模型或标准术语的模式？我认为“继承”这个词在这里并不合适。我有自己的技术处理方法和繁琐的术语，但我想象有一个我可以遵循的标准模式，但我似乎找不到。
一个不完美的类比是检查 .NET 类的方法（有或没有继承的方法）或检查 Javascript 中的原型，但在这里我“继承”记录/对象。
I have a class A that has a collection of objects of Class B.
Class A can also 'inherit' (for lack of a better term) the collection of objects of Class B from other instances of Class A. To model this, instances of Class A point to other instances of Class A (I control for circular references).
A simplified concrete example might be that a person has biological children but also 'inherits' children from their spouse and ex-spouses.
I use instances of class A with and without the inherited objects in my application at run-time. That is, both 'projections' of instances of Class A are meaningful to me in the context of my application in difference scenarios.
My question is, is there a pattern for coding this sort of model or standard terminology? I don't think 'inherit' is the right word here. I have my own ways of handling it technically and my own cumbersome terminology but I'm imagining there is a standard pattern I can adhere to that I just can't seem to find.
An imperfect analogue would be inspecting the methods of .NET classes with and without their inherited methods or inspecting prototypes in Javascript, but here I'm 'inheriting' records/objects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对我来说，看起来像复合模式，其中A对象是复合对象，B对象是叶子。指向其他对象 A 的一个对象 A 是根项。区别似乎在于，当获取叶项时，您可以区分根项是否包含来自它知道或不知道的其他组合的叶项。
Looks like the composite pattern to me, with A objects being composites and B leafs. The one object A that points to other objects A is a root item. The difference seems that when getting leaf items you distinguish whether the root item includes leaf items from other composites it knows of or not.
不，我不认为（A）您正在做的事情有常见的 OOP 习惯用法，也不认为（B）有任何与您相似的突出模式。 (C)，那就绝对没问题。现在也许你应该这样做，也许你不应该这样做。每当你正在做一些你很难描述的事情时，你当然应该反思一下自己，并想知道是否有更简单的方法来做到这一点。但是，缺乏描述您的模型的通用术语，并且它不符合您听说过的“模式”，本身并不表示存在问题。课程有时必须在幕后做一些古怪的事情。这就是重点。如果您为这些类的使用者封装了很多复杂性，并且对于他们来说是直观的、合乎逻辑的并且是可发现的，那就太好了！
然而，不正确地使用常用术语来试图帮助别人理解是错误的。事实上，您上面使用的术语继承确实让我感到困惑，而且我仍然不能 100% 确定我拥有它。是这个吗？
ClassA 类的对象维护 ClassB 对象的集合。此外，ClassA 对象的某些功能不仅必须作用于它自己的 ClassB 对象，而且还作用于其他 ClassA 对象所维护的对象。为此目的，ClassA 对象维护对其他 ClassA 对象的引用。
当然，假设我的理解是正确的，我认为这是描述它的好方法。而这里恰恰不存在继承，如果用这个词的话，会让人感到困惑。另外，如果您正在做的事情与某处的某些模式不匹配，请永远不要感到苦恼。
No, I don't think (A) there are common OOP idioms for what you're doing, nor (B) any prominent patterns similar to yours. And (C), that is absolutely fine. Now maybe you should be doing it this way and maybe you shouldn't be. Whenever you're doing something that you have a hard time describing, you should certainly second-guess yourself and wonder if there's a simpler way of doing it. But, the lack of common terminology for describing your model, and it not fitting into a "pattern" you've heard of, does not in itself indicate a problem. Classes sometimes have to do wacky stuff under the hood. That's the point. If you're encapsulating a lot of complexity for the consumers of these classes, and it's intuitive and logical and discoverable for them, then great!
It is a mistake though to improperly use common terms to try to help someone understand. In fact, your use of the term inherit above really confused me, and I'm still not 100% sure I have it. Is it this?
An object of class ClassA maintains a collection of ClassB objects. In addition, some of a ClassA object's functionality has to act upon not only its own ClassB objects, but those maintained by other ClassA objects as well. A ClassA object maintains references to other ClassA objects for this purpose.
Assuming I have it correct of course, I think that's a good way to decribe it. And since there is precisely no inheritance here, it would confuse people if that term were used. Also, do not ever, ever, every be distressed if what you're doing does not match some pattern somewhere.
我认为你的模型有问题。如果一个类的两个或多个实例与另一个类的实例有关系，正确的模型不是让其中一个实例包含第三个实例 - 而是让它们都参见第三个。对于人类父母，每个人都应该引用相同的“后代”（人类孩子的列表）对象。然后，您可以通过引用计数等机制控制引用的类。
I think your model is at fault. If two or more instances of a class have a relation with an instance of another class, the correct model is not to make one of the instances contain the third - it is to make both of them refer to the third. In the case of human parents, each should refer to the same "offspring" (a list of human children) object. You then control the referred to class via mechanisms such as reference counting.
OOP 定义了两种基本类型的关系：
在第二个类别中，您有子类别：
前两个类似，但您的具体示例显然指的是第三个。父母并不包含孩子，他们与孩子有联系，当某人嫁入家庭时，他们与现有家庭建立了新的关系（关联）。
所以我想答案是否定的，不存在“模式”。您只需将一组关系从一个实例复制/转换到另一个实例。
OOP defines two basic types of relationships:
Within the second category you have subcategories:
The first two are similar, but your concrete example clearly refers to the 3rd. Parents do not contain children, they are related to their children, and when somebody marries into family, they have new relationships (associations) created with the existing family.
So I guess the answer is no, there is no "pattern." You are simply copying/transforming a set of relationships from one instance to another.