Then one day you decide you want to aggressively refactor that class. Now you can because the interface can stay the same even though you could completely re-do the guts. Better still: all your tests will still work, as will your class documentation.

Admittedly, my opinion is mainly based around working mostly in C++, but every codebase I work in of significant age is a knitted castle of interlocking classes with poorly thought out accessors and private variables. While the vision of carefully encapsulating implementation details is nice, in practice the discipline required to do so seems unachievable.

Instead of using private members, if I want an interface I explicitly make an abstract base class interface and inherit from it.

This has two advantages: (1) unit tests are simpler when I can poke/prod the concrete internals because they're public. (2) I can make an "include" directory with the interfaces in it when I want to distribute a shared library and those interfaces will be more concise and less likely to leak all sorts of implementation details in the headers.

I think that compared to the giant hairballs of absolutely unmanageable spaghetti classes when done right have made larger scale projects tractable to mere mortals and have significantly improved software maintenance.

Classes done wrong (hundreds or even thousands of classes that all do almost nothing) are a terrible anti-pattern and should be avoided.

The exact same thing goes for services. And in fact for any tool used in a really bad way.

Speaking as a C# developer, I think the concept of classes as tiny programs with tiny APIs works very well.

Everything looked like this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Maybe it's better now but the Java/C# practice of shoveling largely empty classes around with an IDE isn't something I'd point to as a good example.

Now the Fortran code I've encountered, that's the stuff of nightmares (to be fair to Fortran I've also encountered good code, but there seems to be a generation of embedded developers who have no formal programming training that all adopted a style of Fortran inspired by Cthulhu).

I'm sad that I've worked with plenty of codebases that look exactly like that and I twitched a little bit browsing around. :)

Well the last time I regularly used C++ was Borland C++ 3.1 from 1992. I'm not sure you'd be interested in my opinions on the language from 30 years ago.

I lived the past 10 years in a ruby codebase where since effectively everything was public, we didn't mark enough stuff private and you can always YOLO monkeypatch or call things with `send(:method)` there was zero effective encapsulation.

And that pretty much crippled the product because now everything could be a public API so you can't change some shitty little helper to clean the code up somewhere because someone might have written code against that, in their private codebase that you have no visibility at all into. Every change becomes a potentially breaking change, because you have no idea how someone else's codebase might or might have fucked you by digging into your codebase.

Rejecting encapsulation is literally the dumbest post-OO take, and I have the scars to prove it.

Good fences make good neighbors and all that.

While not much difference in C++ specifically, but having a distinction between a class that encapsulates state and a record/struct that is nothing but plain old data is essential in my opinion. Both are useful for different problems.

That's optimistic. I suspect there are some people who would be confused by your statement if they've been exposed mostly to tests that verify the steps taken by the implementation.

In any case, it's not good. Also not uncommon.

Fair enough.

Typically this is a case of people not really getting what unit tests are for, so they end up testing the implementation rather than the behavior.

Yes, that's what private does. My question was more why you should do that.

> the interface can stay the same even though you could completely re-do the guts.

So is the reason to use private that it's a way to tell programmers to not use something in too many places because that will make it hard to change in all those places if you need to change the private member?

Think of the interface to your class as a contract: this is how this class works, from now until eternity (or until the next breaking change ;) ). Relying on implementation details breaks that contract, the contract is on the interface not on the guts.

It won't be 'hard to change' it may be impossible to change. Because someone that relies on your class may not have access to the code of the other class!

Do you mean that if someone changes a class member, they would not change in all places that use that class member? Why not?

> someone that relies on your class may not have access to the code

As I wrote in the clarification, I'm only interested in cases where everyone has access to all the code.

Ouch, that's a pretty careless reason to start with. Why does insulting your audience seem like the right first move?

In much of the classist (classy? You decide) code I've written, the entire reason that I've chosen to encapsulate the data into a class is that maintaining a consistent data structure requires book-keeping. The fields and methods associated with this bookkeeping are not part of the public interface, because there should never be a reason for consumers to handle that stuff directly.

In short: even in a project that "everybody has access to," you should still implement clean APIs. If you let everybody put hooks into everything anywhere, you get horrible hacky spaghetti code.

