As the code base grows it will be exceedingly difficult to maintain, and eventually any change in it will result in bugs fixing which will be far more difficult than adding features.

>why would it matter if the user won't be able to see the code itself?

If you can see the code itself, you can derive flaws from it. If it's backend code... now you are subject to a whole host of attacks, because people know the names of your tables. People can utilise specific endpoints and pick flaws in your code.

If it's FE code it's not quite as bad but nonetheless you can still figure out flaws and tailor attacks/exploits based on the code you are looking at

What if it's an app that no one is able to see its code, why would encapsulate matter?

So it's only about code coupling?

By encapsulating your code you are defining and separating the external interface from the internal implementation. By doing that the internal implementation can change without breaking everyone who used your components. Without it anyone who uses your components could come to rely on any method or variable you used. If a better implementation comes around and those methods or variables are removed then their code will break.

Similarly if your component is complex, say with lots of concurrency/threads, then leaving internal methods or variables externally accessible can cause all sorts of problems. External components could access those internal structures directly, potentially bypassing any protections you established.

It's about maintainability.

Because encapsulation prevents people from seeing that code (sort of).Another example of encapsulation is it can enforce devs to adopt better practice. It leads to less undefined behaviour.

As a dev, I should only be modifying/impacting code that I need to be interacting with. I shouldn't be able to accidentally modify X code. If other devs adopt encapsulation, I'm no longer able to accidentally interact with code I shouldn't be able to. This reduces undefined behaviour which is a huge part in producing a stable app.

If my system is allowing for tons of (irrelevant) places to interact with otherwise irrelevant code, I could end up introducing bugs/issues every time I PR code. But if my team adopts encapsulation, it reduces that risk.

In other words, it reduces dependencies. Every dependency you add to a module increases the chance of bugs and increases the complexity of that module. So it's harder to work with a system if there are 10000000 potential dependencies vs only a few. It's cleaner and more clear.

Technically nothing would happen. Some languages don't have the concept.

You can think of a program as a list (not a List class) of objects or methods.

For a small grocery list, it's just a list of a few items, you're probably just write them down on a single page with no separation. A small program would be okay with only using one or two classes, it's no big deal.

But say we're talking about multiple store chains in a corporation. You're going to list different stores and different positions in corporate. Each store is going to have their own employees listed, but most people outside of the store is going to be concerned with the store manager and assistant manager so their numbers will be listed for thise outside the store. Inside the store everyone should know about and interact with their coworkers.

Ecapsulation is kind of the same idea. You break code into different classes. Not every class should be concerned with every function or object of a different class, so some objects/methods are marked for different level access so only some or certain objects can interact with those.

One good use of ecapsulation, is imagine you have a method that you have some kind of input like age. A problem with using a public variable from a different class is that you can change the variable and you might not catch every error input like a negative number. By making it private and using a public method that changes it, it can only be changed by that method which can catch if the number is negative, or too high or between a range. This makes debugging easier because the only way that variable could be wrong is if the logic in that setter method is wrong.