Descripción general
Al comunicarse con el subsistema interno, debe llevarse a cabo a través de un objeto de modo de apariencia unificado, que es el modo de apariencia, también conocido como el modo de apariencia. En términos generales, el patrón de fachada es reducir la dependencia entre el cliente y la capa de implementación. El propósito del modo de apariencia es proporcionar un canal de comunicación centralizado y simplificado para el subsistema.
Diagrama de clase UML
En el diagrama UML anterior, aparecen tres caracteres:
Rol de cliente: el usuario llama a la clase de patrón de apariencia a través del cliente para operar el subsistema;
Fachada: el cliente puede llamar a esta clase, que contiene las funciones específicas en el subsistema de llamadas;
Rol de subsistema (módulo): define funciones individuales específicas en el subsistema;
Ejemplo de código:
Entrevista al paquete; clase Modulea {public void testa () {System.out.println ("Método en Modulea"); }} clase ModuleB {public void testb () {System.out.println ("Método en ModuleB"); }} class Modulec {public void testC () {System.out.println ("Método en Modulec"); }} class fachade {public void testa () {modulea modulea = new Modulea (); modulea.testa (); } public void testb () {ModuleB ModuleB = new ModuleB (); MODULEB.TESTB (); } public void testC () {modulec modulec = new Modulec (); modulec.testc (); }} public class Mantest {public static void main (string arg []) {fachade fachade = new fachade (); fachade.testa (); fachade.testb (); fachade.testc (); }} En el código anterior, la clase de fachada actúa como la interfaz de apariencia de los módulos Modulea, ModuleB y Modulec. A través de esta clase, el cliente no necesita llamar al módulo ABC del subsistema en persona, ni necesita conocer los detalles dentro del sistema, lo que implementa mejor el desacoplamiento entre el cliente y el sistema.
Al mismo tiempo, utilizando el modo de apariencia, el método puede estar expuesto opcionalmente. Los métodos definidos en un módulo se pueden dividir en dos partes, en parte para su uso fuera del subsistema, y en parte cuando los módulos dentro del subsistema se llaman entre sí.
Ventajas del modo de apariencia
El patrón de apariencia afloja la relación de acoplamiento entre el cliente y el subsistema, lo que hace que sea más fácil expandir y mantener módulos dentro del subsistema.
Hacer el subsistema más fácil de usar. Los clientes ya no necesitan comprender la implementación del subsistema, ni necesitan interactuar con muchos módulos internos del subsistema. Solo necesitan interactuar con clases de apariencia.
Puede ayudarnos a dividir mejor los niveles de acceso. Algunos métodos están fuera del sistema, mientras que otros se usan internamente. Concentre las funciones que deben expuestas al exterior en la tienda, lo que no solo es conveniente para que el cliente lo use, sino que también oculta bien los detalles internos.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.