作者：京東保險 王奕龍

本文主要給大家分享軟件設(shè)計中的兩個理念，為什么我稱軟件設(shè)計是“理念”而不是“方法”或“原則”呢？這個想法主要受《A philosophy of software design》的影響，它將軟件設(shè)計稱為“哲學(xué)”，而哲學(xué)本身沒有嚴格的定論，同樣地，我覺得軟件設(shè)計是每個開發(fā)者的理念，相同功能的迭代，往往會有不同的看法或思想，也所謂每個人的代碼風(fēng)格，所以本次分享不求同，只求能給大家?guī)硪稽c啟發(fā)。兩個理念如下：

沒有一蹴而就的設(shè)計：軟件設(shè)計不會停止，需要隨著功能迭代（增量開發(fā)）更新現(xiàn)有設(shè)計，因為在迭代過程中相關(guān)開發(fā)、業(yè)務(wù)經(jīng)驗不斷累積，必然會產(chǎn)生更好的設(shè)計方式，最初的設(shè)計通常不是最好的

堅持“深”模塊設(shè)計：“深”這個觀點來自 《A philosophy of software design》，它將每個模塊看作一個矩形，如下圖所示：

矩形的面積代表模塊提供的功能，頂部邊緣代表模塊公開出的接口，邊緣長度代表接口的復(fù)雜性，越長接口越復(fù)雜。設(shè)計較好的模塊比較深，因為它在簡單的接口后隱藏了許多功能，其內(nèi)部的復(fù)雜性只有一小部分對開發(fā)者可見。堅持深模塊設(shè)計也就意味著提供調(diào)用簡單但功能強大的接口。

這兩個理念，我想通過實際的業(yè)務(wù)開發(fā)：延保補購功能迭代來敘述，在開始之前我想先給大家簡單介紹一下什么是延保的補購：

延保補購是購買商品時未購買延保，事后再為該商品購買延保的行為。比如雙十一購買了一部手機，期望能用五年，但是下單時，沒有一起購買延保，之后再去補購 “五年只換不修” 的延保便是延保的補購。

目前在京東商城“延保服務(wù)”頻道頁能進行補購，大家可以在商城搜索 “延保”點擊“京東延保”跳轉(zhuǎn)：

業(yè)務(wù)邏輯介紹

為方便大家理解，我將其中的邏輯做了一些簡化，在查詢用戶可補購的訂單時，它會執(zhí)行如下邏輯：

/** * AddBuy 作為補購的代碼命名定義，定義補購相關(guān)門面接口 */ public class AddBuyFacadeServiceImpl implements AddBuyFacadeService { // 補購相關(guān)訂單查詢 Service @Resource private AddBuyOrderQueryService orderQueryService; // 補購相關(guān)延保查詢 Service @Resource private AddBuyYbQueryService ybQueryService; // 延保結(jié)果構(gòu)建 Service @Resource private AddBuyBuildService buildService; /** * 查詢多條可補購延保的訂單信息 */ @Override public List queryList(AddBuyListRequest req) { // 1. 查詢主商品訂單 OrderInfoRequest orderInfoRequest = new OrderInfoRequest(); orderInfoRequest.setUserNo(req.getUserNo()); // ... List orderInfoList = orderQueryService.listOrderInfo(orderInfoRequest); // 2. 查詢這些訂單可購買的延保信息 YbInfoRequest ybInfoRequest = new YbInfoRequest(); ybInfoRequest.setUserNo(req.getUserNo()); // ... // key: orderNo value: ybInfoList Map> orderNoYbListMap = ybQueryService.listYbInfo(ybInfoRequest); // 3. 封裝訂單和推薦延保信息 return buildService.buildRecommendInfo(orderInfoList, orderNoYbListMap); } }

執(zhí)行步驟如下：

先查詢主商品訂單

查詢這些訂單可購買的延保信息

封裝訂單和推薦延保信息

補購功能會被推廣到很多不同的 渠道 使用，渠道指的是補購功能推廣的范圍，包括微信（WEI_XIN）和PLUS客服推廣（PLUS）等等：

這個渠道值會在查詢做標記，如下所示為補購查詢請求對象 AddBuyListRequest：

public class AddBuyListRequest { private String userNo; // 渠道值信息 private String channel; // ... }

功能迭代

初期功能并沒有針對渠道參數(shù)做校驗和管理，也就是說前端傳什么后端就接什么，導(dǎo)致出現(xiàn)了異常的XXX未知渠道。為了對渠道進行管控，并根據(jù)現(xiàn)有渠道做個性化補購，現(xiàn)在便需要在此基礎(chǔ)上迭代“渠道管控”的功能：

渠道值校驗：校驗未知的渠道值，對現(xiàn)有渠道進行管理

個性化補購：指定渠道查詢 固定品類 的延保等定制化邏輯，比如規(guī)定渠道 “PLUS” 渠道只能查詢 “手機” 品類的延保

為滿足功能，首先定義 ChannelConfig 渠道配置類，其中包含如下字段：

public class ChannelConfig { /** * 渠道 */ private String channel; /** * 要查詢的主品一級類目編碼 */ private List mainFirstCategoryCodeList; // ... }

初版設(shè)計

初版設(shè)計時，定義 channelConfigMap 以 key: channel value: config 的形式維護所有渠道值，在方法 queryList 執(zhí)行時，會先校驗渠道的存在，存在的話繼續(xù)執(zhí)行邏輯，并把 config 對象 透傳 到各個查詢方法中，以執(zhí)行篩選指定品類等定制化邏輯，如下：

在方法 queryList 中，可以發(fā)現(xiàn)渠道配置幾乎 貫穿了接口邏輯執(zhí)行的始終，雖然對該方法的改動并不大，但對于其中的查詢方法 listOrderInfo 和 listYbInfo 來說，會使它們的方法復(fù)用變得困難。

如果想復(fù)用其中查詢訂單的接口（其中第 1 步邏輯）：

List listOrderInfo(OrderInfoRequest orderInfoRequest, ChannelConfig config);

在構(gòu)建查詢?nèi)雲(yún)⒌臅r候就難免不對渠道配置 ChannelConfig config 參數(shù)產(chǎn)生疑問：“這個入?yún)⒌淖饔檬鞘裁础保奎c進去看它的字段：如果發(fā)現(xiàn)有很多字段，那么開發(fā)者大概率不會去了解每個字段的含義，并且也沒辦法記住這么多字段的作用是什么，這就會導(dǎo)致開發(fā)者直接去看 listOrderInfo 方法的實現(xiàn)，分析其中哪些字段是有用的，哪些是沒用的。這使得一件本可以簡單查看方法入?yún)?OrderInfoRequest 便能復(fù)用該方法的事情變得異常復(fù)雜，需要了解太多查詢訂單信息之外的知識，大大增加了認知負荷。

從本質(zhì)上去考慮：“在調(diào)用查詢訂單接口時，我們需要了解‘渠道配置’相關(guān)的內(nèi)容嗎？”，顯然是不需要的，否則為通用查詢接口帶來的復(fù)雜性就太高了，進而使得接口變“淺”。

那么該如何避免這些問題呢？最初我想到兩種簡單的辦法：

詳細的配置注釋：將配置的每個字段描述的足夠清楚，那么使用該接口的研發(fā)人員不需要去了解代碼實現(xiàn)便能知道根據(jù)渠道如何添加一個合適的配置入?yún)?/p>

查詢方法實現(xiàn)中添加配置默認值兜底：解決調(diào)用者不傳該參數(shù)或者某些字段為空的特殊情況，降低復(fù)用難度
但是這樣并不解決根本問題，入?yún)⒅邪琅渲靡廊粫┞镀鋷淼膹?fù)雜性。如果開發(fā)者要復(fù)用該 listOrderInfo 方法并篩選特定品類的訂單，那么需要寫如下邏輯：

