复杂还是不复杂？

ResponseManipulator是原来就存在的，那么为什么会有这个机制呢？你确定你现在的情况不属于ResponseManipulator原来设计要处理的问题吗？

Manipulator在我看来本来就是个过度设计。

它的用法一直都是：

void f(){
  ...
  response = getManipulator().manipulate(response);
  ...
}
ResponseManipulator getManipulator(){
  return new ChainManipulator(new ResponseManipulator[]{
    new Manipulator1(), new Manipulator2()
  });
}

而这个设计相比于下面的代码好处非常有限：

void f(){
  ...
  response = manipulate(response);
  ...
}
Response manipulate(Response response){
  response = Manipulator1.doSomething(response);
  response = Manipulator2.doSomethingElse(response);
}

就为了节省敲“manipulate(response)”在我看来不是一个引入一个接口和ChainManipulator的理由。

感觉说得很好，这才是真正的理由！

The original design is very sound. Don't see this kind of coding often.

The original design fits the open-close principle.

The design is just a template pattern, as those interceptors in web apps, in a chain. It's a post processing of a complex method.

The very naive, and commonly seen,  way to implement is through nested if-else blocks. This completely violates the OO principles.

The root reason is to make maintenance simple. If we started from nested if-else, when we add more if-else blocks, it's just so easy to break existing logic(especially those if-without-else blocks because they have implicit no-code default behaviors). One way to replace them is using interceptors. The interceptors, in a certain degree confine the individual post processing to their own classes so that we can change them independently.

In general, if we have less than 3(the magic number 3) postprocessings, we could hardcode them. But if there are 3 or more similar code patterns then we should definitely avoid it.

The nice thing about this design is that when you add even a simple requirement like this, you touch minimal original code(only the hook portion), plus the new code. A simple requirement is simple, but not 10 simple requirements, not when they interact each other, not when you need to apply them in 10 different places, not when they have heavy dependencies, not when 15 of them combines together.

If you think this is simple, it's because you are benefiting from the sound design. What if you are in a 15-level if-else block and you need to add another if-else there?

Even for a simple salary calculation, there could be many postprocessings, truncate to unit, currency conversion, add bonus, minus stock options, minus health insurrance, pay income tax, etc.

Even we use OO, this is still tough. First, there is an order in the sequence of postprocessings, who does first. For instance, health insurrance should be before income tax because it's "before tax". Then, there could be combination effect, e.g., you can't combine certain set of them. This makes testing very tedious because you need to test all combinations, make sure you get correct results or exceptions

OO is not just a textbook concept, it simplifies coding *and* maintenance. If you think it's overengineering, try inline them to see whether it's good or not. In this case, if you don't follow the original design, then what do you think the guy after you says?

There are several improvements to this design as well. If the creation of these postprocessors is complex, e.g., they have very heavy dependencies, then use a factory dedicated to the creation so that the dependencies won't spread everywhere(Spring is a nice candidate). Furthermore, the interface can be improved too, have two more methods:
initWith(response) - where we get values from response and inject all other dependencies, like get exchange rate for currencies.
isApplicable() - use the above method to determine whether we should apply this processor, based on the values from initWith() and others.

So not only this is a good approach, but we can make it more "OO", not because we like OO, instead because we want to separate things(like dependencies) out.

There are many similar examples in the real world, from web app interceptors for i18n conversion, currency conversion, validation, security, audit, logging, to simple spreadsheets(think about a data matrix as the response here and what we can do for columns and rows, scaling, number crunching, sum and %, etc)

In my experience, I had a case where I had 17 interceptors in 2 years(not knowing all of them upfront), sometimes I had only 10 minutes to add one under heavy pressure. Their combinations are very tricky, the first output(like response) could come from 3 different paths, each of them has heavy dependencies. This design stands well.

When we code, we have to think about how to maintain them. This is not college student homework, which can be thrown away after tests, :-). We may do simple things once or twice, but not more than that.

Just my experience, no point fingers.

我还是觉得简单地直接写出来比较好，容易理解，容易调试，效率似乎也更高。

题外话：看到过有一些component的所谓“data-driven”把什么都写到XML里面，最后XML里面可以配置Condition, And, Or, Not，Op，感觉就是在用XML写代码。写起来不方便不说，调试起来更是累人。

MyResponse runService()现在的实现逻辑是：
1. 调用Web Service得到MyResponse
2. 对MyResponse做一系列后续处理

如果后续处理是可能发生变化的，那么你pair的方案就灵活了，但不要自己查找ResponseMinipulator，而是DI进来，由组装代码负责这个变化。

如果后续处理是一定的，那么hardcode更直观和简洁。

这话正点。如果manipulator是注射进来的话，我一点意见没有。

问题是绕了半天还要直接new出来，一点灵活性也没得到。这就像要计算1+2+3，不直接写，非要写成一个数组加循环：

int[] arr = {1，2，3}；
int sum = 0;
for(int i=0; i<arr.length; i++){
  sum += arr[i];
}

这循环的好处是被计算的数据可以动态决定。可是如果你的数据本身是静态写死的，那么就不如直接1+2+3。

这里需要区分是概念和实现。 我们所采取的办法是保持很直接很方便的方式直接调用实现代码，在需要的时候为实现代码增加概念包装类。实际上如果在系统架构上不存在通用的Manipulator的支持（例如动态配置，管理等），采用chain结构等并不是什么好主意。 很多情况下我们需要的是统一实现而不是概念依赖。

没有一定之规