3 ms·
> 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 thin
by robalni 4y ago
> 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?
- klyrs 4y ago> 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.
- robalni 4y ago> > 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.