Después de leer algunas respuestas, mi primer punto sería que, en este contexto, no creo que debería es lo mismo que decir debe que no es lo mismo que decir Tengo que , creo que quizás estás enfatizando siempre .
-
debería implica que este es un consenso generalizado de que este es un enfoque mejor o más apropiado
- usted debería siempre declarar a sus miembros como privados
-
must implica que esta es la forma en que se realiza
- usted debe declarar en privado a sus miembros
-
tener que implica ninguna otra opción
- usted tiene que declarar en privado a sus miembros
De hecho, en los tres ejemplos (particularmente dada la circunstancia de la cual derivó esta pregunta) uno lo haría y IMO debería (aunque no debe ni debe) consultar ninguna declaración que se les presente, así es como programa la mejor computadora de todas. Por ejemplo, si alguien dijera que siempre debe hacer algo a pesar de que sabe que esta vez sería perjudicial, ¿lo haría sin cuestionar su racional?
Me imagino que en este caso su tutor (probablemente por su facilidad) lo ha considerado, una mejor práctica con la que, de hecho, yo (y quizás muchos otros) estarían de acuerdo. La pregunta que siento nunca debería ser por qué hacer que un miembro sea privado, sino en realidad lo contrario a cómo hacerlo público, tomando como ejemplo a Facebook, a las personas claramente les gusta publicar información sobre ellos mismos, pero incluso entonces, tal vez solo mis amigos puedan ver esto. , mi familia puede ver eso, y usted, que no conozco, no puede ver nada.
Devolviendo esto a OOP y en particular a Java, una de las razones principales para los que obtienen y configuran es IMO (y puede que esté equivocado) un caso de buena práctica semántica, obj.getState()
y obj.setState()
en lugar de obj.state
y obj.state = 'foo'
, en ambos casos, sostendría que el proceso de hacerlo es imperativo. Me gustaría pensar que la orientación a objetos no solo consiste en romper con este paradigma, sino en encapsular datos y funciones en un componente reutilizable. Si no ocultamos nada, ¿acabamos con un espacio de nombres para almacenar datos y métodos?
Otro punto clave que creo que se reduce a anular, las clases que heredan de una súper clase que contiene variables públicas ahora están atascadas con una variable pública que a mi me parece que esto podría llevar a una disminución en la reutilización. Al utilizar captadores y definidores, ha proporcionado una forma para que las subclases anulen el acceso a sus variables, tal vez agregue un poco de validación con la que nunca se haya molestado.
En cuanto a ser tedioso en cuanto a los creadores y creadores de la escritura, esto es realmente nulo y sin valor ya que creo que la mayoría de los IDE harán mucho por ti (y como acabo de encontrar lombok, que se ve bastante bien y me recuerda a @property
etc en objetivo-c)
En resumen, sí, debería utilizar siempre miembros privados a menos que tenga una buena razón para no hacerlo (los DTO serían, en cierta medida, una excepción razonable)