Abstracción con Java en Android

Estaba estudiando algunos tutoriales sobre el lenguaje Java. Me preguntaba si debería abstraer cada vez que código algo, y en cualquier tipo de estándar y la pila?

He visto que con cada Spring Services, por ejemplo, podríamos incluso abstraer los controladores, utilizando interfaces con EJBs en la pila JavaEE, etc.

Me preguntaba cuál es el objetivo de eso? ¿Debo hacer lo mismo mientras desarrollo con el SDK de Android?

¿Debo abstraer todas las clases que codifico?

    Siempre es una buena idea hacer componentes modulares y reutilizables . Cuando una aplicación se construye desde cero con esto en mente, se vuelve más y más escalable , más y más auto-extensible . Los mismos componentes de una aplicación se reutilizan cuando se agregan nuevas funciones, lo que ahorra tiempo y esfuerzo. Y es más fácil hacer cambios más adelante o identificar fuentes de errores. La refactorización nunca debe ser después, sino desde el principio.

    Dicho esto, no es una gran idea tener más y más abstracciones en las aplicaciones móviles sólo por el bien de la "abstracción". La razón, por supuesto, es que los teléfonos inteligentes no son tan potentes como los servidores o incluso las computadoras de escritorio. Hay una penalización de rendimiento asociada literalmente a cada clase y método virtual en una aplicación de Android. Debe haber un mayor equilibrio entre "abstracción" y eficiencia, y los compromisos de rendimiento se vuelven más visibles en los dispositivos de gama media y baja.

    De los documentos oficiales:

    1. Tenga cuidado con las abstracciones de código

    2. Evitar los marcos de inyección de dependencia

    3. Evitar crear objetos innecesarios

    4. Prefiere la estática a través de Virtual

    5. Evite los Interruptores Internos

    EDITAR:

    Después de haber probado recientemente Dagger , tengo que admitir que el punto 2 puede ser un poco anticuado por ahora. ¿Qué puedo decir … Vine a la fiesta de la Daga muy tarde.

    Necesitas abstracción siempre que tengas una clase que no quieras implementar todos sus métodos. Aquellas clases que lo heredan se verán obligadas a implementar todos esos métodos, de lo contrario tendrían que declarar las subclases como abstractas también.

    Además de que debe ser consciente de la interfaz, los métodos de interfaz no debe tener cuerpo y lo bueno es que su clase puede implementar tanto como la interfaz que desee. Mientras que, sólo se puede heredar una clase abstracta. Las interfaces son como contratos. Cualquiera que sea la clase que las implemente, debe proveer cuerpo para todos sus métodos.

    Si usted necesita el extracto o la interfaz o ambos es realmente dependen de su diseño y de lo que usted desea poner en ejecución. Aunque es una buena práctica obligar a aquellas clases que tienen métodos comunes para implementar la misma interfaz (si no sabes nada sobre el cuerpo de cada uno de los métodos) o abstracto (si sabes lo que el cuerpo de algunos, todos o ninguno de ellos los métodos)

    Otro ejemplo sería cuando tienes abstracción o interfaz si agregas algo a ellos todas las subclases o clases que las están implementando necesitan seguir esas modificaciones, significa que el podría sería más fácil de ser modificado.

    Eche un vistazo a esto , esto y esto y el principio de apertura / cierre también.

    Esto se puede interpretar de muchas maneras diferentes. En mi punto de vista, la abstracción se utiliza en la codificación como un principio de diseño, en los casos en que se necesita una extensión o muchos tipos de implementaciones. Por ejemplo, en Spring, un controlador puede haber definido como una clase abstracta (A) y tener varios otros tipos de controladores (B, C, D ..) que se extienden A. Como usuario del framework Spring, si no se satisface con Las implementaciones de controlador disponibles, todavía puede desarrollar su propio controlador de extensión A. También los desarrolladores de primavera también puede ampliar / añadir nuevos controladores en versiones futuras con facilidad.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.