Why making everything public is bad with examples

[spice gorge]

I'm a bit busy know, so created a thread for now. When I have some time I'm gonna explain with examples based on your code. But maybe someone else could share their ideas as well until then.

[tawny dew]

It's okay because I really need to sleep but I'll check this in the morning :)))

[tawny dew]

I am awake now 😄

[spice gorge]

Sorry. Didn't have a chance to give it a thought.

Okay, assume you have the fields of this button referenced from all over the scene. Since they are public you're tempted very much to access them from somewhere else. For example you might want to change the color of the close image or something. Now you have all kinds of references to this script fields, but then either a new team member comes to the project or you after a while. They want to remove the close button for whatever reason(maybe they's a timer instead of a button now). They simply remove the component or the whole gameobject and maybe even delete the script. But now you have a lot of both compile errors and actual errors at runtime(since the reference to the button is invalid now) and some of them might be even harder to track(for example there's one reference that you get with Find or something at the very end of your game). Now you've got a lot of potential bugs/errors in your project simply because the button was giving access to things it shouldn't. Moreover, it was also doing stuff that it shouldn't do. You'd think that close button would only close something(a ui panel?). It for some reason also sets the camera position, finds and activates/deactivates objects, seta text. You only wanted to remove a ui button, but with it all of this extra functionality(that is not the responsibility of the button is gone as well). Another point is that the code is harder to read. I see a public fieldsl, a public method, I start thinking of a reason why it was implemented like that. Does it need to be called from somewhere else? Where is it called from already? Will something break if I call it myself?
And again about providing access to things you don't want to provide. base_positionis public and totally accessible from outside. What if someone(like future you) sets it to something else without understanding the implications(since it's public it should be fine to set it's value, right?)

Here's another one. Let's say you have some internal methods/fields that are called/set as part of some complicated initialization process. For example, you have a method that pools a pooled object. It does all kind of work related to resetting the object state and finally adds it to the pool collection. If you have everything public, you can easily add and remove things from the pool collection without the proper processing/resetting. That could give birth to a whole range of all kinds of bugs. If you only set things to private, you'd avoid accidental access to things that shouldn't get accessed.

[spice gorge]

Basically, by just setting things public by default you allow bad things to happen in the future, make the code more confusing to read and harder to refactor/improve.

[tawny dew]

Hmmmm that does make a bit more sense however if you choose to delete the Close Button (The script is multiple buttons, it's just a file for multiple on click functions so I don't have to look through 40 different files lol) then you'd need to refactor that code with the other components that use it anyways, private or public- right? I see no way that making it private would make it easier to refactor? If some other component is using that piece of code I'd need to refactor it no matter what is what I mean*

[spice gorge]

If most of it's members are private, there's less chance that other code depends on it/couples with it, making it easier to refactor or replace(via an interface for example). When we talk about refactoring, we usually talk about changing the inner workings of some class/function/whatever. Things that are not supposed to be accessed from the outside - private things. You refactor the innards and it doesn't break anything that depends on this code, because there is only few contact points that don't change.