java - proyectos - programa basico en android
¿Por qué algún código de Android tiene campos públicos? (2)
Echa un vistazo a esta sección de developer.android.com:
En idiomas nativos como C ++, es una práctica común usar getters (i = getCount ()) en lugar de acceder directamente al campo (i = mCount). Este es un hábito excelente para C ++ y se practica a menudo en otros lenguajes orientados a objetos como C # y Java, porque el compilador generalmente puede integrar el acceso, y si necesita restringir o depurar el acceso a los campos, puede agregar el código en cualquier momento.
Sin embargo, esta es una mala idea en Android. Las llamadas a métodos virtuales son caras, mucho más que las búsquedas de campo de instancia. Es razonable seguir las prácticas comunes de programación orientada a objetos y tener captadores y definidores en la interfaz pública, pero dentro de una clase siempre debe acceder a los campos directamente.
Sin un JIT, el acceso directo al campo es aproximadamente 3 veces más rápido que invocar a un captador trivial. Con el JIT (donde el acceso directo al campo es tan barato como acceder a un local), el acceso directo al campo es aproximadamente 7 veces más rápido que invocar a un captador trivial.
Tenga en cuenta que si está utilizando ProGuard, puede tener lo mejor de ambos mundos porque ProGuard puede en línea accesores para usted
developer.android.com/training/articles/…
Probablemente, esta es la razón por la que ve campos públicos en AOSP.
Hay muchas preguntas y respuestas sobre el uso de campos públicos en la Programación Orientada a Objetos, y la mayoría de ellos recomienda no usar campos públicos por muchas razones.
Pero cuando miré el código de Android, encontré que algunas clases usan campos públicos. Por ejemplo, Android.view.View tiene campos públicos mCachingFailed y mAttributes .
¿Por qué son públicos? Es difícil pensar que esto es un error de parte de Google y AOSP.
No es inherentemente un error tener campos públicos. No es, como sugiere la nota de recompensa, una "violación fundamental de OOP". Después de todas estas dos clases son (para la mayoría de los propósitos) idénticas:
public class DemoA {
public int field;
}
public class DemoB {
private int field;
public int getField() { return field; }
public void setField(int value) { field = value; }
}
Es decir, si tiene la intención de que las personas que llaman tengan acceso directo de lectura y escritura a un campo que agregue un captador y configurador puede ser una placa de caldera adicional.
El beneficio de los captadores y definidores, incluso si no hacen otro trabajo que leer y escribir en los campos, es que abstraen el hecho de que los datos se almacenan en un campo en absoluto. Puede almacenarse en una fuente de datos externa o calcularse sobre la marcha, o lo que quiera, y las personas que llaman no tienen que preocuparse por cómo se implementa el comportamiento. Esta es definitivamente una buena práctica en general porque separa las preocupaciones de los llamantes (la API) de sus preocupaciones (la implementación).
Sin embargo, a veces es solo una exageración, y es perfectamente razonable exponer los campos públicos si esa es la mejor manera de proporcionar el comportamiento que necesitan las personas que llaman. La mayoría de las veces, esto se hace para tipos de valor , clases que existen únicamente para agrupar una serie de campos. No hay muchos beneficios en escribir los puntajes de los que consiguen y los que establecen cuando todo lo que necesita una clase para hacer se puede lograr simplemente haciendo públicos los campos.
Como cuestión práctica, Android tiene una preocupación adicional. Las llamadas a los métodos son caras y la cantidad de métodos que una aplicación puede (fácilmente) definir está limitada a ~ 65k . Para los casos en los que es seguro hacerlo, la exposición de un campo reduce directamente la sobrecarga del método en dos y ahorra valioso tiempo de CPU. Puede que no parezca mucho, pero se acumula rápidamente.