Depeche Mode, Demeter, and @Deprecated

If you're like me your parents tried to teach you not to lie.  As you grew into an adult you started to notice that most adults do lie.  In fact you could go as far as to say that most utterances contain only partial truths.  To quote Gracian, "The truth is generally seen, rarely heard."  So when your parents told you not to lie were they just indirectly asking you to hush up?!

While your parents offered idealistic, age appropriate advice, Gracian offers the practical.  Like the lyrics to the Depeche Mode song Policy of Truth, "You'll see your problems multiply...(when you follow) the policy of truth.  So "...hide what you have to hide and tell what you have to tell."

We are living in what Alvin Toffler calls, The Third Wave or Information Age.  As he describes in Powershift, mankind has progressed from using violence, to wealth, and finally knowledge to attain power.  In this era of Fake News, I find myself frequently hesitating over what I read.  "Is it sincere or simply an attempt to make me an instrument of another man's will?"  Maybe a little of both.

"A leader is a man who has the ability to get other people to do what they don't want to do and like it:"

-- Harry S. Truman

Thus stands modern man.  Each of us a Little Caesar.  With our Facebook, Instagram, and concerns over privacy none of us is free from public life.  Thankfully, we have Depeche Mode & Gracian to offer a little practical guidance.  Well, as if this weren't stressful enough, I'm here to advocate it in your code as well.

The Law of Demeter essentially spells out a Policy of Truth for software.  Objects get access to information on a "need to know basis" only.  Despite this being a well known "law," there's apparently still quite a bit of uncertainty surrounding how to apply it.  

I'm writing to address some common, yet risky practices that I've observed in an attempt to at least express an opinion on how best to approach them.

If something can be hidden now but you think you may need it later leave it hidden.

This is a rationale I've seen a lot.  "We're probably going to be doing X in the future and X will need this property, so let's just create a method for it."  I say if there's any uncertainty, err on the side of caution.  Let the developer who needs X add it.  

Code is not only what it does.  Good code should be self explanatory and exemplary.  Even if the assertion regarding X is 100% correct, X may not come to fruition for some time.  If you open up the property in question, anyone not privy to this conversation is apt to misinterpret the intent of the code.  What's worse, they may use it as a guide and replicate or mimic it, propagating your loose policy.

If you're unsure, take the conservative approach.  Loose lips sink ships.

Default to private, even for classes.

To be safe, I think it might be nice if the default access level for Java and like languages were "private."  You should start there and open things up in increments only when necessary.  This means don't blindly create a bunch of accessors (or mutators) when first writing a class.  Postpone their creation until they're required.  Even for classes it's good to ask yourself, "Could this be private?"  In other words, "Can I make this an inner class?"

Don't open up access pell-mell, just for testing.

There's the adage, "Fools rush in where angels fear to tread."  Writing tests can be a drag.  It usually takes longer than coding up the functionality it's testing.  I know I get impatient and just wanna get the damn thing done.  Opening up access in this situation is certainly tempting, but resist.

• Do not change access levels (private -> public) for a test
• Do your best not to create accessors and mutators just for tests
• If you can't find another way around it, mark your methods as deprecated to halt the propagation of their use