He estado pensando en algunas "buenas prácticas" con respecto a la estructura del paquete dentro de los paquetes de osgi. Actualmente, en promedio, tenemos como 8-12 clases por paquete. Una de mis iniciativas/propuestas ha sido tener dos paquetes; com.company_name.osgi.services.api (para clases/interfaces relacionadas con API (que se exporta externamente) y un paquete com.company_name.osgi.services.impl para implementación (no exportado)). ¿Cuáles son las ventajas de esto? ¿Cualquier otra sugerencia?Estructura del paquete del paquete OSGi
Respuesta
También podría considerar poner las interfaces en com.company_name.subsystem
, y la implementación en com.company_name.subsystem.impl
, el código específico de OSGI, si hay alguno, podría estar en com.company_name.subsystem.osgi
. En algún momento puede tener una implementación múltiple de las mismas interfaces. En este caso, usted podría considerar - com.company_name.subsystem.impl1
y com.company_name.subsystem.impl2
, por ejemplo:
com.company.scm // the scm api
com.company.scm.git // its git implementaton
com.company.scm.svn // its subversion implementation
com.company.scm.osgi // the place to put an OSGI Activator
en esta estructura de paquetes sentido podría ser agnóstico OSGi, si más adelante en movimiento a un contenedor distinto, sólo hay que poner un adicional
com.company.scm.sca // or whatever component model you might think of
Tener siempre api
y impl
en el nombre de su paquete podría ser molesto. Si tiene dudas, use impl
pero no api
.
No es la cantidad de clases lo que importa, sino los conceptos. En mi opinión, debe tener una entidad conceptual en un paquete. En algunos casos, esto podría ser solo unas pocas clases en otros varios paquetes con cientos de clases.
Lo importante es que separes la API y la implementación. Un paquete contiene la API de su concepto y el otro la implementación. De esta manera puede proporcionar diferentes implementaciones para una API bien definida. En algunos casos, esto puede ser necesario incluso si desea acceder a los servicios desde un paquete de forma remota (utilizando, por ejemplo, R-OGSi)
Los paquetes de API se utilizan luego compartiendo el código y los servicios de los paquetes de implementación compartiendo el servicio. La mejor forma de explorar esas posibilidades es mirar ServiceTrackers.
En su caso, podría tener la implementación en el mismo paquete, pero todas sus clases "paquete protegido". De esta forma, puede exportar el paquete y la implementación no sería visible desde el exterior, incluso cuando no se use OSGi (sino como un archivo jar normal).
- 1. Estructura del paquete DAO
- 2. ¿Cómo funciona la actualización del paquete OSGi?
- 3. pregunta del ciclo de vida del paquete osgi
- 4. Iniciando el paquete OSGi
- 5. ¿La mejor técnica para obtener el contexto del paquete OSGi?
- 6. ¿Cómo establece el marco OSGi la ID del paquete?
- 7. Refactor "estructura del paquete" en Eclipse para reubicar paquete secundario de un paquete a su paquete principal
- 8. Encuentra el paquete OSGI que exporta un paquete?
- 9. conseguir OSGi paquete de Eclipse IConfigurationElement
- 10. com.sun.awt uso del paquete
- 11. Dependencias del paquete R
- 12. Agregando paquete a la estructura del proyecto Java
- 13. Módulos vs capas en la estructura del paquete de Java
- 14. ¿Estructura del paquete para un proyecto de Java?
- 15. Embedded OSGi o paquete de aplicación
- 16. Ejemplos completos del uso del paquete pySerial
- 17. Mal comportamiento del instalador del paquete
- 18. Alias o alias del nombre del paquete
- 19. Desinstalación del paquete WIX MSI
- 20. Log4J nombre del show paquete
- 21. ¿Restablecer la ruta del paquete?
- 22. iPhone - Cambio identificador del paquete
- 23. Dependencias externas del paquete Python
- 24. Procedimiento de especificación del paquete
- 25. log4j: registro específico del paquete
- 26. Common Lisp definición del paquete
- 27. javadoc sin nombre del paquete
- 28. Uso del paquete data.table dentro de mi propio paquete
- 29. Identificador de paquete difiere del identificador de paquete reservado
- 30. Modificar la configuración del paquete desde otro paquete