Question

不确定这是否是Decorator模式的理想用法。这是设置。

我有一个CommandBuilder类，其中包含一个名为build（）的操作方法。我想动态地应用这个命令：将它写入文件，将其写入stdout，将其写入日志文件。

它是这样的：

public abstract class CommandBuilder {

   public abstract String build();

}

然后我有一个具体的impl

 public class StringBuilder extends CommandBuilder {

  ...
  public String build() {
       ... builds command string ....
       return commandString;
  }
 }

抽象装饰者：

 public abstract class OutputDecorator extends CommandBuilder {
     public abstract String build();
 }

最后，装饰者自己：

 public class FileDecorator extends OutputDecorator {
      CommandBuilder builder;
      public FileDecorator(CommandBuilder builder) {
         this.builder = builder;
      }

      public String build() {
            String commandOutput = builder.build(); // call it
            ...
            someWriteClass.writeFile(commandOutput); // use it
            return commandOutput; // pass it along unchanged;
      }
 }

依旧是StandardOutputDecorator，LoggerOutputDecorator ......

然后在使用中：

 CommandBuilder mybuilder = new LoggerOutputDecator(
   new StandardOutputDecorator(
       new FileDecorator(
           new StringCommandBuilder()
           )
        )
 );
  mybuilder.build();

从而构建我的字符串命令并以各种方式输出它。

问题：由于我没有修改这些装饰器中的操作数据，而只是在将其传递给其他方法之前将其输入到未改变的状态，我是否“滥用”该模式？有没有更好的方法来实现这个？

Answer 1

它非常合适，除了OutputDecorator抽象类应该处理对CommandBuilder的引用（就像在FileDecorator中一样，不与其他装饰器共享）

Answer 2

首先，我建议您查看Bridge设计模式。您应该有一个用于处理数据的层次结构（打印到文件，控制台等），以及您的数据构建器的另一个层次结构 - 它们应该松散耦合，因为一个原因，类必须连贯和创建，作为最佳实践

此外，我们使用Decorator模式来扩展类的默认行为。你的FileDecorator，LoggerOutputDecator类有自己的责任，他们没有扩展＆＃34;装饰＆＃34;对象的默认行为。

我认为你应该有两个不同的层次结构，但是数据处理程序的层次结构不应该以数据方式实现（不要使用Decorator模式，因为它们不会装饰任何东西）。

我认为使用构建器构建数据并迭代处理程序会更清晰。应该调用每个处理程序，并且构建器构建的数据应该作为参数传递。

装饰模式与操作传递？

2 个答案: