Como han dicho otros, las variables privadas son buenas para evitar los usos erróneos que llevan al objeto a un estado incoherente y es difícil rastrear errores y excepciones imprevistas.
Pero, por otro lado, lo que más han ignorado los demás es sobre los campos protegidos.
Una subclase extendida tendrá acceso completo a los campos protegidos, haciendo que el objeto sea tan frágil como si esos campos fueran públicos, pero esa fragilidad se limita a la propia clase que se extiende (a menos que exponga dichos campos aún más).
Por lo tanto, los campos públicos son difíciles de considerar buenos, y hasta la fecha, la única razón para usarlos es para las clases utilizadas como parámetro de configuración (una clase muy simple con muchos campos y sin lógica, por lo que la clase se pasa como un parámetro solo a algún método).
Pero, por otro lado, los campos privados reducen la flexibilidad de su código para otros usuarios.
Flexibilidad frente a problemas, ventajas y desventajas:
Los objetos instanciados por su código en la clase de vainilla con campos protegidos son seguros y son de su exclusiva responsabilidad.
Por otra parte, los objetos que extienden su clase con campos protegidos, creados por los usuarios de su código, son de su responsabilidad, no de usted.
Por lo tanto, los campos / métodos protegidos no están bien documentados, o si los usuarios no entienden realmente cómo se deben usar dichos campos y métodos, tienen una buena posibilidad de causar problemas innecesarios para ellos mismos y para usted.
Por otro lado, hacer que la mayoría de las cosas sean privadas disminuirá la flexibilidad de los usuarios, e incluso puede dejarlos de lado en busca de alternativas mantenidas, ya que tal vez no quieran crear y mantener una bifurcación para que las cosas sucedan a su manera. p>
Entonces, lo que realmente importa es un buen equilibrio entre privado, protegido y público.
Ahora, decidir entre lo privado y lo protegido es el problema real.
¿Cuándo usar protegido?
Cada vez que entienda que un campo puede ser muy flexible, debe codificarse como protegido.
Esa flexibilidad es: desde que se convierte en nulo (donde nulo siempre se marca y reconoce como un estado válido que no produce excepciones), hasta que tiene restricciones antes de que sea utilizado por su clase ex. > = 0, < 100, etc., y se corrigen automáticamente para los valores de flujo excesivo / insuficiente, lanzando como máximo un mensaje de advertencia.
Entonces, para un campo tan protegido, puede crear un captador y solo usarlo (en lugar de usar directamente la variable de campo), mientras que otros usuarios no lo pueden usar, en caso de que quieran más flexibilidad para su código específico, en mi ejemplo podría ser como: si quieren que los valores negativos funcionen bien en su clase extendida.