I'm working on a tower defense game at the moment and have realized that I'm not really following any standard approach when it comes to updating the values of fields between classes, which I don't like. For example, I have a build manager singleton which is being used to hold information on what tower has been selected in the UI, and when an available space on the game grid is clicked then that tower is built. Currently, I'm using a public GameObject named TowerToBuild inside a BuildManager class to hold this data. At the beginning of the game, the BuildManager class assigns a default standard tower to this variable. When updating a value like this from another class, the UIManager for example, is it best to: A. Keep the variable public (or property with public set method) and update the value directly by accessing BuildManager.Instance.TowerToBuild and assigning the new tower to it. B. Add an UpdateTowerToBuild() method to the BuildManager class which accepts the GameObject as a parameter and update it by calling this method. It seems I've been doing a bit of both over the past few months, depending on things I've read or tutorials I've taken and I'd much prefer to have a standard approach. Also, I know that option B would allow for additional logic to be built inside the method which we may want to live inside the BuildManager class itself. Including this logic as part of a property would also work here of course, and my research on property usage so far has given me an insight in to how shorter, simpler pieces of logic generally should exist in properties and more complex pieces inside methods. I feel like I have an ok understanding of this. I'm more interested in the very simple use case above, where we're just updating a field. Are they both exactly the same? Just a design choice? Do you use both options or try to stick to one for consistency? Feedback much appreciated!