Edit: and just FYI, "private" does not mean "secure" or "secret" or "untouchable." A dedicated user can gain access to, and modify, everything.

I think it's fine. This is probably the reason that I used to have for using private until I started thinking about it.

> there should never be a reason for consumers to handle that stuff directly

Are we assuming here that the organization is structured so that only one team works on a class, so that that's the team that knows how the bookkeeping is done and no other team should touch it?

No. If you're in such an organization, anybody on any team should be able to read the code and discover how the bookkeeping is done and locate bugs therein. A good API will obscure the necessity of bookkeeping from consumers in order to reduce bug-ridden boilerplate. Said in more highfalutin' language, privacy should be used to prevent leaky abstractions.

> I think it's fine. This is probably the reason that I used to have for using private until I started thinking about it.

I mean I understand if no-one would claim to have that reason currently because people like to have more specific reasons for what they do but it's still a valid reason for using private so I didn't want to leave it out.

That may be so, but it is akin to using an undocumented system call. And good luck if that class ever gets refactored or turned into a service.

Within reason, you should treat every class as a tiny library that defines an API for other people to use.

That allows you freedom to change things within the class without breaking other code. It also makes it easier to prevent accidental misuse of the class that can leave it in weird states that aren't supposed to happen. It allows you to reason about the intended use cases of the class and write tests for them all.

Let's say I have a Motorcycle class with 2 Wheel members. What if in the code I assume 2 Wheels when writing the serializer? And then someone comes along, instantiates a Motorcycle and nukes a Wheel? The code will break.

You can make an argument that OOP is not what you want, and instead create something akin to namespaces+data, and that's fine. But OOP's thing is to create a public API, and controlled state behind it.

it does not matter what you promise in the contract:

all observable behaviors of your system

will be depended on by somebody."

If your programming language supports reflection, people will depend on private properties and methods regardless of what you do.

I might want to have a method called SetPrice(APIPrice price) and there I do a check to see if it's a valid value as far as my code is concerned. I had a situation like this handling pricing information taken from a variety of indices but I want a calculation to still work out to something usable. Also, most business users don't understand what NULL * 3.5 would mean, but they would understand 0.0 * 3.5.

That's the main one off the top of my head.

- Steering wheel

- Transmission

- Brakes and Gas pedal

- Doors and Windows, etc.

The following is a private API for a Car:

- The inner workings of the engine

- The inner workings of the battery

- Smart break system, internal wiring, etc.

All users of the Car only care about how to drive it with as little knowledge as possible.

Now Mazda can do a full recall and upgrade the smart breaking systems internally but millions of drivers around the world don't have to "learn" anything new, they can happily continue using the public API.

It makes refactoring much easier, reduces dependency and enables duct typing (in supported languages) via message passing for objects with a common public API. You also don't have to perform shotgun surgery[0] when changing classes..

[0] https://refactoring.guru/smells/shotgun-surgery

If you can see the use in access modifiers for libraries then it's not so hard to make the leap to its general usefulness. Defining objects with clear and simple APIs is extremely valuable when working on complex software projects. As the code base inevitably grows to a point where no one knows every part of it, you want developers to be able to contribute without having intimate knowledge of everything. The value proposition is the same as for third-party libraries.

From the linked page I read: "Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods."

So there are two possible reasons here:

1. The access could "expose hidden implementation details". This is not really a reason because it's just saying that you hide something to prevent access in a way that can expose what you hid.

2. The access could "violate state invariance maintained by the methods". Let's say the class has two arrays, `vertices` and `edges`. The state invariance is that they need to have the same number of items (like you have in a polygon). Then why would you make them private? A possible reason could be that it's easy to forget to add an edge if you add a vertex. But why would that be easier to remember if you do it in a member function?

Re 2: Supposing that the two collections have to be the same size, this implies that they get extended at the same time. If they are public, then anyone can add either a vertex or an edge at will. But they are not required (by the interface, only by a verbal contract of sorts) to extend both at the same time. With private members, you present a public interface that ensures both collections are updated simultaneously (or "simultaneously", as a transaction both happen before the method/function/subroutine/procedure/whatever the fuck ends). This makes the class/module author responsible for controlling this invariant, and not the users. Which is the only sane option unless you really like broken contracts and duplicated code scattered throughout a code base.

