Skip to main content
Expanded on why you don't want to know
Source Link
jmoreno
  • 11.2k
  • 1
  • 33
  • 50

It has nothing to do with trust or fear of attacks, it is solely about Encapsulation -- not forcing unnecessary information on the user of the class.

Consider private constants -- they should not contain secret values (those should be stored elsewhere), they can't be changed, they can'tdon't need to be passed into your class (otherwise they would have to be public). The only possible use for them is as constants in OTHER classes. But if you do that, those classes now depend upon your class, to do work that is unrelated to your class. If you change the constant, other classes might break. That's bad from both sides -- as the writer of your class, you want the freedom to change as much as possible, and don't want to worry about things outside your control. A consumer of your class wants to be able to depend upon the exposed details of your class, without worrying about you changing it and breaking their code.

A consumer of your class wants to know everything needed to INTERACT with your class, and does not want to know anything about your class that doesn't change how they do so: it is useless trivia. If you have used a langauge with reflection, how often have you used it to learn not how some class does something or where it is throwing an exception unexpectedly, but simply the name of the private fields and methods? I'm betting never. Because you have no use for that knowledge.

It has nothing to do with trust or fear of attacks, it is solely about Encapsulation -- not forcing unnecessary information on the user of the class.

Consider private constants -- they should not contain secret values (those should be stored elsewhere), they can't be changed, they can't be passed into your class. The only use for them is as constants in OTHER classes. But if you do that, those classes now depend upon your class, to do work that is unrelated to your class. If you change the constant, other classes might break. That's bad from both sides -- as the writer of your class, you want the freedom to change as much as possible, and don't want to worry about things outside your control. A consumer of your class wants to be able to depend upon the exposed details of your class, without worrying about you changing it and breaking their code.

It has nothing to do with trust or fear of attacks, it is solely about Encapsulation -- not forcing unnecessary information on the user of the class.

Consider private constants -- they should not contain secret values (those should be stored elsewhere), they can't be changed, they don't need to be passed into your class (otherwise they would have to be public). The only possible use for them is as constants in OTHER classes. But if you do that, those classes now depend upon your class, to do work that is unrelated to your class. If you change the constant, other classes might break. That's bad from both sides -- as the writer of your class, you want the freedom to change as much as possible, and don't want to worry about things outside your control. A consumer of your class wants to be able to depend upon the exposed details of your class, without worrying about you changing it and breaking their code.

A consumer of your class wants to know everything needed to INTERACT with your class, and does not want to know anything about your class that doesn't change how they do so: it is useless trivia. If you have used a langauge with reflection, how often have you used it to learn not how some class does something or where it is throwing an exception unexpectedly, but simply the name of the private fields and methods? I'm betting never. Because you have no use for that knowledge.

Source Link
jmoreno
  • 11.2k
  • 1
  • 33
  • 50

It has nothing to do with trust or fear of attacks, it is solely about Encapsulation -- not forcing unnecessary information on the user of the class.

Consider private constants -- they should not contain secret values (those should be stored elsewhere), they can't be changed, they can't be passed into your class. The only use for them is as constants in OTHER classes. But if you do that, those classes now depend upon your class, to do work that is unrelated to your class. If you change the constant, other classes might break. That's bad from both sides -- as the writer of your class, you want the freedom to change as much as possible, and don't want to worry about things outside your control. A consumer of your class wants to be able to depend upon the exposed details of your class, without worrying about you changing it and breaking their code.