/** * 復(fù)用 listOrderInfo 方法樣例 */ public void reuseExample(Request req) { OrderInfoRequest orderInfoRequest = new OrderInfoRequest(); orderInfoRequest.setUserNo(req.getUserNo()); ChannelConfig config = new ChannelConfig(); // 賦值指定的品類編碼 config.setMainFirstCategoryCodeList(Collections.singleton("1234")); List orderInfoList = orderQueryService.listOrderInfo(orderInfoRequest, config); // ... }

一旦篩選條件中涉及渠道配置中的字段，都要創(chuàng)建一個渠道配置 ChannelConfig 對象，都要去了解這個類中定義了哪些字段。

這時候我就在想，那么為何不將渠道配置 ChannelConfig 中的字段都提出來放到另一個參數(shù) OrderInfoRequest 中呢？那么這樣在入?yún)⒅斜隳懿辉賯魅肭琅渲昧耍缦滤荆?/p>

這樣當開發(fā)者復(fù)用 listOrderInfo 方法時，只需關(guān)注 OrderInfoRequest 對象并為相關(guān)字段賦值即可，這樣通用的訂單查詢接口便無需再關(guān)注渠道配置相關(guān)的內(nèi)容了。

但是到這里還沒完，有一點值得考慮：渠道配置信息 ChannelConfig 作為 不可變的對象，并不應(yīng)該被公開出來，而且在一般情況下，開發(fā)者會習(xí)慣使用 Lombok 的注解 @Data 為類做標注，如下：

@Data public class ChannelConfig { // ... }

這樣它每個字段的寫（set）操作都是公開（public）的，一旦對原本不可變的數(shù)據(jù)進行修改，那么因此產(chǎn)生的問題將非常難排查。相對應(yīng)地，在《重構(gòu)》一書中，提到過類似觀點：“對于所有可變的數(shù)據(jù)，只要它的作用域超出單個方法，我就會將其封裝起來，只允許通過方法訪問，數(shù)據(jù)的作用域越大，封裝就越重要，因為這樣能夠很清楚的知道哪些地方讀了這些數(shù)據(jù)或?qū)懥诉@些數(shù)據(jù)，如果我們想避免其他開發(fā)者修改這個對象的話，那么就可以不公開出 set 方法”。

對 @Data 的觀點：@Data 注解實際上有些被濫用，在面向?qū)ο蟮拈_發(fā)中，通常我們都會把類內(nèi)字段聲明為 private，但是又在類上標記 @Data 注解，為每個字段生成 Getter 和 Setter 方法，使得 private 失效。雖然多數(shù)時候并不會引發(fā)問題，但是更好的做法應(yīng)該是針對字段指定 Getter 和 Setter 方法，而不是泛泛的生成全部，特別是如果要定義某些不可變的字段時，要尤為注意。此外，當整個對象都不可變時，每次獲取該對象時返回它的深拷貝也是很有必要的，否則其被修改后，引發(fā)的線上問題非常難定位和排查，這個對象被使用的越多，則越需要警惕。

所以，我們需要將渠道配置對象隱藏起來。

信息隱藏

為了不暴露 ChannelConfig 對象，定義渠道配置服務(wù) ChannelConfigService，并提供校驗渠道的方法，如下：

