¿Por qué los campos privados no están lo suficientemente protegidos?

Porque como dices, protected aún te deja con la capacidad de "modificar la implementación completamente". No protege realmente nada dentro de la clase.

¿Por qué nos importa "proteger genuinamente" las cosas dentro de la clase? Porque de lo contrario, sería imposible cambiar los detalles de la implementación sin romper el código del cliente . Dicho de otra manera, las personas que escriben subclases también son "el mundo exterior" para la persona que escribió la clase base original.

En la práctica, los miembros protected son esencialmente una "API pública para subclases" de una clase y deben permanecer estables y compatibles con versiones anteriores tanto como lo hacen los miembros public . Si no tuviéramos la capacidad de crear un verdadero private miembros, entonces nada en una implementación sería seguro de cambiar, porque no podría descartar la posibilidad de que (no) malicioso) el código del cliente de alguna manera ha logrado depender de él.

Por cierto, mientras que "En POO, tarde o temprano, vas a hacer una subclase de una clase" es técnicamente cierto, tu argumento parece estar asumiendo que es mucho más fuerte que "tarde o temprano, vas a hacer una subclase de cada clase "que seguramente no sea el caso.

  

En POO, tarde o temprano, harás una subclase de una clase

Esto está mal. No todas las clases deben clasificarse como subclases y algunos lenguajes OOP tipificados estáticamente tienen funciones para evitarlo, por ejemplo, final (Java y C ++) o sealed (C #).

  

es bueno entender y poder modificar la implementación completamente.

No, no lo es. Es bueno para una clase poder definir claramente su interfaz pública y preservar sus invariantes incluso si se hereda de.

En general, el control de acceso se trata de la compartimentación. Desea que se entienda una parte individual del código sin tener que entender en detalle cómo interactúa con el resto del código. El acceso privado lo permite. Si al menos todo está protegido, debe comprender lo que hace cada subclase para comprender cómo funciona la clase base.

O para ponerlo en los términos de Scott Meyers: las partes privadas de una clase se ven afectadas por una cantidad finita de código: el código de la clase en sí.

Las partes públicas pueden verse afectadas por cada bit de código existente, y cada bit de código que aún no se ha escrito, lo que es una cantidad infinita de código.

Las partes protegidas pueden verse afectadas por cada subclase existente, y cada subclase aún por escribir, lo que también es una cantidad infinita de código.

La conclusión es que la protección le otorga poco más que lo público, mientras que la privada le brinda una mejora real. Es la existencia del especificador de acceso protegido lo que es cuestionable, no privado.

Sí, los campos privados son absolutamente necesarios. Sólo esta semana tuve que escribir una implementación de diccionario personalizada donde controlara lo que se colocó en el diccionario. Si el campo del diccionario se hiciera público o protegido, entonces los controles que yo había escrito tan cuidadosamente podrían haberse evitado fácilmente.

Los campos privados suelen ofrecer garantías de que los datos son como el codificador original esperado. Haga que todo lo protegido / público y usted monta un entrenador y caballos a través de esos procedimientos y validación.

Al intentar razonar formalmente sobre la corrección de un programa orientado a objetos es typical para utilizar un enfoque modular que incluya invariantes de objetos . En este enfoque

1. Los métodos se han asociado con ellos antes y después de las condiciones (contratos).
2. Los objetos se han asociado con invariantes.

El razonamiento modular sobre un objeto procede de la siguiente manera (al menos una aproximación al menos)

1. Demuestre que el constructor del objeto establece el invariante
2. Para cada método no privado, suponga que el objeto es invariante y la condición previa del método se mantiene en la entrada, luego pruebe que el cuerpo del código implica que la condición posterior y la invariable se mantienen en la salida del método

Imagina que verificamos un object A usando el enfoque anterior. Y ahora deseamos verificar method g de object B que llama a method f de object A . El razonamiento modular nos permite razonar sobre method g sin tener que reconsiderar la implementación de method f . Siempre que podamos establecer el invariante de object A y la condición previa de method f en el sitio de la llamada en method g, podemos tomar la condición de publicación de method f como un resumen del comportamiento de la llamada al método. Además, también sabremos que después de que la llamada devuelva el invariante de A todavía se mantiene.

Esta modularidad de razonamiento es lo que nos permite pensar formalmente sobre grandes programas. Podemos razonar sobre cada uno de los métodos individualmente y luego componer los resultados de este razonamiento, a su vez, para razonar sobre partes más grandes del programa.

Los campos privados son muy útiles en este proceso. Para saber que el invariante de un objeto continúa reteniéndose entre dos llamadas de método en ese objeto, generalmente confiamos en el hecho de que el objeto no se modifica en el período intermedio.

Para que el razonamiento modular funcione en un contexto en el que los objetos no tienen campos privados, tendríamos que tener alguna forma de asegurarnos de que, independientemente de lo que un campo haya sido configurado por otro objeto, siempre se haya restablecido el invariante ( después del conjunto de campos). Es difícil imaginar un objeto invariante que ambos sostienen independientemente del valor que tengan los campos del objeto, y también es útil para razonar sobre la corrección del programa. Probablemente tendríamos que inventar alguna convención complicada sobre el acceso al campo. Y probablemente también pierda algo de (en el peor de los casos, incluso) nuestra capacidad de razonar de forma modular.

Campos protegidos

Los campos protegidos restauran parte de nuestra capacidad de razonar de forma modular. Dependiendo del idioma protected puede restringir la capacidad de establecer un campo para todas las subclases o todas las subclases y clases del mismo paquete. Es frecuente que no tengamos acceso a todas las subclases cuando razonamos acerca de la corrección de un objeto que estamos escribiendo. Por ejemplo, puede estar escribiendo un componente o una biblioteca que luego se usará en un programa más grande (o en varios programas más grandes), algunos de los cuales aún no se han escrito. Por lo general, no sabrá si y de qué forma puede ser subclasificado.

Sin embargo, por lo general, corresponde a una subclase mantener el objeto invariante de la clase que extiende. Entonces, en un lenguaje donde proteger significa solo "subclase", y donde somos disciplinados para garantizar que las subclases siempre mantengan las invariantes de su superclase, se podría argumentar que la opción de usar protegido en lugar de privado pierde solo una modularidad mínima .

Aunque he estado hablando sobre el razonamiento formal, es a menudo pensado que cuando los programadores tienen motivos informales sobre la exactitud de su código también a veces se basan en tipos de argumentos similares.

Las variables private en una clase son mejores que protected por el mismo motivo por el que una instrucción break dentro de un bloque switch es mejor que una instrucción goto label ; que es que los programadores humanos son propensos a errores.

Las variables protected se prestan para el abuso no intencional (errores del programador), al igual que la declaración goto se presta para la creación del código spaghetti.

¿Es posible escribir código libre de errores de trabajo utilizando las variables de clase protected ? ¡Sí, por supuesto! Así como es posible escribir código libre de errores de trabajo usando goto ; pero como dice el cliché "¡Solo porque puedes, no significa que debas!"

Las clases, y de hecho el paradigma OO, existen para evitar que los programadores humanos propensos a cometer errores cometan errores. La defensa contra los errores humanos es tan buena como las medidas defensivas incorporadas en la clase. Realizar la implementación de su clase protected es el equivalente a hacer un agujero enorme en las paredes de una fortaleza.

Las clases base no tienen ningún conocimiento de las clases derivadas. En lo que respecta a una clase base, protected en realidad no le brinda más protección que public , porque no hay nada que impida que una clase derivada cree un public getter / setter que se comporte como una puerta trasera.

Si una clase base permite el acceso sin obstáculos a sus detalles de implementación interna, entonces es imposible para la clase defenderse contra los errores. Las clases base no tienen ningún conocimiento de sus clases derivadas y, por lo tanto, no tienen forma de protegerse contra los errores cometidos en esas clases derivadas.

Lo mejor que puede hacer una clase base es ocultar la mayor parte posible de su implementación como private y establecer suficientes restricciones para evitar que se rompan los cambios de las clases derivadas o cualquier otra cosa fuera de la clase.

En última instancia, existen lenguajes de alto nivel para minimizar los errores humanos. Las buenas prácticas de programación (como Principios SOLID ) también existen para minimizar los errores humanos.

Los desarrolladores de software que ignoran las buenas prácticas de programación tienen muchas más posibilidades de fallar y es más probable que produzcan soluciones que no se pueden mantener. Los que siguen las buenas prácticas tienen una probabilidad mucho menor de fracasar y es más probable que produzcan soluciones que puedan mantenerse en funcionamiento.

Las clases hereditarias tienen dos contratos, uno con titulares de referencias de objetos y con clases derivadas. Los miembros públicos están sujetos al contrato con los titulares de referencia, y los miembros protegidos están sujetos al contrato con las clases derivadas.

Crear miembros protected hace que sea una clase base más versátil, pero a menudo limita las formas en que podrían cambiar las versiones futuras de la clase. Hacer que los miembros private le permita al autor de la clase una mayor versatilidad para cambiar el funcionamiento interno de la clase, pero limita los tipos de clases que se pueden derivar de manera útil.

Como ejemplo, List<T> en .NET hace que la tienda de respaldo sea privada; si estuvieran protegidos, los tipos derivados podrían hacer algunas cosas útiles que de otra manera no serían posibles, pero las versiones futuras de List<T> tendrían que usar para siempre su monótono almacén de respaldo monolítico incluso para listas que contienen millones de artículos. Hacer que la tienda de respaldo sea privada permitiría que las futuras versiones de List<T> usen una tienda de respaldo más eficiente sin romper las clases derivadas.

Creo que hay una suposición clave en su argumento de que cuando alguien escribe una clase no sabe quién podría extender esa clase más adelante y por qué motivo . Teniendo en cuenta este supuesto, su argumento tendría mucho sentido, ya que cada variable que haga privada podría cortar algún camino de desarrollo en el futuro. Sin embargo, rechazaría esa suposición.

Si se rechaza esa suposición, solo hay dos casos a considerar.

1. El autor de la clase original tenía ideas muy claras de por qué podría extenderse (por ejemplo, es un BaseFoo y habrá varias implementaciones concretas de Foo en el futuro).

En este caso, el autor sabe que alguien extenderá la clase y por qué y, por lo tanto, sabrá exactamente qué hacer protegido y qué hacer privado. Utilizan la distinción de privado / protegido para comunicar una interfaz de tipo al usuario que crea la subclase.

2. El autor de la clase secundaria está intentando piratear algunos comportamientos en una clase primaria.

Este caso debería ser raro (se podría argumentar que no es legítimo), y no se prefiere simplemente modificar la clase original en la base del código original. También podría ser un síntoma de mal diseño. En esos casos, preferiría que la persona que piratea el comportamiento solo use otros hacks como amigos (C / C ++) y setAccessible(true) (Java).

Creo que es seguro rechazar esa suposición.

Esto generalmente se remonta a la idea de composición sobre herencia . La herencia se enseña a menudo como una forma ideal de reducir la reutilización del código, sin embargo, rara vez debería ser la primera opción para la reutilización del código. No tengo un simple argumento de derribo y puede ser bastante difícil y polémico de entender. Sin embargo, en mi experiencia con el modelado de dominios descubrí que rara vez utilizo la herencia sin tener una idea muy clara de quién heredará mi clase y por qué.

Los tres niveles de acceso tienen su caso de uso, OOP estaría incompleto sin ninguno de ellos. Normalmente lo haces

• haga que todas las variables / miembros de datos sean privadas . No desea que alguien del exterior se meta con sus datos internos. También los métodos que proporcionan funcionalidad auxiliar (piense en cálculos basados en varias variables miembro) a su interfaz pública o protegida : esto es solo para uso interno, y es posible que desee cambiar / mejorarlo en el futuro.
• haga que la interfaz general de su clase sea pública . Con eso se supone que deben trabajar los usuarios de su clase original, y cómo cree que deberían ser las clases derivadas. Para proporcionar una encapsulación adecuada, generalmente son solo métodos (y clases / estructuras auxiliares, enumeraciones, typedefs, lo que sea que el usuario necesite para trabajar con sus métodos), no variables.
• declare los métodos protegidos que podrían ser útiles para alguien que quiera ampliar / especializar la funcionalidad de su clase, pero que no debe ser parte de la interfaz pública - de hecho, generalmente eleva miembros privados a protegidos cuando sea necesario. En caso de duda no, hasta que sepas eso.
  1. su clase puede / puede / será subclasificada,
  2. y tenga una idea clara de cuáles pueden ser los casos de uso de subclases.

Y te desvías de este esquema general solo si hay un good reason ™ . Tenga cuidado con "esto facilitará mi vida cuando pueda acceder libremente desde el exterior" (y afuera aquí también incluye subclases). Cuando implemento jerarquías de clases, a menudo comienzo con clases que no tienen miembros protegidos, hasta que las clasifico / extiendo / especializo, convirtiéndome en las clases base de un marco / kit de herramientas y, a veces, subo parte de su funcionalidad original un nivel hacia arriba.

Una pregunta más interesante, tal vez, es por qué es necesario cualquier otro tipo de campo que privado. Cuando una subclase necesita interactuar con los datos de una superclase, al hacerlo directamente se crea un acoplamiento directo entre los dos, mientras que el uso de métodos para proporcionar la interacción entre los dos permite un nivel de direccionamiento indirecto que puede hacer cambios en el Superclase que de otro modo sería muy difícil.

Varios idiomas (por ejemplo, Ruby y Smalltalk) no proporcionan campos públicos, por lo que se desaconseja a los desarrolladores permitir el acoplamiento directo a sus implementaciones de clase, pero ¿por qué no ir más allá y solo tener campos privados? No habría pérdida de generalidad (porque la superclase siempre puede proporcionar accesores protegidos para la subclase), pero aseguraría que las clases siempre tengan al menos un pequeño grado de aislamiento de sus subclases. ¿Por qué este no es un diseño más común?

Muchas buenas respuestas aquí, pero de todos modos lanzaré mis dos centavos. :-)

