Estructura del paquete de proyectos de Android
Me pregunto, cómo crear una estructura de paquetes flexible para una aplicación de Android, de modo que será fácil extender y administrar. Mi primera idea es poner cada componente de la aplicación en un paquete aparte, como por ejemplo:
Spk.myapp.main (todas las clases utilizadas en la actividad principal) spk.myapp.processor. (Todas las clases utilizadas por el proveedor de Procesador)
…y así. Sin embargo, el aspecto que no me gusta es que la clase y la convención de nomenclatura de paquetes puede llegar a ser rápidamente inconsistente con otros nombres totalmente calificados, como las autoridades de proveedores (en este caso prefiero nombrarlos spk.myapp.processor que spk.myapp .processor.processor como sugeriría la ruta del paquete de clase).
He hecho algunas investigaciones, pero la mayoría de las páginas explican la estructura inicial del directorio del proyecto, en lugar de sugerir una para proyectos más grandes.
Mi problema puede sonar tonto, pero me gusta tener orden en mis proyectos desde el principio, de tal manera que una mayor gestión y ampliación de ellos no implica refactorings innecesarios o limpiezas. Además, no tengo mucha experiencia en Java y deseo aprender buenos hábitos desde el principio.
¿Se tiene una estructura de paquete de proyecto buena y fiable y convenciones de nomenclatura para los proyectos de Android?
Wikipedia tiene notas útiles sobre paquetes Java. Los paquetes son principalmente útiles por dos razones:
- Un paquete proporciona un espacio de nombres único para los tipos que contiene.
- Las clases en el mismo paquete pueden tener acceso a los miembros del paquete de acceso.
El primer punto significa que puede agrupar elementos por funcionalidad lógica. Las actividades podrían residir bajo un paquete de actividades y sus servicios bajo un paquete de servicios.
El segundo punto es muy importante ya menudo se pasa por alto. El acceso al paquete le permite hacer algunas cosas inteligentes. Por ejemplo, puede tener una clase 'constructor' que puede crear y rellenar modelos que tengan propiedades de acceso a paquetes, sin agregar muchos métodos setter ni utilizar propiedades públicas. Esto puede hacer que la creación de objetos sea realmente simple e intuitiva, mientras que los objetos permanecen inmutables fuera del paquete.
Un ejemplo realmente bueno de este principio se puede encontrar en la aplicación de Shelves de Romain Guy. La clase BookStore puede crear objetos Book y modificar sus miembros, sin exponer estos campos a otras clases (en otros paquetes).