摘要：結論二從不同的角度去看抽象一致性得出的結論是不一樣的只有最符合現有業務的沒有最正確的說明三對于實現一方法是查詢用戶的消費信息而這里的詳細計算訂單金額直接寫在這個方法里面抽象層次十分混亂所以實現一是不推薦的。

用戶實體User

通過用戶Id查找用戶的訂單信息接口List orders = orderService.queryOrders(long userId)

通過用戶Id查找用戶退款訂單Id列表List orderIds = orderRefundService.queryRefundOrderIds(long userId)

查找所有用戶的信息List users = UserService.queryAllUsers()

要求查詢用戶訂單消費總金額(除去退過款的訂單)

public List queryUserStatistics(){
    List users = UserService.queryAllUsers()
    for (User user : users) {
        long userId = user.getAccountId();
        List orders = orderService.queryOrderInfo();
        BigDecimal totlePayAmount = filterRefundOrderAndCalculateAmount(orders,accountId);
        user.setSumPayAmount(totlePayAmount);
    }
}
private BigDecimal filterRefundOrderAndCalculateAmount(List orders, long     userId) {
    List orderIds = orderRefundService.queryRefundOrderIds(userId);
    BigDecimal totlePayAmount = BigDecimal.ZERO;
    for (Order order : orders) {
        if (!orderIds.contains(order.getOrderId())) {
            totlePayAmount = totlePayAmount.add(order.getPayAmount());
        }
    }
    return totlePayAmount;
}

public List queryUserStatistics(){
    List users = UserService.queryAllUsers()
    for(User user : users){
         BigDecimal sumPayAmount = calculateTotleConsumeAmount(user);
         user.setSumPayAmount(sumPayAmount);
    }
}
private BigDecimal calculateTotleConsumeAmount(User user) {
    long userId = user.getUserId();
    List orders = orderService.queryOrderInfo(userId);
    return filterRefundOrderAndCalculateAmount(orders, userId);
}

private BigDecimal filterRefundOrderAndCalculateAmount(List orders, long     userId) {
    List orderIds = orderRefundService.queryRefundOrderIds(userId);
    BigDecimal totlePayAmount = BigDecimal.ZERO;
    for (Order order : orders) {
        if (!orderIds.contains(order.getOrderId())) {
            totlePayAmount = totlePayAmount.add(order.getPayAmount());
        }
    }
    return totlePayAmount;
}

public List queryUserStatistics(){
    List users = UserService.queryAllUsers()
    for(User user : users){
         BigDecimal sumPayAmount = calculateTotleConsumeAmount(user);
         user.setSumPayAmount(sumPayAmount);
    }
}
private BigDecimal calculateTotleConsumeAmount(User user) {
    long userId = user.getUserId();
    List orders = orderService.queryOrderInfo(userId);
    List orderIds = orderRefundService.queryRefundOrderIds(long userId);
    return filterRefundOrderAndCalculateAmount(orderPayAmountVOs, orderIds);
}

private BigDecimal filterRefundOrderAndCalculateAmount(List orders,List         orderIds) {
    BigDecimal is = BigDecimal.ZERO;
    for (Order order : orders) {
        if (!orderIds.contains(order.getOrderId())) {
            totlePayAmount = totlePayAmount.add(order.getPayAmount());
        }
    }
    return totlePayAmount;
}

實現一:接到一個需求,完成工作,未仔細推敲代碼的合理性

實現二:接到另外一個需求,需要復用實現一的部分代碼,所以重新組織了下代碼

實現三:仔細看了下實現二,覺得很別扭,深層次的思考了下代碼的結構,發現實現二并沒有滿足現在已知需求的「抽象一致性」

對于實現二queryUserStatistics()的抽象層次,我們可以這樣定義:

查找用戶的訂單消費總額和用戶信息

查找用戶信息

計算訂單消費金額

計算訂單消費金額

查找所有的訂單信息

查找退款信息

過濾退款信息,計算消費金額
或

查找所有的訂單

過濾退款訂單

計算消費金額

過濾退款訂單

查找退款訂單

過濾

結論一:實現二在已知的需求里面其實是不是非常滿足「抽象一致性的」
結論二:仔細推敲下實現三,其實這個方法中filterRefundOrderAndCalculateAmount還是不是非常滿足「抽象一致性」的要求的。

從另外一個角度來看實現二

計算訂單消費金額

查找所有的訂單信息

過濾退款并計算消費金額

過濾退款并計算消費金額

查找退款信息

過濾退款信息

計算消費金額

結論一:如果這樣子理解,也是可以說實現二也滿足「抽象一致性」。
結論二:從不同的角度去看「抽象一致性」得出的結論是不一樣的,只有最符合現有業務的,沒有最正確的

對于實現一queryUserStatistics方法是查詢用戶的消費信息,而這里的詳細計算訂單金額直接寫在這個方法里面,抽象層次十分混亂,所以實現一是不推薦的。

在編寫代碼的時候,盡量讓方法或者類保持「抽象一致性」,這里說盡量的意思就是說明在很多時間可以違反這個約定(因為有的時候會覺得很沒有必要,保持抽象一致性,就代表著你的方法里面可能需要很多私有方法,并且在極端情況下私有方法里面的代碼數很少)

「抽象一致性」從不同的角度看,可能會有不同的結果,所以盡量選一個更加符合當前業務的角度(比如說實現一和實現二)
PS：關于抽象一致性更加詳細的描述,可以翻看我以前的提問對抽象層次一致性的看法