¿Variables/métodos privados en la clase anónima?

Question

He creado una clase anónima en la que declaro algunas variables y métodos. Mi maestro de Java me dice que haga esto en privado. No veo cómo cambiar el modificador hace ninguna diferencia ya que estas variables y métodos son privados para la clase anónima de todos modos, por lo que prefiero no tener ningún modificador. ¿Quién tiene razón y qué tiene más sentido? Vea a continuación el código de ejemplo en el que no elijo ningún modificador para 'mapa' y 'convertir' en lugar de hacerlo privado.

Collections.sort(list, new Comparator<String>(){ 
    public int compare(String a, String b){ 
    return convert(a).compareTo(convert(b)); 
    } 
    Map<String, String> map = new HashMap<String, String>(); 
    String convert(String s) { 
    String u = map.get(s); 
    if (u == null) 
     map.put(s, u = s.toUpperCase()); 
    return u; 
    } 
}); 

Answer 1

Su profesor tiene razón. Haga que todas las clases sean privadas y expóngalas mediante propiedades (si no anónimas).

La regla general es mantener la información de los miembros como variable, incluido el objeto Map, en privado.

Answer 2

estaría tentado a que sean privadas simplemente por el hecho de que si refactorizar el código y tire de la clase anónima como una clase estándar (IntelliJ, por ejemplo, puede hacer esto con el clic de un botón), teniendo campos privados es lo que realmente quieres. No tendrá que ir y volver a trabajar sus clases para que coincida con su estándar.

Answer 3

Personalmente los haría privados (y finales cuando sea posible) de todos modos, es solo una buena costumbre estar en general.

para decirlo de otra manera: si tenido que poner un modificador de acceso (si, por ejemplo, la palabra clave package también fue utilizado como un modificador de acceso) ¿qué elegiría? Privado, presumiblemente, después de todo, en realidad no desea otorgar ningún otro acceso de clase, ¿verdad?

Ahora, habiendo decidido que privado es el modificador de acceso más lógicamente apropiado, lo haría explícito en el código.

Por otra parte, es muy posible que no creara una clase interna anónima con una variable miembro de todos modos, estaría tentado de convertirla en una clase anidada nombrada en su lugar.

Answer 4

El modificador predeterminado no es el mismo que el modificador private, existen diferencias sutiles. Sin embargo, en su caso, es más una cuestión religiosa si convertir convert() predeterminado o privado. Sin embargo, no veo ninguna ventaja en hacerlo privado.

De todos modos, el código tiene una pérdida de memoria como el caché de cadenas no se borra :-P Además, para aún más corta menos código /, utilice Comparador String.CASE_INSENSITIVE_ORDER:

Collections.sort(list, String.CASE_INSENSITIVE_ORDER); 

Answer 5

Realmente no importa , pero probablemente sea una buena idea mantener feliz a tu profesor ya que él/ella te estará evaluando.

Answer 6

Yo diría que es una cuestión de estilo. No puede acceder al miembro map fuera de la clase anónima, pero podría ser mejor definirlos como privados para mantener la coherencia con otras clases.

Si este fuera mi código, diría que si una clase es lo suficientemente complicada como para necesitar miembros de datos, podría valer la pena extraerla en una clase separada, en cuyo caso los miembros de datos serían privados.

Answer 7

El punto clave es cuando dices "No veo cómo cambiar el modificador hace ninguna diferencia ya que estas variables y métodos son privados para la clase anónima de todos modos" ... estás asumiendo mucho acerca de cómo tu clase va a ser usado.Trate a cada clase como si fuera transmitida y utilizada de diversas maneras; en otras palabras, use modificadores según corresponda. Además, hace clara la intención de clase. No es que Java sea un lenguaje concisa de todos modos, así que también debes ser claro.

Answer 8

No veo mucho beneficio para marcar las cosas privadas solo por el placer de hacerlo. En realidad, no le ganará nada y alguien que lea el código podría otorgar cierta importancia a la elección cuando realmente no la hay.

Answer 9

desea que estos campos sean private, por lo que los marcan private .Si un miembro está marcado ni public no private entonces algo sospechoso está ocurriendo. También marque los campos que no deberían cambiar final. Mantener las cosas estandarizadas significa pensar menos, o al menos pensar menos en lo irrelevante, y menos cambiar cuando se modifica el código.

Desde el punto de vista del lenguaje, la única diferencia real es que si extendió una clase base en el mismo paquete, ahora tiene campos ocultos o reemplazó los métodos "paquete-privado" (acceso predeterminado). También se puede acceder a los miembros a través de la reflexión (sin setAccessible) por código en el mismo paquete (esto puede tener implicaciones de seguridad para el código móvil).

Answer 10

Me gustaría cuestionar la necesidad de toda esta complejidad. Eche un vistazo a: String.compareToIgnoreCase()

Answer 11

diferencia entre predeterminado y protegido.

protected: objeto/método es accesible para todas las clases que están en el mismo paquete, y también accesibles para sub/clases de extensión.

predeterminado: objeto/método es accesible a todas las clases que se encuentran en el mismo paquete.

Cuál es su intención de su objeto/método y modificador de código en consecuencia. No se deje confundir cuando regrese al código después de seis meses, porque en proyectos grandes, quiere saber que ese objeto/método no es accesible en ningún otro lado.

En tres semanas, no sólo meses, se olvidarían lo que la accesibilidad prevista de esos objetos, garantizada 101%. Entonces, si tienes un gran proyecto y tienes cien modificadores que no son específicos y deseas desesperadamente actualizar el código, te sentirás frustrado por la compulsión de ejecutar una verificación de referencia en esos 100 objetos/métodos. Puede ser que alguien haya tomado su jarra y encontrado las cookies ocultas en ellas y las haya usado, luego cambió su código y rompió el código de alguien.

Code sus modificadores de acuerdo a su intención a menos que son o bien uno o más de los siguientes:

1. no tiene más ganas de trabajar en grandes proyectos de Java.

2. usted es una persona autista extremadamente inteligente alta funcionamiento que tiene una memoria indexada de todos los acontecimientos de su vida y puede escribir un par a par servicio de intercambio de archivos completamente funcional dentro de dos semanas en un ordenador portátil en una cafetería .

3. deliberadamente lo usa como otra herramienta para ocultar su código .