在日常开发中，我们经常听到这样的话：“把这段代码提成一个单独的方法(类),这样就可以在被复用了”，然而，我们由于我们抽取的方法不同，导致有些模块并不具备复用的条件，而有的模块不仅可以小规模复用，甚至可以大规模复用。本文就和大家探讨下如何写出大规模可复用的代码。

这里借用《Scala函数式编程》里举的一个例子，来感受下：

场景：购买咖啡

Given： 我要用信用卡购买一杯咖啡

When：提供一个合法的信用卡号

Then：完成计费，并能给客户一杯咖啡

这是一个典型的场景，我们第一反应下的代码应该是这样的：

public class BuyCoffeeService{
  @Autowired
  BankService bankService;
  
  public Coffee buyCoffee(CreditCard creditCard){
    Coffee coffee=new Coffee();
    BigDecimal price=new BigDecimal("10.0");
    bankService.decrease(creditCard,price);
    }
}

一般来讲，我们基本上完成了需求，即使使用BDD测试套件，也察觉不到有什么问题。但是如何测试这个代码是不是可复用呢，很简单，我们一次性买10杯咖啡。

public class BuyCoffeeService{
  @Autowired
  BankService bankService;
  
  public Coffee buyCoffee(CreditCard creditCard){
    Coffee coffee=new Coffee();
    BigDecimal price=new BigDecimal("10.0");
    bankService.decrease(creditCard,price);
    }
  public List<Coffee> buyCoffee(CreditCard creditCard,int count){
    if(count>0){
      List<Coffee> coffees=new ArrayList(n);
      for(int i=0;i<n;i++){
        coffees.add(this.buyCoffee(creditCard));
      }
      return coffees;
    }else{
      return Collections.emptyList();
    }
  }
}

​ 看起来也能复用。。。可是等我们上线后不久，客户经理气呼呼的过来找你，说你的程序上线出事故了！有的客户买了三杯咖啡，结果提示用户购买失败，但是却扣了两杯的钱！而商家说我一次性卖10杯，为什么扣10次手续费？？

找来找去，发现他们全都是调用buyCoffee(CreditCard creditCard,int count)这个方法。因为BankService是一个远程调用，买多次咖啡可能引发上层应用超时，而且，扣商家十笔手续费确实不妥。

那么我们在这种场景下是不是可以做批量操作呢？答案是可以的。

public class BuyCoffeeService{
  @Autowired
  BankService bankService;
  
  public Coffee buyCoffee(CreditCard creditCard){
    AbstractMap.Entry<Coffee,BigDecimal> result=    cupOfCoffee();
    bankService.decrease(creditCard,result.value());
    }
  
  private AbstractMap.Entry<Coffee,BigDecimal> cupOfCoffee(){
    return new AbstractMap.Entry(new Coffee,new new BigDecimal("10.0"));
  }
  
  public List<Coffee> buyCoffee(CreditCard creditCard,int count){
    if(count>0){
      List<AbstractMap.Entry<Coffee,BigDecimal>> coffees=new ArrayList(n);
      for(int i=0;i<n;i++){
        coffees.add(this.cupOfCoffee());
      }
      bankService.decrease(creditCard,coffees.stream()
                           .map(entry->entry.value())
                           .reduce(new BigDecimal(0),(r1,r2)->r1.add(r2)));
      return coffees.stream().map(entry->entry.key()).collect(Collectors.toList());
    }else{
      return Collections.emptyList();
    }
  }
}

仔细分析这段代码，会发现，我们通过把生成账单的这段代码实现了逻辑的复用，消除了代码之外隐含的问题。

举这个例子，我是想提出一个观点:

可以完美复用的代码，一定是无副作用的 。

所谓副作用，指的是对外部世界的影响，我们调用一段函数的时候，如果不能完全了解其对外部世界的影响，就会出现隐含的bug。从外观上看，调用buyCoffee的时候只是返回了一杯coffee，完全不知道它还调用外部进行了扣款操作。这就是我们无法控制其副作用的表现。

那么如何控制代码的副作用呢？

首先，副作用是无法消除的，但是可以被推迟处理。我们的软件就是靠其产生的副作用产生价值的，所以没办法消除副作用，我们可以把副作用推到最外层处理，使计算部分和输入输出部分分开，正如上面那段代码，计算部分就是产生coffee和账单的cupOfCoffee 方法，而buyCoffee则根据cupOfCoffee的结果与外部进行通信。

我们能做的，只能是隔离计算和输入输出。

一般情况下Java的函数式API已经够我们用的了，我这里主要介绍几种技巧，来消除计算过程中的副作用。

异常处理

异常处理在Java中有很多流派，在《Effective Java》中建议我们接口中方法声明的时候不要声明受检异常，声明受检异常意味着接口方法要了解其实现，违背了面向接口编程的初衷。而在日常编码中，我们常常像下面那样操作

    private static void checkBounds(byte[] bytes, int offset, int length) {
        if (length < 0)
           throw new StringIndexOutOfBoundsException(length);
        if (offset < 0)
            throw new StringIndexOutOfBoundsException(offset);
       if (offset > bytes.length - length)
            throw new StringIndexOutOfBoundsException(offset + length);
    }

上面的例子来自JDK，严格的讲，这也不是一个好的实践，因为它有个假设，就是我们只能在同一个线程中调用该函数。下面的代码将不能很好的运行

public String findSomeName(Integer id){
   SomeOne someone= mapper.findeSomeNone(id)
     return someone.getName();
}

public List<String> memberNames(List<SomeOne> list){
  return list.parallelStream().map(this::findSomeName).collect(Collectors.toList());
}

上面如果 some没有找到的话，会抛空指针异常，但是不会在当前线程中抛出，而且，无法从函数声明的返回值类型无法覆盖所有的结果（并没有告诉调用者这方法将返回异常，所以客户端可能会漏掉异常处理）。这种情况，我们可以定义Either容器，关于Either容器，这里就不详细介绍了，直接贴解决代码

public Either<String,Exception> findSomeName(Integer id){
  try{
    SomeOne someone= mapper.findeSomeNone(id)
     return Either.right(someone.getName());
  } catch(Excetion e){
    return Either.left(someone.getName());
  }
}

public List<String> memberNames(List<Integer> ids){
 
  List<Either<String,Exception>> result=list.parallelStream().map(this::findSomeName).collect(
  Collectors.toList());
   return result.stream().filter(Either::isRight).collect(Collectors.toList());
}

这样处理 ，既没有把异常吞掉，又有效的对结果进行了组合

多返回值

多返回值的问题也是经常困扰开发人员的一个问题。在购买coffee的改造后的函数中，我们返回了一个AbstractMap.Entry 作为返回值类型，有的看官可能比较奇怪，这是因为Java中并没有原生的Turple类型，如果想要把Coffee和账单同时返回，一般情况下，需要定义一个DTO作为返回值，但是如果每抽取一个函数都要定义一个DTO的话，我想大多数人都不会愿意抽取函数了，所以我们可以定义一些公用的容器类，作为返回值的容器，

public static class Tuple2<A, B>{
       
        public final A _1;
        
        public final B _2;

        private Tuple2(A _1, B _2) {
            this._1 = _1;
            this._2 = _2;
        }
        public static <A,B> tuple2(A a,B b){
          return new Tuple2(a,b);
        }
    }

之后我们就可以用这个tuple辅助抽取一些需要多返回值的函数了，对于tuple2不满足的可以定义一些tuple3，tuple4...

本文介绍了一些日常开发用的技巧，如果想了解类似更多的技巧，可以了解些函数式编程的理论，在这里我就不展开讲了。