2. First, remember that I am only interested in code that everyone has write access to so even if something is private, everyone can still change it. "This makes the class/module author responsible for controlling this invariant" - does that mean that private is mostly useful together with a rule that only one person (or a few) should change code that belongs to their class, so that that person can keep the invariants in their head and that way avoid breaking them?

2. Forget about people, it's about place. I don't care how many people alter a particular class or module. What I care about is how many places some information has to exist within the code and has to be maintained and synchronized as a result.

As a mostly-useless-after-CS101 example, consider a bounded stack. An implementation might have a number (perhaps variable) which describes its limit, an array backing it, and another number indicating where the current "top" of the stack is (in languages where arrays carry their size you don't necessarily need that limit number as a separate thing).

If you leave everything public then every user of this bounded stack could directly alter the backing array and change the "top" of the stack, artificially indicating that something had been popped off or incorrectly incrementing beyond the limit. The limit itself could be altered without actually changing the backing array. The backing array could be made smaller or larger without correspondingly changing the limit. All of that would make this data structure useless, because it would be in an arbitrary, likely invalid, state.

In order to preserve the invariants of the system (limit == array size, 0 <= top <= limit; as just two of them), you write routines internal to this module (class, whatever) that make sure that when one is changed the others are changed, or that changes are only valid (top can never be larger than limit or less than 0). If users are able to bypass these routines by directly accessing these three member fields of the data structure then to correctly use it they have to preserve all these invariants everywhere they use the data structure. The code is now scattered and contains many duplications. Again, this isn't about people, it's about places and the number of them.

If you want to change the internal structure of this bounded stack, you have to change every place that currently accesses the public fields. Or you can be a sane developer, use private fields and public routines that manipulate the state so that it's always in a valid state. Now when you change the internal structure you only have to change those public routines and the private fields, no other place has to be altered. Every use of this bounded stack will look exactly the same as before, just push and pop and some error handling for when the stack is full or empty.

So it's not to make it easier to change things? Otherwise what's the difference, in difficulty to change things, between using a member in 20 places outside of the class and 20 places inside the class? It's the same amount of code to change if you change the member.

> But no one outside the class/module can directly access it

Everyone can access all the code.

> those outside users will not be impacted

What do you mean that they will not be impacted? If I change the internal array and all the places where it's used, nobody might even notice it. Or is the assumption that one team can only change inside the class and other teams can only change outside of the class? Remember that we assume that everyone has access to the all the code.

2.

> it's about places and the number of them.

So again, is private a way to tell programmers to reduce the number of places they use the member in so that it will be easier to change it?

> Everyone can access all the code.

I don't care what everyone can access (in terms of altering on a filesystem and code repository). It's about what the code can access.

  public class BoundedStack<T> {
    ...
    private int limit; // initialized in constructor
    private T[] array;
    private int top = 0;
  }

  void some_method() {
    BoundedStack<Messages> stack = new BoundedStack<Messages>(100);
    ...
    stack.top = 200; // invalid
    ...
  }

Using private, here, is moving a convention (like _ in Python or just a verbal agreement or a note in the documentation) to a compiler checked thing. It makes it guaranteed that users cannot (modulo reflection facilities in some languages, but that's jumping through hoops, but that's their problem when it breaks, not mine) access these without going through your intended interfaces.

>> those outside users will not be impacted

> What do you mean that they will not be impacted? If I change the internal array and all the places where it's used, nobody might even notice it. Or is the assumption that one team can only change inside the class and other teams can only change outside of the class? Remember that we assume that everyone has access to the all the code.

What I mean is that in the above, you can change the manner in which BoundedStack (or whatever the module is) is implemented and the interface remains the same. Users still have access to peek, pop, push, and whatever other methods you provided. What they cannot do is assume (you know what assuming does, right?) that the underlying representation is stable and bypass your intended interfaces. BoundedStack could switch to using a LinkedList for all the user needs to care, but if they assume it's an array backing it and have access to that array they might write something like this (even assuming they do everything as safely as possible so that this is a valid piece of data they're accessing, but in an unintended way):

  void bad_user() {
    BoundedStack<int> stack = new BoundedStack<int>(100);
    ...
    int a_datum = stack.array[n]; // where `n`, to be generous, is a valid item at this point
    ...
  }

