3 ms·

I never really got the whole public/private thing. If you want to only expose certain functionalities, that's what the interface does. Making things private jus

I never really got the whole public/private thing. If you want to only expose certain functionalities, that's what the interface does. Making things private just hides things that are potentially nice hooks for testing or whatever.

khedoros1 10y ago
The assumption is that your public members are your interface. Anything private is an internal implementation detail, possibly subject to future change or replacement. Thorough testing of the public methods should end up calling all of the private methods. Of course, that's a best case scenario. In C++ at least, it'd be an option to make a testing class that's a friend of the class it tests. Then you could test the private members individually.
- justicezyx 10y ago
  I think almost all modern languages end up with granting (unit) testing code free access to everything. The idea of testing only the public interface is about an unique snow flake only meaningful in C++ design, and was never a viable practice at all. Otherwise, I'd say at least one other language follow the similar approach...
  - khedoros1 10y ago
    Are you just complaining about a lack of introspection to get around access controls? Friend classes are better for encapsulation than introspection is.
zvrba 10y ago
> I never really got the whole public/private thing. It's about encapsulation and class invariants. Public methods must preserve them, private methods can break them temporarily. You get a prepackaged component and you're prevented from introducing bugs into the component from the outside of the component. Take std::vector, for example. By keeping implementation details (pointer to element storage and element count) private, you prevent users of the class to accidentally shoot themselves in the foot by, say, changing the element count directly. You could use interfaces, but for that you have to use virtual functions: Objects have to be created dynamically and you have to handle pointers or references instead of values.
- novembermike 10y ago
  I understand what it's used for, i just feel like there's a more elegant way to do it.

khedoros1 10y ago

The assumption is that your public members are your interface. Anything private is an internal implementation detail, possibly subject to future change or replacement. Thorough testing of the public methods should end up calling all of the private methods. Of course, that's a best case scenario. In C++ at least, it'd be an option to make a testing class that's a friend of the class it tests. Then you could test the private members individually.

justicezyx 10y ago
I think almost all modern languages end up with granting (unit) testing code free access to everything. The idea of testing only the public interface is about an unique snow flake only meaningful in C++ design, and was never a viable practice at all. Otherwise, I'd say at least one other language follow the similar approach...
- khedoros1 10y ago
  Are you just complaining about a lack of introspection to get around access controls? Friend classes are better for encapsulation than introspection is.

zvrba 10y ago

> I never really got the whole public/private thing. It's about encapsulation and class invariants. Public methods must preserve them, private methods can break them temporarily. You get a prepackaged component and you're prevented from introducing bugs into the component from the outside of the component. Take std::vector, for example. By keeping implementation details (pointer to element storage and element count) private, you prevent users of the class to accidentally shoot themselves in the foot by, say, changing the element count directly. You could use interfaces, but for that you have to use virtual functions: Objects have to be created dynamically and you have to handle pointers or references instead of values.

novembermike 10y ago
I understand what it's used for, i just feel like there's a more elegant way to do it.