有设计模式。还有设计模式。有一些我经常使用，因为我对它们的用法和技术很清楚，比如singleton或factory模式，observator和其他一些。由于某些原因，装饰图案对我来说很难理解。我几年前在一个研讨会上知道的。但是这些年来，我没有必要使用它，因此也没有必要理解它。我试着改变这几个星期了…

我还没有完全完成它…

装饰器模式本身经常被描述，UML图主要可以在那里找到。到目前为止，我还不知道在ABAP环境中使用该模式做什么。尽管如此，我还是试着建立一个例子来理解它是如何工作的，也许有一天我能用它做些什么。但这正是我对这种模式的问题：在哪些情况下，我希望在不知道添加了某些内容的情况下将某些内容添加到类中？在大多数情况下，我有装饰需要知道至少一些关于装饰对象。这被认为是这种模式的一个缺点：装饰需要以某种方式通知装饰对象他们做了什么。在我看来，这有点奇怪：使用一些特别解耦的东西，而不是构建一些东西来再次连接？

decorator模式创建了一个层次结构，就像使用继承时得到的那样。前置对象将在实例化时传递给decorator对象，并将其存储在class属性中。这发生在每一个将要应用的新装饰者身上。

例如，在所有装饰完成后，可以通过询问最后一个装饰来查询价格。这个装饰然后问前任装饰师它的价格，加上它自己的价格，然后把结果传回来。一方面，这很好，因为您只需添加新组件，就不会对现有类产生技术影响？

在我看来，最大的缺点是，这种模式的用例非常有限。另一个明智的问题可能是关于冰淇淋的重量。这也可以很好地回答相当于如何计算价格。查询价格和重量看起来很合理，但是如果我想了解更多关于配置的信息呢？例如，有没有含有人工甜味剂的成分？我有多少勺冰淇淋？我需要一个更大的华夫饼筒吗？

如果我考虑SAP编程，我不会发现decorator模式有帮助。在他的博客上有一个Naimesh Patel的例子，但在我看来它不是装饰者。模式本身当然是decorator模式，但是用例并不真正适合。为什么我要使用像decorator这样的非常复杂的模式来产生不同的输出？

关于如何使用装饰器，有很多例子。大多数人喜欢：

煮咖啡装饰披萨卖冰激凌（见上图）

为了事后得到一个总价。

保罗·哈代（Paul Hardy）已经在2013年写了一篇关于装饰酒店的文章，但我没能重新编写他的例子。此外，这是一个在SAP系统中找不到的例子。

在他的主页上，Philipp Hauer还非常详细地描述了decorator模式，高返利页游，但又是虚构的例子……关于该模式的非常详细的信息也可以在本页上找到：配置pizza.

我总是使用某种结构化表来做一些事情，因为为这些选项创建类并不常见。有一个例子

由于缺乏一个更好的SAP世界的例子，我决定使用汽车，因为这是大多数人都知道的事情。汽车是很常见的，服务器云，每个人都知道一些特殊的选择汽车有。所以呢我决定用一些选择来装饰一辆车。在一个充满新事物的世界里，移动物联网卡，至少有一件众所周知的事情，这样就更容易理解了。希望。

类

在我的示例程序中有一个基本的模型类（"basic"），还有一些选项类：

option\u multimedia选项\u自动选项\u金属option\u rallye

当然有定义为抽象的主装饰器类"option"，因为这个类本身不会被使用。

类"basic"将从"option"派生"Basic"是保存基本车型的主类。

装饰器类"option\u decorator"也将派生自抽象的"option"类，点云，但具有装饰器模式的主要特征：一个私有属性用于保存前一个选项。

方法

选项类中有两个方法：

get\u priceget\u configuration

get\u price会询问前置机的价格并添加自己的价格。选项本身的价格在构造函数中定义。

方法get\u configuration向前一个请求其配置，并将其自身的配置（名称）附加到返回表。

程序

报告有四个复选框，分别对应四个选项中的一个。执行beeing时，将创建主对象："basic"类。对于每个选定的选项，将创建相应的类。前置对象（如果是第一个选项，则前置对象是基本模型），将作为构造函数的导入参数传递。

改进

我做了一些改进，我只是想提一下，但由于太复杂，所以不会发布。

第一次升级：decorator模式本身有一个我非常不喜欢的怪癖：通过传递当前对象创建一个对象，然后覆盖当前对象我觉得很奇怪。所以我试着在助手类中隐藏它。