Programación basada en interfaz
 | Este artículo incluye una lista de referencias generales , pero permanece en gran parte sin verificar porque carece de suficientes citas en línea correspondientes . ( Septiembre de 2016 ) |
 | Este artículo necesita citas adicionales para su verificación . ( mayo de 2015 ) |
La programación basada en interfaz , también conocida como arquitectura basada en interfaz , es un patrón arquitectónico para implementar la programación modular a nivel de componente en un lenguaje de programación orientado a objetos que no tiene un sistema de módulos. Un ejemplo de dicho lenguaje es Java , que (a partir de 2015 [actualizar]) no tiene un sistema de módulos a nivel de componentes. Java tiene un sistema de paquetes , pero los componentes de software de Java suelen constar de varios paquetes de Java - y en cualquier caso, la programación de interfaces puede ofrecer ventajas sobre el mero uso de paquetes de Java, incluso si un componente solo consta de un único paquete de Java.
La programación basada en interfaz define la aplicación como una colección de componentes, en la que las llamadas a la interfaz de programación de aplicaciones (API) entre componentes solo se pueden realizar a través de interfaces abstractas, no de clases concretas. Las instancias de clases generalmente se obtendrán a través de otras interfaces utilizando técnicas como el patrón Factory .
Se afirma que esto aumenta la modularidad de la aplicación y, por lo tanto, su capacidad de mantenimiento . Sin embargo, se requiere cierta precaución: simplemente dividir una aplicación en componentes arbitrarios que se comunican a través de interfaces no garantiza en sí mismo un bajo acoplamiento o una alta cohesión , otros dos atributos que comúnmente se consideran clave para la mantenibilidad.
Se puede utilizar una arquitectura basada en interfaz cuando terceros, o incluso equipos separados dentro de la misma organización, desarrollan componentes o complementos adicionales para un sistema establecido. El código base del Eclipse IDE es un ejemplo de programación basada en interfaz. Los proveedores de complementos de Eclipse solo tienen que desarrollar componentes que satisfagan la interfaz especificada por el proveedor de la aplicación principal, Eclipse Foundation. De hecho, en Eclipse, incluso los componentes originales, como las herramientas de desarrollo de Java, son en sí mismos complementos. Esto es algo así como un fabricante de teléfonos móviles que especifica una interfaz de cargador móvil (disposición de pines, corriente continua esperada voltaje, etc.) y tanto el fabricante como los terceros fabrican sus propios cargadores de teléfonos móviles que cumplen con esta especificación de interfaz estándar.
Evolución del software en la programación basada en interfaces
El uso de interfaces para permitir la colaboración de equipos dispares plantea la cuestión de cómo ocurren los cambios de interfaz en la programación basada en interfaz. El problema es que si se cambia una interfaz, por ejemplo, al agregar un nuevo método, el código antiguo escrito para implementar la interfaz ya no se compilará, y en el caso de complementos cargados dinámicamente o vinculados, no se cargará o vinculará, o bloqueo en tiempo de ejecución. Hay dos enfoques básicos para abordar este problema:
- Se puede desarrollar una nueva interfaz con funcionalidad adicional, que podría heredar de la interfaz anterior.
- Se puede comunicar una política de versiones de software , como la versión semántica 2.0 , a los implementadores de la interfaz, para permitir cambios incompatibles con versiones anteriores, o incluso con versiones anteriores, en futuras versiones "principales" de la plataforma.
Ambos enfoques se han utilizado en la plataforma Java.
Diseño por contrato
El editor de las interfaces generalmente promete que no cambiará la interfaz en nuevas versiones "menores" del software, y el implementador, al implementar la interfaz, implica que ha implementado al menos las partes requeridas de la interfaz sin ninguna desviación. Por lo tanto, una interfaz puede verse como un "acuerdo contractual", entre un proveedor y un consumidor de la interfaz. Si este contrato está documentado de manera más formal como una especificación de software, este es un ejemplo de diseño por contrato . Sin embargo, el diseño por contrato per se no exige el uso de interfaces para todos los componentes.
Ver también
- Microservicios
- Modelo de actor
- CORBA , un antiguo sistema basado en componentes para software orientado a objetos que ahora rara vez se usa, por varias razones
Referencias
- Desarrollo basado en interfaz C # , c-sharpcorner.com
- Desarrollo basado en interfaces: el lenguaje de modelado unificado (UML) , devmentor.org
- Architecting a large application with interface-based architecture , rhyous.com, 18 de octubre de 2011
- Comprensión de la programación basada en interfaces , Microsoft Developers Network , consultado el 16 de septiembre de 2016
- Patrón arquitectónico (informática)
