3 ms·
Everything public versions poorly when you can't update all clients of your code after you change your implementation. It increases coupling in ways you can't c
by barrkel 7y ago
Everything public versions poorly when you can't update all clients of your code after you change your implementation. It increases coupling in ways you can't control.
It also doesn't work very well with code completion - implementation methods get mixed up with surface API - and usability by third parties suffers.
If you're on a team of one, and you own the project for its whole lifetime, then you're fine.
- adrianN 7y agoThe implicit contract is that anybody who uses m_ "intended to be private" members is responsible for fixing breakage.
- pdpi 7y agoI’d rather have no breakages over a breakage that’s somebody else’s fault
- QuadrupleA 7y agoAdmittedly my use case is generally projects that are under my control. But in the case of say an open source library, how likely are clients going to update their code with each new release of the library? Typical case is to do it from time to time, especially with compiled code / shared libs, and expect a few incompatibilities to sort out and fix when you do. In a fast evolving large team project, seems it depends on how well the boundaries of the subsystems are worked out. Misusing supposed-to-be-private members is one minor possibility amidst many challenges.