Privado es bueno por la misma razón por la que los datos globales son malos.

Si una clase declara que los datos son privados, entonces usted sabe absolutamente que el único código que se mete con estos datos es el código de la clase. Cuando hay un error, no tienes que buscar en toda la creación para encontrar todos los lugares que puedan cambiar estos datos. Sabes que está en la clase. Cuando realiza un cambio en el código y cambia algo sobre cómo se usa este campo, no tiene que rastrear todos los lugares potenciales que podrían usar este campo y estudiar si su cambio planificado los romperá. Sabes que los únicos lugares están dentro de la clase.

He tenido muchas, muchas veces que he tenido que hacer cambios en las clases que están en una biblioteca y usadas por múltiples aplicaciones, y tengo que seguir con mucho cuidado para asegurarme de no romper alguna aplicación que conozco nada acerca de. Cuantos más datos públicos y protegidos haya, mayor será la posibilidad de problemas.

Creo que vale la pena mencionar algunas opiniones disidentes.

En teoría, es bueno tener un nivel de acceso controlado por todas las razones mencionadas en otras respuestas.

En la práctica, con demasiada frecuencia cuando se revisa el código, veo personas (a quienes les gusta usar privado), cambiando el nivel de acceso de privado - > protegido y no muy a menudo protegido de > público. Casi siempre, el cambio de propiedades de clase implica modificar modificadores / captadores. Estos han malgastado gran parte de mi tiempo (revisión de código) y de ellos (cambio de código).

