Hacker News new | comments | show | ask | jobs | submit login
Why does Clean Code suggest avoiding protected variables? (stackexchange.com)
19 points by iProject 1608 days ago | hide | past | web | 10 comments | favorite



The Python language has been able to build many successful large-scale projects without language-enforced private fields or functions. (There is a convention to prefix internal functions and variables with "_" to indicate "This isn't intended to be part of our public API, it's probably totally undocumented so you'd better read the code before you start messing with it, and it may change or go away in future releases." And double-underscores, but I don't like them and don't use them.)

Ever since I started using Python, in Java I've started just making all my member variables public and forgetting about accessor methods.

It actually works.


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.


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.


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.


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


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.


For some human activities there are problems simply too complicated to be handled by science, mostly because it is very hard to build a rigorous and viable methodology to investigate the problem. If these areas are important and profitable you end up with an industry of pundits giving opinions "supported" by rhetoric rather than an evidence impossible to gather. Politics is the most obvious example, with its nauseating abundance of Glen Becks, Rush Limbaughs and Michael Moores. Stock market "analysts", self help gurus, psychic card readers, soothsayers are the more common varieties.

"Uncle Bob" (Clean Code's author) is the equivalent to those in the Software Engineering field, a snake oil seller that will give you the placebo that promises to fix problems that sometimes don't even exist or are of small relevance.



Having been bitten a couple of times by private/protected shadowing issues in Java and C++, I default to protected unless I know for certain I want something totally private.


Protected is fine if you understand it and use it where appropriate. My only real use for it is to allow NHibernate proxies to read backing fields for our entities.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: