在真正的开发中，要一直保持一次只做一点改动，在改动完成之后要测试自己的改动。如果一次性的改动太大，很容易出现没有测试到的流程。并且开发中尽量保证一次的改动只需要满足当下的需求，不需要考虑的太长远而徒增复杂度。
在一次接口开发中，我们需要从外部接受消息，在系统中创建出运价。之前我们的系统中从来没有维护过类似的接口，在设计中我想的太多，每一个模块就有一个用一个interface，为了以后每一个客户都可以定制不同的逻辑。
比如通过Message生成name的逻辑，结构就是这么复杂:
public class Message {
public String a;
public String b;
}
public class Service {
public String generateName(Message message) {
return NameGeneratorFactory.getGenerator().generateName(message);
}
}
public Interface NameGenerator {
String generateName(Message message);
}
public class CustomerANameGenerator implements NameGenerator {
public String generateName(Message message) {
return message.a + message.b;
}
}
public class NameGeneratorFactory {
public static getGenerator() {
return new CustomerANameGenerator();
}
}
这样的设计导致我写了很多无用的代码，从NameGenerator开始与它相关联的一切代码都是没有用的，新建这些类本身就够花费很多时间了，而最后还是只有当时的一个客户使用了这个接口。后来在这里有逻辑改动的时候，我把这些interface全部删了，变成了这个样子:
public class Message {
public String a;
public String b;
}
public class Service {
public String generateName(Message message) {
return message.a + message.b;
}
}
从这件事开始我就再也没有过度设计代码结构，每次都只满足当时的特定需求，在每次的新需求改动中重构之前的代码，复用逻辑。
另外，从这件事中应该反思的不止是过度设计。对于一个系统来说核心的逻辑是一定的。核心逻辑应该只对外暴露一个common并且稳定的API，不同客户应该通过adapter向common的API靠拢，而不是不断的修改核心逻辑，为了适应不同客户的需求。
像这里的需求，就应该在外部消息进入系统前预先处理好Message
image.png
直接在Message中加出来name属性，后面直接使用就好
public class Message {
public String a;
public String b;
public String name;
}