También me molesta que eso signifique que sus clases no están cerradas para su modificación.

Eso fue con el código interno donde siempre puede cambiarlo si lo necesita también. La situación es peor con el código de terceros cuando no es tan fácil cambiar el código.

¿Cuántos programadores piensan que es una molestia? Bueno, ¿cuántos están usando lenguajes de programación que no tienen privado? Por supuesto, las personas no solo usan esos idiomas porque no tienen especificadores privados, sino que ayudan a simplificar los idiomas y la simplicidad es importante.

Imo es muy similar a la escritura dinámica / estática. En teoría, la tipificación estática es muy buena. En la práctica, solo evita un 2% de los errores La efectividad irrazonable de la escritura dinámica ... . El uso privado probablemente previene errores menos que eso.

Creo que los principios de SOLID son buenos, deseo que las personas se preocupen por ellos más de lo que se preocupan por crear una clase con público, protegido y privado.

También me gustaría agregar otro ejemplo práctico de por qué protected no es suficiente. En mi universidad, los primeros años emprenden un proyecto en el que tienen que desarrollar una versión de escritorio de un juego de mesa (para lo que luego se desarrolla una IA y se conecta a otros jugadores a través de una red). Se les proporciona un código parcial para que comiencen, incluido un marco de prueba. Algunas de las propiedades de la clase de juego principal están expuestas como protected para que las clases de prueba que extienden esta clase tengan acceso a ellas. Pero estos campos no son información sensible.

