Hmm… the definitions I know of are a bit different or rather I understand them differently. The definition of encapsulation I know of is about the hiding of data or methods in order to simplify a client’s usage of the objects or modules in question.
http://www.adobe.com/devnet/actionscript/learning/oop-concepts/encapsulation.html
http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html
The last one offers the closest reasoning to yours, but notice in his example.between the position class and the route class. Why didn’t Mr. Rogers just add the position methods into the route class? That would follow your understanding of encapsulation. Why he doesn’t do it? It is in his “2nd rule of encapsulation”, which is.
Encapsulation rule 2: Use responsibility-driven design to determine the grouping of data and operations into classes
which is the rule you ignore to make your 9000 line monster class viable in your mind. It is wrong. It is bad coding. It is hard to understand (which readability is all about). It basically kills all your arguments about DI.
No, you take issue with those who say it is ok to use it everywhere. The appropriate is a given (and why I agreed with you.) You are adding the “inappropriate and superfluous” to the equation and then you pull it into your world of programming to say, most of the time it is inappropriate and superfluous and that is YOUR issue. As Tom is trying to get you to explain to us, what is your definition of “appropriate”? If it is based on your own code, it thus shows basically NOTHING about what appropriate means. Your now and then usage of DI is NOT appropriate, because the basis your code is built on is NOT appropriate. You have absolutely no grounds to judge what appropriate is, because you don’t know what appropriate means. You DO NOT follow the second rule of encapsulation.
Encapsulation rule 2: Use responsibility-driven design to determine the grouping of data and operations into classes
Scott