Are there any patterns or is there any standard terminology for inheriting data/objects?_问答_开发者

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开发者_如何学Go methods of .NET classes with and without their inherited methods or inspecting prototypes in Javascript, but here I'm 'inheriting' records/objects.

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.

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 defines two basic types of relationships:

A is a B
A has a B

Within the second category you have subcategories:

A contains B
B is a component of A
A is associated with (or references) B

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.