3 ms·

The Python language has been able to build many successful large-scale projects without language-enforced private fields or functions. (There is a convention t

• meaty 14y ago
  Works - yes. Works forever - probably not by which time you're in a world of pain. Your accessors are part of the class's immutable contract with the outside world. When you couple the class internals to the contract, hacks will ensue en masse and your little party will fall flat on its face. It's fine for trivial stuff, but if you work with others, this will cause uber amounts of pain.
  • csense 14y ago
    > if you work with others, this will cause uber amounts of pain. If this is true, why is it that there are plenty of large and successful frameworks and libraries written in Python? > hacks will ensue en masse Having downstream projects that use it is a sign of health for a library. If they're using the library in ways its creator never envisioned, so much the better for everyone. That's innovation. More than once, I've had to make a choice between partially re-implementing part of a popular Java library's functionality, or shipping my own fork with all the maintenance burden that entails, because in the official version a field I want to access is private, or a class I want to subclass is final.
  • Jare 14y ago
    No, hacks do not necessarily follow lack of privacy. Over time, I have found that people tend to hack when: 1 - They can't do something 'the right way' because the contract won't let them. 2 - They don't know how to do something 'the right way' because the contract is insufficiently documented (or worse, outdated). 3 - They prefer 'the first way' to 'the right way' (in a rush, not give a damn, etc). To avoid 1) you need to have created an absolutely rock solid design that covers all use cases. To avoid 2), your documentation must be excellent. To avoid 3), there must be 'only one way'. Unless you comply with all of the above, and can also prevent the ability to copy& paste / duplicate your code, you perfectly hidden internals will not save your project from someone who wants to write dirty code. In fact, hidden internals only really help with 3) there. But, hey, they may not prevent all of it, but at least they will help reduce it, right? Maybe not. In practice, hen programmers don't have the mental safety net of hidden internals, my perception is that they tend to produce simpler designs, with lower amount of state and lower amount of dependencies among pieces of that state. Which in turn tend to improve the situation against 1,2 and 3 above.
• csense 14y ago
  Also, non-public fields make unit testing a pain. I like to put my unit tests in separate classes, in a separate source root directory (for the convenience of my build script), and ship them in a separate jar. But if I want to test private methods or have the tests check the values of private variables, it simply can't be done without violating the separation of test and non-test code by putting test code in the class being tested.
  • bunderbunder 14y ago
    At least in my language of choice (C#), the general wisdom is that feeling a need to unit test against an object's internal state is a code smell. It suggests that your class is violating the single responsibility principle and needs to be separated into multiple smaller ones. Writing tests against implementation details makes the code less maintainable, since it means that you won't be able to change those implementation details without rewriting (or worse yet, just commenting out) unit tests.