Java: force two-way linked objects

I design a game engine in Java

The core of this engine is that there are two types of assets and attributes, among which assets have an attribute list Most attributes do not need to be linked to their attributes, which means that attributes can and often appear in the list of multiple assets However, there is an extension of attribute called uniqueattribute, which is specific to its asset implementation and takes advantage of a link

>Ideally, if I delete other code, the addAttribute method of my asset looks like this:

public void addAttribute(Attribute attribute){
  if(attribute instanceof UniqueAttribute)
    ((UniqueAttribute)attribute).setAsset(this);
  attributeList.add(attribute);
}

Unfortunately, because they live in different packages, uniqueattribute Setasset() must be public This makes this method confusing for external users of the engine, and I can manually place it by directly using this method, which is a mistake - it seems quite careless. > The second option is to provide asset construction for uniqueattribute, which means that the code for creating points is as follows:

asset.addAttribute(new UniqueAttribute(asset));

Although I can add a checkable or assertable asset to confirm that the correct asset is passed in, I basically rely on the user to connect the two, and I am not willing to do so. > The third option is to bite the bullet and put all 50 java files in the same package so that I can use standard visibility

Is there any pattern or thing that can help these two people connect without exposing the wires, or force me to put everything in a big package?

Irrelevant roar: I always dislike the concept of sub package in Java, which is not extended in any meaningful way As far as Java is concerned, a sub package is a different package, and there are many occasions where more visibility modifiers directly related to this can be used

Solution

My suggestion is that assets, attributes and uniqueattribute should all be in the same package (there may be some other core "engine" classes) You can then use uniqueattribute Standard package visibility for setasset

You don't need to put all other classes in the same package – your asset AddAttribute methods should be public and accessible from other packages, so other applications can only use them directly

So the solution can be called "3 -" in your category

As a more general point of view, we should also consider:

>Whether you really need complex attributes and uniqueattributes – I'm not sure you did, you've implemented a fairly complex game object model before without anything that looks like uniqueattributes If uniqueattribute "needs a link", then maybe it's trying to be too smart / too much? > Even if you do need both, you really want to write code that treats them the same way / as part of the same object They seem to be conceptually different. If you mix two people together, you will eventually write a lot of conditional code. Various other advantages of > attribute are always shared and unchanged - it is more suitable for memory use, concurrency and testability And because they can be quite small, the cost of copying semantics at write time is negligible when needed