1. Did something unexpected with the code (why the fuck are they using a stack if they want to access anything but the top?).

2. Assumed the internal implementation details were stable.

It doesn't matter how many teams are involved, you can (and ought) to use private even for yourself or for one team. It makes the system far more maintainable and reliable to either have an actual language notion of private or a community consensus on what is private (like _ prefixed member variables in Python). It reduces coupling, which is one of the number one ways to cripple development as a system grows in size.

Yes that's what private does, it makes sure that you can't access something from any place in the code. The questions is why you should make this constraint.

> That's invalid code

Is private used to tell programmers that if you change this variable or call this function, the object can be in an invalid state?

> For some reason you left the name array in place

Is the reason here that private makes it easier to find all uses of something because it reduces the number of places you have to look in? Example, you change the meaning of a variable but forget to change the name so the compiler will not tell you about all the places to change. You can still change all the uses of that member in the class because those uses are easy to find and know about.

Making the list or the dictionary public opens you up to situations where consumers of the code modify either datastore independently and corrupt the consistency of the class.

Coming from Fred Brooks, this was an enormous admission! What is this amazing "information hiding?" It is separating interface from implementation, leaving one public and the other private. It is accomplished, among other means, by marking things "private."

This is the one thing in 20 years that Brooks found to be valuable in increasing programmer productivity in terms of essential complexity. Marking implementation details as private reduces the essential complexity of the code.

By the way, in some of your comments you talk about "everyone" having access to things, as if that makes a difference. Marking things as "private" is not about closing off access to particular people. It's not a security measure. It's about reducing the complexity of a given class by ensuring that the number of access points to that class are limited. That could affect other teams, sure, but it could also affect future-you, or you-working-on-other-class.

The only time I break this rule is for data-transport type classes. For example if I serialize some object into some class X before sending it to some API. Since all those objects do is hold data, I see no point in making the members private. Many people do, I suppose out of habit; or in anticipation that maybe one day those objects will do more than hold data. I'd like to hear a good argument for making members private in data-transport type classes.

A lot of people are ignoring this part of the question. The primary usefulness of object-oriented programming is scope control. Dependencies kill teams, and scope control helps them survive. The more I limit the scope of something, the easier for someone else to understand it and make necessary changes.

Imagine a language without scope control: When people try to understand how something works and what might break it, they have to consider all possible points of entry, which becomes every variable & function in your class.

Java programmers often pitch fits about "getters" and "setters", insisting that every variable be private and guarded by a public method. In your context, you might find this to be kind of silly since we're mostly just moving scope control around instead of limiting it, but good luck fighting that battle (I'm not going to try). At any rate, I still would not use this kind of annoyance as an excuse to wave off scope control as nothing but bureaucratic boilerplate. It has real value when used pragmatically.

Do you mean that when you have structured the organization so that each class is worked on by at most one team, you want to reduce the number of dependencies between classes in order to reduce the number of dependencies between teams?

> they have to consider all possible points of entry

So is this basically what I mentioned, that you want to reduce the number of places you have to look in when you want to find all uses of it?

By "dependencies kill teams" I mean all the forms of dependencies: Database dependencies, web service dependencies, library dependencies, across teams, across organizations, and so on.

Arguably internal dependencies inside a program are the least lethal. You are largely doing others the favor of implicit documentation by using scope control, a guaranteed statement of "This is never used outside this file". They might be able to figure as much out by grepping, remove & recompile, or IDE-based tools. "Greppability" is often part of the solution when dealing with database & http dependencies.

As for the second question, basically, yes.

The set of property values of an object is its state, and you can model every possible valid state and state transition. Not every state is valid. If you allow all variables to be touched willy-nilly, you allow an object to be put into an invalid state.

The only variables and functions that should be public are those that cannot put an object into an invalid state.

That's an interesting one. So a reason to use private is to tell programmers that calling this function or changing this variable can leave the object in an invalid state? I guess invalid state then means that you can't call a public function on that object.

