Is there any benefit in in having an instance variable within a class which is an instance variable-CodePudding

For example lets say there is a player object with an instance variable:

public class Player {
    private final PlayerConnection connection;
    private final PacketSender sender;


    public PlayerConnection getConnection() {
        return this.connection;
    } 


    public PacketSender getSender() {
        return this.sender;
    } 

}

then another object PlayerManager:

public class PlayerManager {

    private final Player managedPlayer;
    private final PlayerConnection connection;
    private final PacketSender sender;

    public PlayerManager(Player player) {
        this.managedPlayer = player;
        this.connection = player.getConnection();
        this.sender = player.getSender();
    }
  
}

Is there any benefit to having connection and sender as instance variables of PlayerManager since the player object is already an instance variable. Or is it better to not even pass the player in and only create instance variables for the necessary objects (even if the PlayerManager needs access to many more variables within Player than the two listed here).

As described above what is the preferred choice in terms on style or runtime.

CodePudding user response：

If these classes are designed to work closely together it can make sense to 'duplicate' that data. You'd have to weigh memory and maintenance effort for the copies versus speed when trying to access the data.

You can see similar patterns in many frameworks and libraries. Look at Java Swing, or at org.w3c.dom.Node and it's derivatives.

CodePudding user response：

There is no benefit, and worse they two values may differ. Don't do it.

As for "performance", you could not measure the different between these two:

myPlayerManager.getPlayerConnection()
myPlayerManager.getPlayer().getPlayerConnection()

As for design, remove getPlayerConnection() from Player - how the player is currently connected is transient data that only the player manager needs to know, not an intrinsic attribute of the player.

CodePudding user response：

There are some benefits...

PlayerManager does not depend on Player having those members. If a future version of Player does not need them, you can remove them without the need to change PlayerManager.

It is also more clear what PlayerManager depends on, which can be helpful when someone is learning the class for the first time. During code reviews it's more obvious the dependencies changed than if the code starts access a property. It's also more obvious when searching for usages of PlayerConnection.

They're fairly minor benefits in small code bases or within small teams, but they can be helpful patterns when more people are involved or when working with a code base large enough that you can forget how parts of it work.