Como TA para la unidad, a menudo veo a los estudiantes simplemente haciendo todo su código agregado protected o public (tal vez porque vieron los otros protected y public y asumieron que deberían seguir su ejemplo). Les pregunto por qué su nivel de protección es inapropiado, y muchos no saben por qué. La respuesta es que la información confidencial que están exponiendo a las subclases significa que otro jugador puede hacer trampa simplemente extendiendo esa clase y accediendo a la información altamente sensible para el juego (esencialmente, la ubicación oculta de los oponentes, creo que es similar a cómo sería si podría ver las piezas de sus oponentes en un tablero de acorazados extendiendo alguna clase). Eso hace que su código sea muy peligroso en el contexto del juego.

Aparte de eso, hay muchas otras razones para mantener algo privado incluso en tus subclases. Podría ser ocultar los detalles de la implementación que podrían estropear el funcionamiento correcto de la clase si alguien la cambia y no necesariamente sabe lo que está haciendo (principalmente pensando en otras personas que usan su código aquí).

Los métodos / variables privados generalmente se ocultarán de una subclase. Eso puede ser una buena cosa.

Un método privado puede hacer suposiciones sobre los parámetros y dejar la verificación de la cordura a quien llama.

Un método protegido debería verificar las entradas de información.

"privado" significa: No está diseñado para ser cambiado ni accedido por nadie, excepto la clase en sí. No pretende ser cambiado o accedido por subclases. Subclases? ¿Qué subclases? ¡Se supone que no debes subclasificar esto!

