> Ouch, that's a pretty careless reason to start with

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?

> 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.

> > Ouch, that's a pretty careless reason to start with

> 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.

> A dedicated user can gain access to, and modify, everything.

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.

Indeed. My point was that "private" has all the strength of a "warranty void if removed" sticker.

That's a funny way of putting it, but yes, you are correct.