public interface ChannelConfigService { /** * 校驗渠道是否存在，否則拋出異常 * * @throws ChannelNotExistException 渠道不存在異常 */ void checkChannelExist(String channel) throws ChannelNotExistException; // ... } @Service public class ChannelConfigServiceImpl implements ChannelConfigService { /** * 渠道配置 key: channel value: config */ private HashMap channelConfigMap; @Override public void checkChannelExist(String channel) throws ChannelNotExistException { if (StringUtils.isBlank(channel) || !channelConfigMap.containsKey(channel)) { throw new ChannelNotExistException("渠道: " + req.getChannel() + " 不存在"); } } }

這樣將保存渠道配置的 Map channelConfigMap 就下沉到了 ChannelConfigServiceImpl 實現(xiàn)中，queryList 方法中將不再暴露 ChannelConfig 對象，校驗渠道值邊以方法的形式，如下：

同樣地，封裝品類查詢條件等與配置相關(guān)的邏輯也需要被隱藏起來，因為已經(jīng)沒有渠道配置 config對象了，那么這部分該如何處理呢？

我是這樣做的：在渠道配置服務(wù)中 ChannelConfigService 定義獲取品類配置的方法 getMainFirstCategoryCodeList，這樣便無需公開渠道配置對象了：

public interface ChannelConfigService { /** * 獲取主品類目編碼配置，默認值為空列表對象 */ List getMainFirstCategoryCodeList(String channel); // ... } @Service public class ChannelConfigServiceImpl implements ChannelConfigService { /** * 渠道配置 key: channel value: config */ private HashMap channelConfigMap; // ... @Override public List getMainFirstCategoryCodeList(String channel) { ChannelConfig config = channelConfigMap.get(channel); // 默認返回空 List if (config == null || CollectionUtils.isEmpty(config.getMainFirstCategoryCodeList())) { return Collections.emptyList(); } return Collections.unmodifiableList(config.getMainFirstCategoryCodeList()); } }

開發(fā)者只需根據(jù)接口公開出的方法來獲取相應(yīng)的配置信息即可，并不需要對渠道配置對象 ChannelConfig 做了解，改動如下：

做過頭了

還有一種方式是將渠道配置服務(wù) ChannelConfigService 注入到訂單查詢服務(wù) AddBuyOrderQueryService 中，并添加渠道配置相關(guān)的處理邏輯：

@Service public class AddBuyOrderQueryServiceImpl implements AddBuyOrderQueryService { @Resource private ChannelConfigService configService; @Override public List listOrderInfo(OrderInfoRequest orderInfoRequest) { // ... // 過濾一級品類，如果沒有指定則取渠道配置的一級品類配置 List firstCategoryCodeList; if (CollectionUtils.isNotEmpty(orderInfoRequest.getMainFirstCategoryCodeList())) { firstCategoryCodeList = orderInfoRequest.getMainFirstCategoryCodeList(); } else { firstCategoryCodeList = configService.getMainFirstCategoryCodeList(orderInfoRequest.getChannel()); } processMainFistCategory(firstCategoryCodeList); // ... } }

雖然這樣做將渠道配置相關(guān)信息隱藏得更深，幾乎不暴露到補購查詢 queryList 邏輯中，如下：

但是有一個問題需要考慮：訂單查詢接口屬于通用查詢接口，將渠道配置服務(wù) ChannelConfigService 下沉到其中，便使訂單和渠道的知識發(fā)生耦合，并且在邏輯中存在依賴，渠道配置的改動可能會影響通用的訂單查詢。這樣做，可能就有些過頭了。

擴展性設(shè)計對復(fù)雜度的管理

隨著業(yè)務(wù)發(fā)展，有新的服務(wù)方提供延保的查詢服務(wù)（對應(yīng)代碼中步驟 2），這些服務(wù)需要接入現(xiàn)有補購邏輯中，并根據(jù)渠道的不同，查詢不同的延保服務(wù)。

這是非常典型的策略模式應(yīng)用場景，原有延保查詢服務(wù)和新增的延保查詢服務(wù)都將作為不同的策略來實現(xiàn)。借助策略模式實現(xiàn)擴展性并不困難，常見的有兩種實現(xiàn)方法，但是它們對策略帶來的復(fù)雜性處理是不同的：

第一種保持延保查詢服務(wù) AddBuyYbQueryService 公開的方法不變，使用靜態(tài)代理模式在其實現(xiàn)中 AddBuyYbQueryServiceImpl 借助 HashMap 保存所有策略，并根據(jù)渠道的不同執(zhí)行不同的策略：

public interface AddBuyYbQueryService { Map> listYbInfo(YbInfoRequest ybInfoRequest); } /** * 實現(xiàn) ApplicationContextAware 用于注入 ApplicationContext 獲取想要的策略（Bean） * 實現(xiàn) InitializingBean 用于在應(yīng)用啟動時，根據(jù)策略類型 AddBuyYbQueryStrategy 加載所有的策略 */ @Service public class AddBuyYbQueryServiceImpl implements AddBuyYbQueryService, ApplicationContextAware, InitializingBean { private ApplicationContext applicationContext; private HashMap nameServiceMap; // 渠道配置 Service @Resource private ChannelConfigService configService; @Override public Map> listYbInfo(YbInfoRequest ybInfoRequest) { String ybType = configService.getYbType(ybInfoRequest.getChannel()); // 通過定義枚舉實現(xiàn) ybType 與具體策略實現(xiàn)的關(guān)聯(lián) YbQueryStrategyEnum strategyEnum = YbQueryStrategyEnum.parseByType(ybType); AddBuyYbQueryStrategy ybQueryStrategy = nameServiceMap.get(strategyEnum.getQueryServiceName()); return ybQueryStrategy.listYbInfo(ybInfoRequest); } @Override public void afterPropertiesSet() { nameServiceMap = new HashMap(); nameServiceMap.putAll(applicationContext.getBeansOfType(AddBuyYbQueryStrategy.class)); } @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } }

策略 AddBuyYbQueryStrategy 接口方法簽名與延保查詢服務(wù) AddBuyYbQueryService 中方法簽名一致，它們的類關(guān)系圖如下所示：

延保查詢服務(wù) AddBuyYbQueryService 的 listYbInfo 方法不變，那么 原方法 queryList 邏輯也不需要改變，這樣便將策略帶來的復(fù)雜度隱藏了起來。

第二種是創(chuàng)建策略上下文 AddBuyYbQueryStrategyContext，將對應(yīng)的策略管理起來并通過調(diào)用 getSpecificStrategy 直接暴露具體的策略，如下：

public interface AddBuyYbQueryStrategyContext { AddBuyYbQueryStrategy getSpecificStrategy(YbInfoRequest ybInfoRequest); }

那么這樣對原方法的改動如下：

這樣會將使用策略模式的復(fù)雜度暴露到原方法 queryList 中，實際上開發(fā)者在這個方法中不需要了解策略該如何分配等相關(guān)邏輯。

封裝推薦延保信息的邏輯（其中第 3 步）由于引入了不同類型的延保服務(wù)，也需要根據(jù)不同的延保對象類型適配相應(yīng)的策略，同樣需要使用策略模式，但實現(xiàn)邏輯類似，不再贅述，不過不同點是該步驟一并使用了模板方法模式：

封裝訂單和推薦延保信息的 buildRecommendInfo 方法主要步驟為封裝訂單信息（initialMainOrderInfo）和封裝推薦的延保信息（initialRecommendYbInfo），其中封裝訂單信息的邏輯是通用的，而封裝推薦的延保信息步驟需要分別處理不同的延保類型，所以借助了模板方法模式。將后者其定義為抽象方法，由子類不同的策略去分別實現(xiàn)，抽象模板類如下：

public abstract class AbstractAddBuyBuildService implements AddBuyBuildStrategy { @Override public List buildRecommendInfo(List orderInfoList, Map> orderNoYbListMap) { List res = new ArrayList(orderNoYbListMap.size()); // Group By OrderNo Map orderNoOrderInfoMap = orderInfoList.stream().collect(Collectors.toMap(OrderInfo::getOrderid, x -> x)); // orderNoBindListEntry: (key: 訂單號；value: 訂單對應(yīng)的延保信息) for (Map.Entry> orderNoYbListEntry : orderNoYbListMap.entrySet()) { // 訂單信息 OrderInfo orderInfo = orderNoOrderInfoMap.get(orderNoYbListEntry.getKey()); // 延保信息 List ybList = orderNoYbListEntry.getValue(); AddBuyResult element = new AddBuyResult(); // 1. 封裝訂單信息 MainOrderInfo mainOrderInfo = initialMainOrderInfo(orderInfo); element.setMainOrderInfo(mainOrderInfo); // 2. 封裝推薦的延保信息 List recommendYbInfo = initialRecommendYbInfo(ybList); element.setRecommendYbInfoList(recommendYbInfo); res.add(element); } return res; } // 封裝訂單信息作為私有方法，被各個不同的策略復(fù)用 private MainOrderInfo initialMainOrderInfo(OrderInfo orderInfo) { // ... } // 抽象初始化推薦延保的方法，用于子類實現(xiàn)不同的策略 protected abstract List initialRecommendYbInfo(List ybList); }

類關(guān)系圖如下：

這樣便能實現(xiàn)通用邏輯的復(fù)用。使用模板方法模式并不復(fù)雜，實現(xiàn)這種模式需要借助繼承（extends），而繼承在設(shè)計原則中被強調(diào)“少用繼承，多用組合”，而且在一些軟件設(shè)計相關(guān)的書中也會經(jīng)常看到對繼承的詬病，比如在《程序員修煉之道》中便將其稱為“繼承稅”，并且舉了一個非常好玩的例子：

你想要一根香蕉，但得到的卻是一只拿著香蕉的大猩猩，甚至還有整個森林

其表達的意思也不難理解：強調(diào)繼承使父類中的大量信息發(fā)生泄露，讓維護在每個類中的知識在繼承關(guān)系之間 “波動”，暴露了太多的知識出來，做不到抽象和信息隱藏。一方面會使子類獲得太多無關(guān)的知識，另一方面如果在子類中大量使用這些通用的部分，便會使得耦合加深，父類中信息變更可能為子類帶來意想不到的后果。

以如上繼承關(guān)系為例，如果父類中某些內(nèi)容發(fā)生變更，子類中對其使用的話，那么可能會引起子類行為的改變，而如果這種改變并不引起編譯期異常的話，便很難發(fā)現(xiàn)，使得代碼的可維護性大大降低。那么不用繼承該怎么辦呢？常見的觀點有兩個：

使用接口實現(xiàn)來代替類的繼承，保證多態(tài)又不會造成信息的緊耦合

使用組合代替繼承：比如想要香蕉，那么直接將包含香蕉的類注入進來，不再通過繼承去獲取了

但是，我覺得繼承也并不能被一票否決，在 Java 源碼中常用容器的實現(xiàn)里，都是有抽象層的（AbstractList, AbstractMap 等等），通過繼承它們，實現(xiàn)了大量代碼復(fù)用，為各種不同容器的實現(xiàn)提供了很多方便之處。所以，我覺得繼承能被應(yīng)用需要具備以下前提條件：

保持不變性：父類中抽象出來的供復(fù)用的通用方法、字段保持不變

控制繼承樹的高度：繼承樹高度越高引入的復(fù)雜度越大，所以需要控制樹高，限制一層繼承關(guān)系，那么復(fù)雜度便可控

總結(jié)

我覺得軟件設(shè)計更應(yīng)該站在代碼閱讀者的角度上，考慮如何降低復(fù)雜度，設(shè)計更深的模塊，并隨著功能迭代，不斷更新現(xiàn)有設(shè)計，而并不是將注意力放在如何改動更簡單上，代碼的堆疊可能會導(dǎo)致復(fù)雜性不斷累積，以至于在不能滿足業(yè)務(wù)功能迭代時，花更多的時間去重構(gòu)。

審核編輯 黃宇