It might not be clear what an invalid state is though. I mean, every state has its place. Example, after I decrease the health of the player to 0 but before the death animation is played, is that a valid state? I should not be able to play in that state but it's a state that the player might be in for a frame and it will be visible on the screen.

  a_bounded_stack = new BoundedStack(100);

  a_bounded_stack.limit = 50;

  a_bounded_stack
    limit = 50
    array.size = 100
    top = 60

Someone could come by with cookies while I'm writing a private function too. This is more of a reason for having a function for doing something. Is the reason to make those variables private then to tell the programmer that there is a function that changes them and that you have to look through all the functions of the class before you touch them to see if there is a function that does what you need?

But following the example: if you made the player's health a public property, code could straight up just set it to a negative number. The game engine this is running in may not properly support a negative health value. If instead it was set using a public method, there can be added checks to lower bound health to zero. And depending on the architecture, all of the post death animation stuff could also be handled as a check in that function call.

> Is the reason to make those variables private then to tell the programmer that there is a function that changes them and that you have to look through all the functions of the class before you touch them to see if there is a function that does what you need?

I'm not sure I understand the question.

A private property is a property that a class user should have no reason to want to directly write to. Or more accurately, it's a variable that directly writing to could invalidate the state of the object. They are intermediate values or implementation details that define the state of the object. Reading them should be fine, but allowing unrestricted writing is dangerous. If there is reason to directly change the value, there should be a public method that includes validation to prevent the user from invalidating the object.

On the other hand, private methods exist for code re-use convenience purposes. You could just as easily only have public methods and write all logic inside of them. But a lot of the time you have pieces of code that could be reused between methods, but on its own doesn't guarantee the object to be in a valid state at the beginning or end of the call. So, you make it private. It only exists as a means of avoiding code duplication and possibly improving readability.

Private methods may also have value in inheritance / abstract classes, but I'm focusing on invalid state.

What the user of a class has reason to do depends on what they need to get done. Maybe there is a function that already does what they need to do or maybe there isn't. So the choice is: call a function or write code that directly accesses the variable. This is a choice you would have both for private and public variables. But people say that they make things private because the class user should use already existing functions instead of touching the variable directly if there is already a function that does it. So does that mean that private is a way to tell the class user that there are functions that touch this variable, to increase the chances that the class user finds and uses them?

I would say private is a way to tell the user to not touch the variable, or to use an accessor function that has validation to prevent entering invalid state.

At this point I feel like I'm just repeating myself, as I can't imagine a concrete example of what you're asking. Could you give a hypothetical, or better yet real, example of what you're thinking of here? I can't think of any at all. I felt that the example by Jtsummers was a great illustration.

That's what I meant, that it's a way to tell the programmer that you may not need to touch this variable directly because there are already functions that do that so please look at those functions to see if there is one that does what you need. Private then makes sure that all functions that touch the variable are added to the list because you can't use a private variable in a function not in the list. The list I'm talking about is the function declarations/definitions in the class.

This C++ code doesn't compile because `number` is private by default:

    class A {
        int number;
    };
    void zero(A &a) {
        a.number = 0;
    }

    class A {
        int number;
        void zero();
    };
    void A::zero() {
        number = 0;
    }

Otherwise, what's the difference between my two examples that makes the second one better than the first one (other than that the first one doesn't compile)? The only difference is that the function has been added to a list inside the class and got a slightly different name.

> Otherwise, what's the difference between my two examples that makes the second one better than the first one (other than that the first one doesn't compile)? The only difference is that the function has been added to a list inside the class and got a slightly different name.

The second one is not better than the first one. I would say it's a completely pointless approach to a problem, and would be better served by just making number public. Leaving an empty zero function signature around so someone can come by and fill it in to do what they want serves absolutely no useful purpose at all here. If zeroing out the number property of class A is useful for A, then it should be an already implemented function.

That being said, the example given, in my eyes, is not useful. What is "number"? Why is it private? What does "A" do? What are it's expected states? What are it's failure conditions? If A cannot enter an invalid state by changing number, there is no reason for it to be private.

