Acceder a los campos singleton mediante un método estático

Tengo una clase singleton.

Al acceder a los métodos de la clase tengo la opción de dos posibilidades.

  1. Cree estos métodos como específicos de la instancia y luego obtenga la instancia y invójalos
  2. Cree los métodos como estáticos e invócelos y obtendrán la instancia

Por ejemplo:

Class Test{ private int field1; Test instance; private Test(){}; private Test getInstance(){ if (instance == null) instance = new Test(); return instance; } public int method1() { return field1;} public static int method2() {return getInstance().field1;} } 

Ahora, en otro lugar puedo escribir

  int x = Test.getInstance().method1(); int y = Test.method2(); 

¿Cual es mejor? Puedo pensar en una tercera alternativa donde yo uso "instancia" directamente en el método estático y luego capturar la excepción si es nulo y instanciarlo y luego volver a invocarse a sí mismo.

Podría, en teoría, hacer que toda la porción sea estática. Sin embargo, esto me creará problemas al guardar el estado en cierre de actividad ya que la serialización no guarda estática.

Creo que el primero está más limpio.

Sin embargo, tenga en cuenta que en algunos casos extremos, Android puede matar sus instancias estáticas. Consulte esto, por ejemplo: http://code.google.com/p/acra/ .

Una solución que he encontrado en algún lugar para esto, es mantener una referencia a su singleton de la clase de aplicación, también. No sé cómo es la prueba de problemas esto es, sin embargo.

Debe evitar hacer todo estático. Alguna gente incluso diría que un singleton no se hace.

El punto entero del patrón singleton es que puedes cambiar la implementación . En la mayoría de los casos, se utiliza para mantener abierta la posibilidad de "gancho" en algunas otras implementaciones de esta funcionalidad más adelante.

Lea: al decidir a favor del plan singleton para un método setInstance también, no sólo para un getInstance . – Si esto no tiene sentido, simplemente utilice una clase estática simple.

En la otra mano los singletons están fuera de estación, si usted quiere ser cadera y todo el eso. Haga una búsqueda para " eliminando el estado global ". También hay algunas charlas patrocinadas por Google. En resumen: su código será más comprobable y le ayudará a evitar un caos de dependencia. (Además de ser cadera y todo, es definitivamente un paso en la dirección correcta).

En mi opinión personal tener métodos estáticos es diseño malo en el primer lugar. Por supuesto, depende del programa en sí, pero permitir que una clase tenga un método estático tendrá impacto en todo el diseño. Algunos razonamientos detrás de mi declaración:

  1. Si el método estático puede cambiar fácilmente el estado de algún objeto, tarde o temprano aparecerán errores
  2. Si publica un método estático con su programa, cada cliente que lo utilice tendrá una dependencia muy fuerte en su código. Si decide eliminar o cambiar este método algún día – romperá cada cliente que usó su clase.

Así que, si puede – evitarlo .

Si, por cualquier razón, insiste en tener un método estático, supongo que la primera solución es mejor . Así es como singleton debería funcionar. Debe obtener una referencia a un SINGLETON OBJECT a través de un método estático, pero este objeto debe utilizarse de acuerdo con todos los principios de la programación orientada a objetos .

  • Ampliación de la clase de aplicación y buenas prácticas
  • Los datos estáticos guardados dentro de singleton son nulos a veces cuando se vuelve a la aplicación desde el fondo
  • ¿Qué hace este método privado en esta clase singleton Java?
  • Tiempo de vida único estático en Android
  • ¿Por qué un servicio Android no es singleton cuando se prueba?
  • Usando Gson para deserializar a Json en un singleton
  • Android: una vs muchas instancias de HttpClient por aplicación
  • Actividad de Android singleton
  • Patrón de bloqueo de múltiples hilos de SQLiteDatabase
  • Uso del servicio como singleton en Android
  • Cómo declarar variables globales en Android?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.