在真正的開(kāi)發(fā)中，要一直保持一次只做一點(diǎn)改動(dòng)，在改動(dòng)完成之后要測(cè)試自己的改動(dòng)。如果一次性的改動(dòng)太大，很容易出現(xiàn)沒(méi)有測(cè)試到的流程。并且開(kāi)發(fā)中盡量保證一次的改動(dòng)只需要滿足當(dāng)下的需求，不需要考慮的太長(zhǎng)遠(yuǎn)而徒增復(fù)雜度。

在一次接口開(kāi)發(fā)中，我們需要從外部接受消息，在系統(tǒng)中創(chuàng)建出運(yùn)價(jià)。之前我們的系統(tǒng)中從來(lái)沒(méi)有維護(hù)過(guò)類似的接口，在設(shè)計(jì)中我想的太多，每一個(gè)模塊就有一個(gè)用一個(gè)interface，為了以后每一個(gè)客戶都可以定制不同的邏輯。
比如通過(guò)Message生成name的邏輯，結(jié)構(gòu)就是這么復(fù)雜:

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();
    }
}

這樣的設(shè)計(jì)導(dǎo)致我寫了很多無(wú)用的代碼，從NameGenerator開(kāi)始與它相關(guān)聯(lián)的一切代碼都是沒(méi)有用的，新建這些類本身就夠花費(fèi)很多時(shí)間了，而最后還是只有當(dāng)時(shí)的一個(gè)客戶使用了這個(gè)接口。后來(lái)在這里有邏輯改動(dòng)的時(shí)候，我把這些interface全部刪了，變成了這個(gè)樣子:

public class Message {
    public String a;
    public String b;
}

public class Service {
    public String generateName(Message message) {
        return message.a + message.b;
    }
}

從這件事開(kāi)始我就再也沒(méi)有過(guò)度設(shè)計(jì)代碼結(jié)構(gòu)，每次都只滿足當(dāng)時(shí)的特定需求，在每次的新需求改動(dòng)中重構(gòu)之前的代碼，復(fù)用邏輯。

另外，從這件事中應(yīng)該反思的不止是過(guò)度設(shè)計(jì)。對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō)核心的邏輯是一定的。核心邏輯應(yīng)該只對(duì)外暴露一個(gè)common并且穩(wěn)定的API，不同客戶應(yīng)該通過(guò)adapter向common的API靠攏，而不是不斷的修改核心邏輯，為了適應(yīng)不同客戶的需求。

像這里的需求，就應(yīng)該在外部消息進(jìn)入系統(tǒng)前預(yù)先處理好Message

image.png

直接在Message中加出來(lái)name屬性，后面直接使用就好

public class Message {
    public String a;
    public String b;
    public String name;
}