¿Mejores prácticas para usar público, protegido, privado?

¿Es justo decir que es una buena práctica predeterminar todo privatepor adelantado al codificar algo?

¿Y luego solo actualizarlo protectedsi una subclase lo necesita, o publicsi otra clase lo necesita?

Respuesta corta: sí

Respuesta más larga:

Sí, pero eso no debe interpretarse como una sugerencia para comenzar escribiendo sus clases con todo privado; ese enfoque implica el diseño de la clase al enfocarse en los detalles de implementación antes de que se haya decidido por una interfaz.

Uno de los aspectos más importantes a tener en cuenta al diseñar una clase es cómo se utilizará; lo que implica pensar en sus métodos públicos antes de comenzar a pensar en detalles privados / de implementación.

Además, ese enfoque generalmente pierde oportunidades de preguntarse "¿Cómo escribiría una prueba de unidad para esta clase?" - que es una pregunta importante que hacer, incluso si en realidad no estás escribiendo pruebas unitarias. (Relacionado: "¿Cuáles son los principios de diseño que promueven el código comprobable?" )

Por lo tanto, una vez que haya definido la interfaz pública, es una buena idea poner el resto en privado de forma predeterminada, ya que la mayoría de las veces será un detalle arenoso de la implementación que no es de interés para nada fuera de la clase.

"¿Y luego solo actualizarlo a protegido si una subclase lo necesita, o público si otra clase lo necesita?"

Ese es el enfoque equivocado. En el momento del diseño, debe saber qué acceso público desea dar. Usualmente le das acceso público porque ese es el propósito de tu clase. Y otorga acceso protegido porque desea que las subclases accedan a las cosas. Y usas privado para cosas que no son asunto de nadie más.

Ahora, si alguien necesita acceder a cosas a las que no puede acceder, entonces debe pensar mucho en esa necesidad . No deberían necesitar ese acceso, o su diseño es incorrecto. Tal vez su diseño sea incorrecto, y algo no sea público que debería ser público, así que cambie eso. Pero si su diseño es correcto, entonces hay algo mal con la necesidad , por lo que fijar que en lugar de dañar su diseño.

La clave para comprender este aspecto de la programación orientada a objetos es el concepto de encapsulación de datos . La idea es hacer que una clase sea más fácil de entender al ocultar los detalles de su implementación. Esto se llama ocultación de datos . Por lo tanto, solo queremos exponer (hacer público) aquellas funciones que son necesarias para usar la clase. Estas funciones son la interfaz de la clase.

Piense en una interfaz como la rueda de un automóvil. Usted decide en qué dirección va el automóvil girando la rueda, pero debajo de las cubiertas hay válvulas giratorias, sistemas hidráulicos, poleas que cambian la rotación de sus ruedas, pero no necesita ser un ingeniero mecánico para conducir un automóvil.

Así que la respuesta a tu pregunta es sí. Desea ocultar tantos detalles sobre una clase como sea posible de otras clases. Comprender cuándo algo debe ser público, privado o protegido es fácil de aprender pero difícil de dominar.