one man in his half a page which I actually acquired in the process of writing a book 15 years ago typ written a typewritten half a page he said what we must do we must treble our deficit treble our deficit we have a deficit which is bad we must make it three times as big and make the capitalists of the rest of the world pay for it which is exactly what happened the United States should increase its deficit and use it to create aggregate demand for the net exports of Germany and Japan and later on China

Conversely, I've never in 16+ years of professional development regretted marking a method protected instead of private for reasons related to API safety

I just wanted to tweak Java's BufferedReader to handle custom line delimiters. Thanks to private fields I have to clone the entire class rather than simply extending it and overriding readLine().

I'm not saying never mark methods private. I'm saying the better rule of thumb is to "make methods protected unless there's a good reason not to".

Marking methods protected by default is a mitigation for one of the major issues in modern SW development: failure of imagination.

Been disappointed, surprised or hurt by a library etc. that was overly permissive in it's extensibility? I have not.

The old wisdom "mark it private unless you have a good reason not to" made sense in days when it was written, before open source dominated the developer library space and VCS/dependency mgmt. became hyper collaborative thanks to Github, Maven, etc. Back then there was also money to be made by constraining the way(s) in which a library could be utilized. I spent probably the first 8 or 9 years of my career strictly adhering to this "best practice". Today, I believe it to be bad advice. Sometimes there's a reasonable argument to mark a method private, or a class final but it's exceedingly rare, and even then it's probably not improving anything.

Are protected members/fields really that bad? No. They are way, way worse. As soon as a member is more accessible than private, you are making guarantees to other classes about how that member will behave. Since a field is totally uncontrolled, putting it "out in the wild" opens your class and classes that inherit from or interact with your class to higher bug risk. There is no way to know when a field changes, no way to control who or what changes it. If now, or at some point in the future, any of your code ever depends on a field some certain value, you now have to add validity checks and fallback logic in case it's not the expected value - every place you use it. That's a huge amount of wasted effort when you could've just made it a damn property instead ;) The best way to share information with deriving classes is the read-only property: protected object MyProperty { get; } If you absolutely have to make it read/write, don't. If you really, really have to make it read-write, rethink your design. If you still need it to be read-write, apologize to your colleagues and don't do it again :) A lot of developers believe - and will tell you - that this is overly strict. And it's true that you can get by just fine without being this strict. But taking this approach will help you go from just getting by to remarkably robust software. You'll spend far less time fixing bugs.

As soon as you make a member not-private, you are stuck with it, forever and ever. It's your public interface now.

Derived classes need to follow their base class contracts, but may choose to expose a subtype of base class with more capabilities. This includes making protected members public:

Member Visibility

Member States

ducators being conscious of power dynamicsin the classroom, as well as the importance of seeing oneself as group mem-ber and a group leader, just as a bass player contributes to the foundationof the music and plays a role as a one of the musicians

member (n.)