----- el día siguiente -----
————————————
¿Cuáles son los roles principales incluidos en el patrón de decorador?
1. Interfaz de componentes
En nuestro ejemplo anterior, la interfaz del componente es equivalente a la interfaz del automóvil, y todas las clases empaquetadas y las clases de empaquetado heredan de esta interfaz.
2. Clase ConcreteComponent
La clase ConcreteComponent es la clase de implementación empaquetada. En el ejemplo, Mercedes-Benz, BMW y Tesla pertenecen a este rol.
3. Clase abstracta de decorador
Todas las clases de empaquetado heredan de la clase abstracta Decorator, y la clase Decorator implementa la interfaz Component. Esto se hace para lograr un empaquetado anidado multicapa.
. 4 . Cemento la clase Decorator
La categoría de embalaje específica se utiliza para ampliar las funciones de la categoría de embalaje, como la función de piloto automático y la extensión de la función de vuelo en el ejemplo.
¿Cuál es la relación entre estos cuatro roles centrales? Podemos usar el diagrama de clases UML del patrón decorador para expresar:
La primera es la interfaz del automóvil, que es el papel de Component, que define el comportamiento de ejecutar:
public interface Car {
void run();
}
A continuación, se encuentra la clase de implementación de varios coches, es decir, el rol ConcreteComponent. Los distintos coches tienen diferentes implementaciones de comportamiento de ejecución:
public class BenzCar implements Car{
@Override
public void run() {
System.out.println("奔驰开车了！");
}
}
public class BmwCar implements Car{
@Override
public void run() {
System.out.println("宝马开车了！");
}
}
public class TeslaCar implements Car{
@Override
public void run() {
System.out.println("特斯拉开车了！");
}
}
La siguiente es la clase abstracta del decorador, que es el rol Decorador, que contiene los objetos miembros que se decorarán:
public class CarDecorator implements Car {
protected Car decoratedCar;
public CarDecorator(Car decoratedCar){
this.decoratedCar = decoratedCar;
}
public void run(){
decoratedCar.run();
}
}
ds puede resultar extraño para algunas personas, ¿por qué la clase decoradora debería implementar la interfaz Car? Ésta es la flexibilidad del patrón del decorador.
Heredado de la interfaz Car, cada decorador en sí mismo también puede ser envuelto por un decorador más externo. La forma de empaquetar es pasar el objeto Car como parámetro al constructor del decorador externo.
La siguiente es la clase de implementación del decorador de concreto, que es el rol de ConcreteDecorator. Estos decoradores también implementan el comportamiento de ejecución. Por un lado, se llama al método de ejecución del objeto envuelto y, por otro lado, se realizan algunas operaciones extendidas (como piloto automático, vuelo):
public class AutoCarDecorator extends CarDecorator { public AutoCarDecorator(Car decoratedCar){ super(decoratedCar); } @Override public void run(){ decoratedCar.run(); autoRun(); } private void autoRun(){ System.out.println("开启自动驾驶"); }} public class FlyCarDecorator extends CarDecorator { public FlyCarDecorator(Car decoratedCar){ super(decoratedCar); } @Override public void run(){ decoratedCar.run(); fly(); } private void fly(){ System.out.println("开启飞行汽车模式"); } }
Finalmente, nuestra clase de cliente. La clase de cliente es responsable de crear el decorador y el objeto empaquetado, y de decidir cómo empaquetar y ejecutar:
public class Client {
public static void main(String[] args) {
Car benzCar = new BenzCar();
Car bmwCar = new BmwCar();
Car teslaCar = new TeslaCar();
//创建自动驾驶的奔驰汽车
CarDecorator autoBenzCar = new AutoCarDecorator(benzCar);
//创建飞行的、自动驾驶的宝马汽车
CarDecorator flyAutoBmwCar = new FlyCarDecorator(new AutoCarDecorator(bmwCar));
benzCar.run();
bmwCar.run();
teslaCar.run();
autoBenzCar.run();
flyAutoBmwCar.run();
}
}
Tome el flujo de entrada como ejemplo. Para cumplir con diferentes escenarios de entrada, JDK ha diseñado una variedad de flujos de entrada, incluidos ByteArrayInputStream, FileInputStream, etc.
Todos estos flujos de entrada heredan de una clase abstracta común: InputStream.
Al mismo tiempo, para traer extensiones funcionales a estos flujos de entrada, JDK diseñó una clase decoradora, FilterInputStream . Esta clase hereda de InputStream y "combina" objetos miembros InputStream.
Muchas subclases de decoradores se derivan de la clase FilterInputStream, incluidas BufferedInputStream, DataInputStream, etc., que proporcionan funciones adicionales como almacenamiento en búfer de flujo de entrada y lectura de tipos de datos básicos de Java desde el flujo de entrada.
-----FIN-----