1. El principio y la realización del modelo proxy
Sin cambiar la clase original (o llamada clase de proxy), se introduce la clase de proxy para agregar funcionalidad a la clase original. En circunstancias normales, dejamos que la clase proxy y la clase original implementen la misma interfaz. Sin embargo, si la clase original no define una interfaz y el código de la clase original no es desarrollado ni mantenido por nosotros. En este caso, podemos implementar el modo proxy dejando que la clase proxy herede el método de la clase original.
2. Principio y realización del agente dinámico
Los agentes estáticos necesitan crear una clase de proxy para cada clase, y el código en cada clase de proxy es un poco como un código "duplicado" similar a una plantilla, lo que aumenta los costos de mantenimiento y de desarrollo. Para los problemas de proxy estático, podemos solucionarlo mediante proxy dinámico. No escribimos una clase de proxy para cada clase primitiva de antemano, sino que creamos dinámicamente la clase de proxy correspondiente a la clase original en tiempo de ejecución y luego reemplazamos la clase original con la clase de proxy en el sistema.
3. Escenarios de aplicación del modo proxy
El modelo de agente se usa a menudo para desarrollar algunos requisitos no funcionales en los sistemas comerciales, como: monitoreo, estadísticas, autenticación, limitación de corriente, transacciones, idempotencia y registro. Desacoplamos estas funciones adicionales de las funciones comerciales y las colocamos en la clase de agente para el procesamiento unificado, de modo que los programadores solo necesiten concentrarse en el desarrollo comercial. Además, el modo proxy también se puede utilizar en escenarios de aplicaciones como RPC y almacenamiento en caché.
Modo Puente
En el libro "Patrones de diseño" de GoF, el patrón puente se define como: "Desacoplar la abstracción y la implementación para que se puedan cambiar de forma independiente". En otros materiales y libros, hay otra forma más sencilla de entender: " Una clase tiene dos (o más) dimensiones que cambian de forma independiente. Combinamos estas dos (o más) dimensiones para expandirlas de forma independiente ".
Para la primera forma de entender GoF, entender los dos conceptos de "abstracción" e "implementación" en la definición es la clave para entenderlo. La "abstracción" en la definición no se refiere a "clases abstractas" o "interfaces", sino a un conjunto de "bibliotecas de clases" abstractas, que solo contienen código esqueleto, y la lógica empresarial real debe delegarse a la "implementación" en la definición. "Para acabar. La "implementación" en la definición no es la "clase de implementación de la interfaz", sino un conjunto de "bibliotecas de clases" independientes. La "abstracción" y la "realización" se desarrollan de forma independiente y se ensamblan mediante la combinación de objetos. Para la segunda forma de comprensión, es muy similar al principio de diseño de "la combinación es mejor que la herencia", que reemplaza las relaciones de herencia con relaciones de composición para evitar una explosión exponencial de la jerarquía de herencia.