"protegido" significa: Sólo está diseñado para ser cambiado o accedido por clases o subclases. Deducción probable que se debe subclasificar, de lo contrario, ¿por qué "protegido" y no "privado"?

Hay una clara diferencia aquí. Si hago algo privado, se supone que debes mantener tus dedos sucios fuera de él. Incluso si eres una subclase.

  

Una de las primeras cosas que hago cuando hago una subclase de una clase es cambiar una   manojo de métodos privados para proteger

Algunos razonamientos acerca de private vs. protected métodos :

private evitan la reutilización del código. Una subclase no puede usar el código en el método privado y es posible que tenga que implementarlo de nuevo, o volver a implementar el método o los métodos que originalmente dependen del método privado & c.

Por otra parte, cualquier método que sea no private puede verse como una API proporcionada por la clase al "mundo exterior", en el sentido de que se consideran subclases de terceros "mundo exterior" también, como alguien más sugirió en su respuesta ya.

¿Eso es algo malo? - No lo creo.

Por supuesto, una API (pseudo) pública bloquea al programador original y dificulta la refactorización de esas interfaces. Pero visto al revés, ¿por qué un programador no debe diseñar sus propios "detalles de implementación" de una manera tan limpia y estable como su API pública? ¿Debería usar private para que pueda ser descuidado en la estructuración de su código "privado"? ¿Pensando que tal vez podría limpiarlo más tarde, porque nadie lo notará? - No.