As I previously said, private exists to prevent objects from entering invalid states from external influence. If A#number has no invalid state, then it need not be private.

I clarified in the question that I'm only asking about situations where everyone has access to all of the code. So are we assuming that the organization is structured so that only one person/team works on a class and that no-one else is supposed to touch it? Or why would the class user not write a new function that accesses the member variables? Is it because the variables are private, which tells them to look at existing functions, just like I described?

> That being said, the example given, in my eyes, is not useful.

Ok, let's do a more useful example, a string class, where we assume that `len` may never be negative (and we assume that there are other string functions defined in the same way as `truncate` to make the class more useful; I just didn't want to write them in this example).

Code 1:

    class Str {
    public:
        char *data;
        int len;
    };
    
    void truncate(Str *s) {
        s->len = 0;
    }

    class Str {
        char *data;
        int len;
    public:
        void truncate();
    };
    
    void Str::truncate() {
        len = 0;
    }

Private is a way of excluding the member so designated from any consideration at all by a consumer of the class. Assuming that they see it at all (which if it is in a compiled library using normal tooling they might well not at all), they are effectively told to treat it as if it does not exist.

There may exist mechanism to bypass this (especially in dynamic languages and/or those with robust introspection/metaprogramming), but that's breaking the warranty seal on the class.

All the functionality that a class provides to consumers is provided by its public members. That's what public members are.

The practical reason is that this way you have limited paths (methods) with which the inner workings of a class can be modified with, whereas if anything would be public, any other obejct would be able to change a class' status rendering debugging incredibly more complicaed.

This is also a part of the Open-Closed principle: "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification" https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle

The more fundamental principle that predates OOP is: Abstraction

https://en.wikipedia.org/wiki/Abstraction_(computer_science)

Even within a single module of code, your public interfaces are "APIs". If I write a class that displays a paged interface in a popup modal, there is no relevant difference between a member of my team utilizing that class (from within the same module) and other people using it (as a library I have published). They both read the documenting comments and access the public members to achieve their goals, and both will suffer from the same confusion if there is no way to tell which members are the interface and which members are implementation details.

The difference between a team member and a library user is that the team member works in the same project while library users have their own projects. So if you change something inside the class, you can change all the uses of that class in your project but you can't change other people's projects. That's why I added the clarification, because there is a very obvious reason to be strict about the API of a library that other people use: you can't change those uses.

Anything I do inside that class that isn't marked public is an implementation detail, and might change. Given time, likely will change! But if it's not marked public, then if you want to access something in there, you'll need to think through the implications of making it public, either a new method of by adding to an existing method.

If I come along later and want to change things about those methods, I can do that freely, so long as I maintain the same input types and return types.

Internally I can change a counter from an Int to an Long, and it doesn't matter to anybody. Internally I can change the way I'm assembling a String, and that's fine. Internally I can move the definition for an interim variable to a separate function with its own tests, and that's fine. So long as I maintain the input types and return types, all is good.

If the fields and methods were public, on the other hand, then other classes might be accessing them directly, and now any change has to be negotiated with all callers. The counter needs to be changed from an Int to a Long? If it's public, you'll need to make sure that no other classes anywhere are referring to that counter and expecting it to be an Int.

Side effects are generally unwanted, and marking things as public is making everything in an implementation a side effect.

If the field is mutable then obviously you may want to keep it private to ensure some invariant, or to cache/invalidate/log something when accessed. Accessing the private data directly will circumvent that.

If the exposed data isn’t the same as the stored data (e.g a DateTime struct might have a field with a 32 bit Unix timestamp but only exposes year/month/day/hour…). The reason for not exposing it because you don’t want consumers to depend on it. If you changed to a 64 bit internal representation you will break any consumer who is using the private field. But if you only expose year/month/day/hour/… then you can solve your year-2038-problem by simply changing the data type. Anything exposed is depended on. Always. And here is the kicker: it doesn’t matter if your consumers are other classes in the same program, or library users for a shipped api, they are users and they will (mis)use your class in any way possible. In the library api case you break others’ code. In the internal code case you might get a missed cache, or a harder refactor or similar.

