为什么我们需要装饰器设计模式中的装饰器? [英] Why do we need the decorator in the decorator design pattern?

问题描述

假设我有一个名为 A 的类，并且我想使用装饰器设计模式.如果我错了，请纠正我，但要使其正常工作，我们需要创建一个装饰器类，例如 ADecorator，它将保存对 A 实例的引用，所有其他装饰器都会扩展它以添加功能.

Presuming I have a class named A, and I want to use the decorator design pattern. Correct me if I'm wrong, but for that to work , we'll need to create a decorator class, say ADecorator, which will hold a reference to an A instance, and all the other decorators will extend this to add functionality.

我不明白为什么我们必须创建一个装饰器类，而不是使用 A 实例?

I don't understand why do we have to create a decorator class, instead of using an A instance?

推荐答案

装饰器模式用于动态(即在运行时)向对象添加功能.通常，当您编写类时，对象将具有固定的功能.但重要的一点是对象的功能以一种对对象的客户端透明的方式扩展，因为它实现了与原始对象将责任委托给装饰对象相同的接口.

The decorator pattern is used to add capabilities to objects dynamically (that is, at run time). Normally the object will have its capabilities fixed when you write the class. But an important point is that the functionality of the object is extended in a way that is transparent to the client of the object because it implements the same interface as the original object delegates responsibility to the decorated object.

装饰器模式适用于对象可能具有许多可选功能的场景.如果没有装饰器模式，您将不得不为每个对象选项配置创建一个不同的类.一个非常有用的例子来自 O'Reilly 的 Head First Design Patterns 一书.它使用了一个听起来像星巴克的咖啡店示例.

The decorator pattern works in scenarios where there are many optional functionality that an object may have. Without the decorator pattern you will have to create a different class for each object-option configuration. One example that is pretty useful comes from the Head First Design Patterns book by O'Reilly. It uses a coffee shop example that sounds just like StarBucks.

因此，您可以使用成本等方法获得基本的咖啡.

So you have the basic coffee with a method like cost.

public double cost(){
     return 3.45;
}

然后客户可以添加成本为 0.35 的奶油，因此您现在使用成本方法创建 CoffeeCream 类:

Then the customer can add cream which costs 0.35 so you now create a CoffeeCream class with the cost method:

public double cost(){
    return 3.80;
}

那么客户可能想要价格为 0.5 的摩卡，他们可能想要加奶油的摩卡或不加奶油的摩卡.所以你创建类 CoffeeMochaCream 和 CoffeeMocha.然后客户想要双倍奶油，所以你创建了一个类 CoffeeCreamCream ......等等.你最终得到的是类爆炸.请原谅所使用的糟糕示例.有点晚了，我知道这很微不足道，但它确实表达了要点.

Then the customer may want Mocha which costs 0.5, and they may want Mocha with Cream or Mocha without Cream. So you create classes CoffeeMochaCream and CoffeeMocha. Then a customer wants double cream so you create a class CoffeeCreamCream… etc. What you end up with is class explosion. Please excuse the poor example used. It's a bit late and I know it's trivial but it does express the point.

相反，您可以使用抽象成本方法创建一个 Item 抽象类:

Instead you can create an Item abstract class with an abstract cost method:

public abstract class Item{
    public abstract double cost();
}

并且您可以创建一个扩展 Item 的具体 Coffee 类:

And you can create a concrete Coffee class that extends Item:

public class Coffee extends Item{
    public double cost(){
       return 3.45;
    }
}

然后您创建一个 CoffeeDecorator，它扩展了相同的接口并包含一个 Item.

Then you create a CoffeeDecorator that extend the same interface and contain an Item.

public abstract class CoffeeDecorator extends Item{
     private Item item;
     ...
}

然后你可以为每个选项创建具体的装饰器:

Then you can create concrete decorators for each option:

public class Mocha extends CoffeeDecorator{

   public double cost(){
     return item.cost() + 0.5;
   }

}

注意装饰器如何不关心它包装的是什么类型的对象，只要它是一个项目?它使用 item 对象的 cost() 并简单地添加它自己的成本.

Notice how the decorator does not care what type of object it is wrapping just as long as it's an Item? It uses the cost() of the item object and simply adds its own cost.

public class Cream extends CoffeeDecorator{

   public double cost(){
     return item.cost() + 0.35;
   }

}

现在可以使用以下几个类进行大量配置:例如

Now it is possible for a large number of configurations with these few classes: e.g.

 Item drink = new Cream(new Mocha(new Coffee))); //Mocha with cream

或

 Item drink = new Cream(new Mocha(new Cream(new Coffee))));//Mocha with double cream

等等.

这篇关于为什么我们需要装饰器设计模式中的装饰器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！