代码重构：依恋情节（Feature Envy）

什么是依恋情节（Feature Envy）

• 定义：依恋情节/特性依恋: 一个函数跟另一个模块中的函数或数据交流格外频繁，远胜于在自己所处模块内部的交流
• 影响：可读性、可维护性低：调用另一模块功能时往往需要打一套组合拳才能完成，需要知道过多的细节；往往会伴随有“内幕交易、重复代码、霰弹式修改……”
• 改进目标：将函数搬移到对应的类，解除跨模块的过多交流
• 方法：提炼函数、搬移函数
• 注：策略模式、访问者模式往往会带来依恋情节，这不是说这两个模式不可取。我们需要理解：从根本上，我们消除“依恋情节”和应用这些设计模式都是为了把一起变化的东西放到一块儿。

案例代码

public class Invoice {
    private final String buyer;

    private final String seller;

    private final List<InvoiceLine> lines;

    public Invoice(String buyer, String seller, List<InvoiceLine> lines) {
        this.buyer = buyer;
        this.seller = seller;
        this.lines = new ArrayList<>(lines);
    }

    public String getBuyer() {
        return buyer;
    }

    public String getSeller() {
        return seller;
    }

    public List<InvoiceLine> getLines() {
        return Collections.unmodifiableList(lines);
    }
}

代码背景

• 发票（Invoice）有买方、卖方、还有多个明细行；
• 明细行（InvoceLine）有商品名称、单价、数量；
• 发票打印器（InvoiceFormatter）将发票信息格式化后输出，其中将包含总金额和各明细行金额。

症状/问题

• InvoiceFormatter知道了过多关于Invoice和InvoiceLine的细节。通过Invoice/InvoiceLine提供的属性，自行计算了金额：
• 计算了InvoiceLine的总额（利用了InvoiceLine的2个方法，并带入了multiply方法的使用）
• 计算了Invoice的总额（利用了Invoice/InvoiceLine的3个方法）
• 万一，今后Invoice加上个折扣率，那么这些地方很难支持

• 改进目标
  

重构对比

总结