¿Es posible (recomendado) tener un api-project puro que esté separado de la implementación real?

Question

Se me pidió que creara un diseño de proyecto para nuestra próxima aplicación usando Maven. El primer artefacto en el que vamos a trabajar será la arquitectura. Para facilitar el trabajo de los desarrolladores, tuve la idea de separar la implementación real de la API (como lo haría en un entorno OSGi).

Las dependencias enumerarían el proyecto API como una dependencia para el ámbito de compilación y la implementación solo se proporciona en el tiempo de ejecución.

Con este enfoque, espero reducir la complejidad de los desarrolladores y también evitar que usen clases internas que son frecuentes y están sujetas a cambios. Además, es posible ocultar dependencias transitivas (por ejemplo, no quiero que los desarrolladores llamen a la capa DAO desde el frontend ... esto solo debería ser visible desde la capa de servicio).

¿Alguien ha puesto esto en práctica y cómo ha ido? ¿Qué piensas al respecto en general?

Answer 1

UML le permitimos modelar de esta manera, y algunas herramientas UML generarán código basado en el modelo, que en teoría ayudará a cerrar la brecha de UML a código, cuando llegue el momento.

Enterprise Architect es una de esas herramientas. Pero esto requiere que tu equipo sea conocedor de UML y conocedor de algunas herramientas UML.

Answer 2

Creo que es un buen enfoque y lo uso todo el tiempo. No he experimentado inconvenientes reales al hacerlo de esta manera.

Ejemplo de mi uso es algo así como una biblioteca de raspado de pantalla.

me gustaría tener un proyecto Maven:

data-source-api 

que tiene un servicio como:

package my.datasource.api; 

public interface DataSource { 
    public GetDataResponse getData(GetDataRequest request); 
} 

Dónde GetDataRequest y GetDataResponse (y otras clases de la API) son también en el proyecto API.

y también tienen proyectos Maven llamados:

data-source-urlfetch-impl // for appengine 
data-source-http-client-impl // for Apache HTTP client 
data-source-urlconnection-impl // for appengine/vanilla Java 

Para cada uno de mis implementaciones. Por ejemplo:

package my.datasource.urlfetch; 

public class UrlFetchDataSource implements DataSource { 
    ... 
} 

Answer 3

Su diseño de sonido separa la interfaz (contrato) y la implementación. Pero como con todo, úselo con moderación. No desea restringir y complicar el diseño hasta el punto en que cueste más de lo que ofrece. Recuerde, se supone que debe agregar un beneficio (o un riesgo menor), no es un objetivo en sí mismo. Pregúntese por qué hace estas cosas, cuál es el costo y el beneficio, y cuál sería el riesgo asociado o el costo de NO hacerlo.

Answer 4

lo he visto mucho, y hay ventajas y desventajas de este enfoque:

• Ventajas
  • Clara separación de principios activos y aplicación
• Desventajas
  • Más difícil de entender, porque no hay un contexto real, ejemplo, pruebas unitarias para entender la API.
  • Más difícil de refactorizar y comprender las consecuencias de la definición y los cambios de la API. Soy pobre para imaginar lo que puede ser una buena API hasta que la haya usado (y haya visto que no funciona bien).
  • Si hay una implementación (en ejecución) detrás de su API que no es accesible para las personas, es difícil o incluso imposible implementar una prueba real para la aplicación real.

así que creo que es agradable para publicar una API como API única, pero es difícil desarrollar la API sin el código fuente real, y en ocasiones para poner en práctica el API real sin la ejecución de código que muestra cómo funciona.

Diferentes enfoques podrían ser:

• se desarrollan con la API de una implementación por defecto como escaparate.
• Desarrolla con la API una implementación de ejemplo que muestra cómo usar la API.
• Desarrolla un conjunto de pruebas unitarias y simulacros de objetos para mostrar cómo usar tu API en pruebas unitarias.