Información básica sobre programación orientada a interfaces

En un sistema orientado a objetos, varias funciones del sistema se completan mediante la cooperación de muchos objetos diferentes. En este caso, cómo se implementa cada objeto no es tan importante para los diseñadores de sistemas; la relación de colaboración entre cada objeto se convierte en la clave del diseño del sistema. Desde la comunicación entre diferentes clases hasta la interacción entre módulos, todo debe considerarse al comienzo del diseño del sistema. Este es también el contenido de trabajo principal del diseño del sistema. La programación orientada a interfaz se refiere a la programación según esta idea.

1. Comprensión de las interfaces.

Desde una comprensión más profunda, la interfaz debe ser la separación de la definición (especificación, restricciones) y la implementación (el principio de separación de nombre y realidad).

La interfaz en sí refleja la comprensión abstracta del sistema por parte del diseñador del sistema.

Debería haber dos tipos de interfaces: el primer tipo es una abstracción de una entidad, que puede corresponder a una clase abstracta.

El segundo tipo es una abstracción de una entidad. La abstracción, por un lado, forma una superficie abstracta (interfaz);

Una entidad puede tener múltiples superficies abstractas.

Existe una diferencia entre cuerpo abstracto y superficie abstracta.

2. Otro factor que no se puede ignorar a la hora de diseñar una interfaz es el entorno (contexto, entorno) en el que se ubica la interfaz. Desde la perspectiva de la teoría de sistemas: el entorno es la suma del espacio donde se encuentra el sistema. Se ubican los elementos y los factores externos que influyen. Cualquier interfaz se genera en un entorno determinado. Por lo tanto, no se puede ignorar el impacto de la definición del entorno y los cambios en el entorno en la interfaz. Sin el entorno original, todas las interfaces perderán su significado original.

3. Según el modelo de desarrollo de componentes (3C), los tres se complementan, cada uno tiene su propio rol y son integrados e indispensables.

Orientado a objetos significa que cuando pensamos en problemas, usamos objetos como unidades para considerar sus propiedades y métodos.

Orientado a procesos significa que cuando pensamos en problemas, usamos una proceso específico (proceso de transacción) como una unidad, considere su implementación

El diseño de interfaz y el diseño sin interfaz son para tecnología de reutilización y no son un problema con (proceso) orientado a objetos

UML La interfaz mencionada es otra forma de decir protocolo. No se refiere a la interfaz COM, la interfaz CORBA, la interfaz Java, la interfaz Delphi, la interfaz hombre-computadora o la interfaz NIC.

En una implementación específica, la interfaz UML se puede implementar como una interfaz de lenguaje, una interfaz de entorno de objetos distribuidos u otras interfaces, pero en términos de comprensión de la interfaz UML, se refiere a cada parte del sistema. juntos a través del protocolo determinado por la interfaz.

La programación orientada a interfaz originalmente significa programación abstracta orientada a protocolos, y los implementadores deben seguir estrictamente el protocolo al implementar. La programación orientada a objetos se refiere a la abstracción y la representación. La abstracción y la concreción son una unidad contradictoria, y es imposible tener sólo abstracción sin concreción. Generalmente, las personas que entienden la abstracción comprenden esta verdad. Pero algunas personas sólo conocen la concreción pero no saben qué es la abstracción. Por lo tanto, solo una interfaz sin implementación, o solo una implementación sin interfaz, es inútil y anti-OO.

Así que limítese a la programación orientada a objetos, a la programación orientada a protocolos, o no se oriente a nada y simplemente limítese a la programación.

Pero odio discutir esos términos. ¿Qué tal si hablamos de qué es la programación orientada al liderazgo? ¿Programación orientada al usuario? Los líderes y usuarios a veces son muy BT, entonces ¿por qué deberíamos programar para BT?

Elija interfaz Java o clase abstracta

Muchas personas han tenido esta pregunta: ¿Por qué algunos lugares tienen que usar interfaces en lugar de clases abstractas, mientras que en otros lugares se debe usar la abstracción? ¿Qué pasa con las clases en lugar de las interfaces? En otras palabras, al considerar la generalización de las clases de Java, muchas personas dudarán entre interfaces y clases abstractas, o incluso elegirán una a voluntad.