El programador también debe pensar un poco en su código "privado", para estructurarlo de una manera que permita o incluso promueva la reutilización de la mayor cantidad posible en primer lugar. Entonces, las partes no privadas pueden no convertirse en una carga tan grande en el futuro como algunos temen.

Una gran cantidad de código (marco) que veo adopta un uso incoherente de private : protected , los métodos no finales que apenas hacen algo más que delegar a un método privado se encuentran comúnmente. protected , métodos no finales cuyo contrato solo se puede cumplir a través del acceso directo a campos privados también.

Estos métodos no pueden ser anulados / mejorados lógicamente, aunque técnicamente no hay nada para hacer que (compilador-) sea obvio.

¿Quieres extensibilidad y herencia? No hagas tus métodos private .

¿No quieres que se altere cierto comportamiento de tu clase? Haz tus métodos final .

¿Realmente no se puede llamar a su método fuera de un contexto determinado y bien definido? Haga que su método private y / o piense en cómo puede hacer que el contexto requerido bien definido esté disponible para su reutilización a través de otro método de envoltorio protected .

Es por eso que recomiendo usar private con moderación. Y no confundir private con final . - Si la implementación de un método es vital para el contrato general de la clase y, por lo tanto, no debe ser reemplazada / anulada, ¡hágalo final !

Para los campos, private no es realmente malo. Siempre que el (los) campo (s) puedan ser "usados" razonablemente a través de los métodos apropiados (eso es no getXX() o setXX() !).

  

¿Conoce un caso de uso importante en el que sea privado en lugar de   Protegido es una buena herramienta, o serían dos opciones "protegido y público"   suficiente para los idiomas OOP?

Privado : cuando tienes algo que nunca será útil para que una subclase llame o anule.

Protegido : cuando tienes algo que tiene una constante / implementación específica de subclase.

Un ejemplo:

public abstract Class MercedesBenz() extends Car {
  //Might be useful for subclasses to know about their customers
  protected Customer customer; 

  /* Each specific model has its own horn. 
     Therefore: protected, so that each subclass might implement it as they wish
  */
  protected abstract void honk();

  /* Taken from the car class. */
  @Override
  public void getTechSupport(){
     showMercedesBenzHQContactDetails(customer);
     automaticallyNotifyLocalDealer(customer);
  }

  /* 
     This isn't specific for any subclass.
     It is also not useful to call this from inside a subclass,
     because local dealers only want to be notified when a 
     customer wants tech support. 
   */
  private void automaticallyNotifyLocalDealer(){
    ...
  }
}

Me fue difícil entender este asunto, por lo que me gustaría compartir un poco de mi experiencia:

• ¿Qué es el campo protegido ? No es nada más que un campo, al que no se puede acceder fuera de una clase, es decir, públicamente de esta forma: $classInstance->field . Y el truco que es "esto es". Los niños de su clase tendrán un acceso completo , porque es su parte interna legítima.
• ¿Qué es el campo privado ? Es un " verdadero privado " para su propia clase y su propia implementación de esta clase. "Manténgalo fuera del alcance de los niños", como en el frasco de un medicamento. Tendrá la garantía de que no se puede derribar por los derivados de su clase, sus métodos, cuando se le llame, tendrán exacto lo que ha declarado

ACTUALIZACIÓN: un ejemplo práctico por una tarea real que he resuelto. Aquí está: tienes un token, como USB o LPT (ese fue mi caso), y tienes un middleware. El token le solicita un código PIN, se abre si es correcto y puede enviar una parte cifrada y una cantidad de clave para descifrar. Las claves se almacenan en el token, no puede leerlas, solo utilizarlas. Y había claves temporales para una sesión, firmadas por una clave en un token, pero almacenadas en un middleware. Se suponía que la clave temporal no debía filtrarse a ningún lado, solo que existía a nivel de conductor. Y utilicé los campos privados para almacenar esta clave temporal y algunos datos relacionados con la conexión de hardware. Por lo tanto, ningún derivado pudo usar no solo una interfaz pública, sino también algunas subrutinas "prácticas" protegidas que he hecho para una tarea, pero no pude abrir una caja fuerte con las teclas y la interacción HW. ¿Tiene sentido?