It's for the same reasons. When you write code you are always writing code that some other human will consume through an interface of sorts. Even on small three person projects two truths hold:

- Your project mates are other humans.

- Your future self is an other human.

By defining members as private you're announcing in code to other humans that the private members are important only to the internal implementation of the class and should not be used elsewhere. And yes, your future self with thank you for the distinction.

Now, you don't need to have private methods. In some languages, a work around is to label the methods as "private" by adding a prefix of some sort like an underscore.

Another more functional reason has to do with inheritance. Private methods have different behaviors in different languages when inherited.

For personal projects I do use public things where necessary, and for team programming I also use public functions, but not public variables (sonar doesn't allow it) unless you make them final, which I do.

The important part is "when necessary". Think that each class is like a small little library (it should be at least). There are things you want others to know and use, and other internal things you don't. Public for the first, private for the second.

You sound like a junior developer looking for guidance.

There will always be some amount of coupling, but reducing it makes it much easier to reason in your mind about small sections of code. With good encapsulation, there are clear interfaces between components and it is difficult to use them incorrectly.

You could argue that if there are only a few or even one developer on a project, there is no harm in making everything public since everyone will just use the class "correctly". However, the "correct" way to use the class is not codified or enforced anywhere other than the minds of the developers, comments, or external documentation. All of these sources can easily fall out of sync with the actual code being written. The compiler/runtime should be used to enforce correct usage when possible. This greatly reduces the cognitive load on the developer/s since they know if the code compiles or runs without error, a whole class of bugs has already been eliminated.

I would argue that even if access controls were completely ineffective (they didn’t actually control access), they would still be useful as API documentation within the source code to point others and your future self to the set of variables and functions that should be used to interact with the class. There is a benefit to writing code that is itself expressive of intent without requiring additional documentation or knowledge.

Another reason to reduce coupling is to make it easier to re-implement a single component of the system. If the component was well encapsulated and has a clean and minimal public interface, the only restriction on the new implementation is to meet that same public interface. If the component was not well encapsulated, the new implementation may have to maintain a number of details from the previous implementation than no longer make sense just to maintain all of the unnecessary coupling that’s been created between the component and the code that uses it.

This applies to classes without external users, too, the same divisions between class responsibilities and implementation remains valod

A low surface area API means clean, elegant code that is simpler to use and understand.

>To clarify, I'm only talking about code in the same project that everyone has access to. I'm not talking about defining an API for other people to use that don't have access to the code, like when you make a library.

The concept of API still applies to same codebase modules. Ditching it is the shortest path to spaghetti code.

I do that so that "future me" has as little to understand as possible. ("reduce the number of files to search" seems silly in a world with filename wildcards and find. Are "modern" tools less capable?)

Changing private things and nobody might ever know.

It's about the need to coordinate and communicate changes and avoid people relying on unspecified behavior.

It says "don't call me". That might be because it might be refactored without notice, or might break the intended use of the Class.

Even in languages without formal class access control, there is convention for labelling something as externally unsafe. It's an important part of sharing code.

I don't care and I shouldn't care about the dependencies or statefulness. I'm interested in the before-and-after of using the class methods.

It lowers cognitive load because it provides demarcation of inside vs outside.

Outside of library usage though? Mostly counterproductive in my experience.

I used to believe in information hiding, but not anymore.

Then, you will probably divide up the code into a number of separate methods for better structured code. All the methods that are purely internal and not part of the public API should be private if only to enforce the public API, this is also the encapsulation principle.

I know what _underscoring does in Python and what PEP8 recommends but doing it all the time for everything is so ugly and unnecessary.

Making variables and methods private means making them inaccessible outside the class and I gave the typical reasons/best practices for that.

The point they are making is in python there's no private method, everything is public. There's only a convention of "avoid using anything starting with "_"

Should the implementation of a module not be able to utilize functions internally?

You really think that in the 50+ years of OOP and modular programming no one has considered why? That they've really just thrown shit at the wall and seen what stuck and never considered what to throw at the wall or why it stuck?

We do it because it’s largely automated by IDEs now. I strongly suspect that if IDEs didn’t make it so easy to do, we basically wouldn’t bother with it. Python does OOP just fine without real visibility control.