De hecho, la elección de interfaces y clases abstractas no es arbitraria. Para comprender los principios de selección de interfaces y clases abstractas, son importantes dos conceptos: el comportamiento del objeto y la implementación del objeto. Si una entidad se puede implementar de múltiples maneras, entonces al diseñar la descripción del comportamiento de la entidad, el objetivo debe ser lograr el objetivo de que al usar la entidad, no sea necesario saber en detalle cómo se implementa el comportamiento de la entidad. En otras palabras, el comportamiento del objeto debe separarse de la implementación del objeto. Dado que tanto las interfaces Java como las clases abstractas pueden definir métodos que no proporcionan una implementación específica, al separar el comportamiento de un objeto y su implementación, ¿debería utilizar una interfaz o una clase abstracta?

Construcción de modelos de comportamiento a través de clases abstractas

Al seleccionar interfaces y clases abstractas, uno debe adherirse al principio de que los modelos de comportamiento siempre deben definirse a través de interfaces en lugar de clases abstractas. Para ilustrar el motivo, intentemos construir un modelo de comportamiento a través de clases abstractas y veamos qué problemas pueden surgir.

Supongamos que desea diseñar un software para el departamento de ventas. Este software contiene una entidad "Motor". Obviamente, no es posible describir todos los aspectos del motor en detalle en el objeto del motor, sólo ciertas características que son importantes para el software actual. En cuanto a qué características del motor son importantes, esto sólo puede determinarse comunicándose con el usuario (departamento de ventas).

El departamento comercial exige que cada motor tenga un parámetro llamado caballos de fuerza. Para ellos, este es el único parámetro que vale la pena tener en cuenta. Con base en este juicio, el comportamiento del motor se puede definir como el siguiente comportamiento.

Comportamiento 1: consulta los caballos de fuerza del motor y el motor devolverá un número entero que representa los caballos de fuerza.

Aunque no está claro cómo obtiene el motor el parámetro de potencia, lo cierto es que el motor debe soportar este comportamiento, y este es el único comportamiento característico de todos los motores digno de atención. Esta característica de comportamiento puede definirse mediante una interfaz o mediante una clase abstracta. Para ilustrar los problemas que pueden surgir al usar definiciones de clases abstractas, a continuación se utilizan clases abstractas para establecer el modelo de comportamiento del motor y se utilizan métodos Java para describir el comportamiento 1. El código es el siguiente:

Código

public abstract Motor{

abstract public int getHorsepower();

}

Se construye una variedad de implementaciones concretas basadas en la clase abstracta del motor, como el motor tipo A, el motor tipo B, etc., además de otras partes del sistema, finalmente obtenga la versión 1.0 del software y entreguela para su uso. Ha pasado un tiempo y ha llegado el momento de diseñar la versión 2.0 del software. En el proceso de evaluación de los requisitos de software para la versión 2.0, se descubrió que una pequeña parte del motor funciona con batería y la batería requiere una cierta cantidad de tiempo de carga. La gente del departamento de ventas quiere poder comprobar los tiempos de carga de sus ordenadores. Defina un nuevo comportamiento basado en este requisito, como se muestra en la Figura 1.

Comportamiento 2: consulta el tiempo de carga del motor eléctrico y el motor devolverá un número entero que representa el tiempo de carga.

Utilice el método Java para describir este comportamiento. El código es el siguiente:

Código

resumen público BatteryPoweredMotor extends Motor{

resumen public int getTimeToRecharge ();

}

En el software del departamento de ventas, el motor de accionamiento eléctrico también se implementa en forma de clases, pero estas clases se derivan de BatteryPoweredMotor en lugar de Motor. . Después de que se agregaron estos cambios a la versión 2.0 del software, el departamento de ventas quedó muy satisfecho. A medida que el negocio siguió desarrollándose, no pasó mucho tiempo antes de que aparecieran los motores impulsados ​​por luz. El departamento de ventas requiere que el motor impulsado por luz requiera una cierta cantidad de energía luminosa para funcionar, y la energía luminosa se mide en lúmenes. Esta información es importante para los clientes porque es posible que algunos motores impulsados ​​por luces no funcionen durante el tiempo lluvioso o nublado. El departamento de ventas solicitó que el software agregara soporte para motores ligeros, por lo que se tuvo que definir un nuevo comportamiento.

Comportamiento 3: Consulta el número mínimo de lúmenes necesarios para que el motor de accionamiento de luz funcione normalmente y el motor devuelve un número entero.

Defina otra clase abstracta y convierta el comportamiento 3 en un método Java. El código es el siguiente:

Código

public abstract SolarPoweredMotor extends Motor{

resumen public int getLumensToOperate();