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

12

¿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?

— AJJ
fuente

2

Si está creando alguna API, debe anticipar la funcionalidad que la persona que llama puede necesitar. Por lo tanto, tendrá que pensar más en sus modificadores de acceso. Depende de quién esté usando el código que está escribiendo.

— user2023861

Posible duplicado de ¿TODAS sus variables deben declararse privadas?

— mosquito

10

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.

— Ben Cottrell
fuente

Entonces, si tratara de resumir lo que me está diciendo (para ver si entiendo), es una buena idea pensar primero en la interfaz pública (es decir, ¿cómo está siendo utilizada esta clase por el afuera para comenzar?) y luego hacer que todo lo demás sea privado?

— AJJ

1

@ArukaJ Un buen enfoque es escribir código que usará sus clases antes de construir la implementación. Esto puede ser un problema de huevo o gallina hasta que comience a escribir pruebas unitarias primero.

— JimmyJames

1

@ArukaJ A grandes rasgos sí; lo que al principio puede parecer más difícil de hacer, aunque, como JimmyJames menciona, se siente mucho más intuitivo cuando escribes pruebas unitarias. Puede implicar una mentalidad ligeramente diferente, pero el objetivo es pensar más cuidadosamente sobre lo que representa su clase y cómo se ven sus entradas / salidas; en general, esa es una forma mucho más "OO" de pensar sobre el diseño; es más probable que resulte en clases perfectamente encapsuladas con alta cohesión.

— Ben Cottrell

Soy receloso de usar pruebas unitarias para diseñar su clase, porque las pruebas unitarias no son las que realmente lo usarán. Sin embargo, definitivamente son mejores que nada para pensar cómo se usará la clase.

— user949300

8

"¿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.

— gnasher729
fuente

Digamos que usted tiene una clase que no tiene intención de subclase en este momento (y puede ser que nunca se necesita) y un método que si fueras a una subclase de la clase, sería útil / necesario para / por la subclase. ¿Harías ese método privateo protected?

— lfk

Debe ser la respuesta aceptada, hacer que todo sea privado al principio suena como si no quisiera pensar / diseñar.

— Niing

1

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.

— Chris Ghyzel
fuente