在实习的这一段时间里，我深刻体会到一个道理，就是用户的需求不断的在变化，因而自己的代码也要进行重构，这说明了一个问题，我设计的代码不够好。所以，我觉得作为程序员来说，很重要的一点就是，让你的代码能够适应变化。
行为参数化
行为参数化，就是可以帮助我们处理频繁变化需求的一种软件开发模式，通俗的说，就是拿出一个代码块，把它准备好，却不去执行它。这个代码块以后可以被程序的其他部分调用，这就意味着我们可以推迟这块代码的执行。
背景
农场里有很多苹果，我们要去筛选特定的苹果，并记录下来。接下来，我们通过不断变化的需求来重构我们的代码。以下的场景都是我虚拟出来的，便于故事的发展，哈哈。
片段一
开始的别人给我们提出的需求是，筛选出来所有颜色是绿色的苹果。我心里想，你是不是鄙视我，这么简单，遍历一下把绿色苹果放到新的集合不就行了吗？我可是程序员哎，不是来打杂的，我可是要写牛逼的代码的。算了，还是写吧。代码如下:
public static List<Apple> filterGreenApples(List<Apple> inventory) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if ("green".equals(apple.getColor())) {
result.add(apple);
}
}
return result;
}
我把代码提交上去了，然后屁颠屁颠的做其他事情了，好像完成了一个很大的项目。。。
片段二
第二天，那个人又找到我，说道，你能不能实现一个筛选红色苹果的接口。
我心里自言自语，卧槽，这需求变化那么快，昨天苹果还是绿的，今天就变红了，尼玛，这万恶的商家，催熟剂就是厉害。以后吃苹果还是吃青的吧。开始我准备把上面的代码copy下来，然后"green"改成"red"，但是仔细一想，万一明天，让我写一个黑苹果的接口，那我不又要写一个。于是把color抽象出来，变成一个参数传进来，这样你要什么颜色的我都有了。突然，发现自己好厉害，抽象我都会。。。自我陶醉中。代码如下:
public static List<Apple> filterApplesByColor(List<Apple> inventory, String color) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (color.equals(apple.getColor())) {
result.add(apple);
}
}
return result;
}
写完之后，我心里在那嘀咕，万恶的资本主义，我把颜色都抽象出来了，看你需求怎么变。哥，可是--程序员。
片段三
晚上回去睡个安稳觉后，第二天，那人又来了，对，还是那个男人。我问他，是不是我写的接口不行。那人回到到，不是，是这边又有新的需求。突然之间，整个人都傻了。还有需求，算了，谁让我是程序员呢。之后，他和我说道，新的需求是区分，大苹果和小苹果，大苹果是重量大于500g的。二话没说，扭头就去撸代码。代码如下：
public static List<Apple> filterApplesByWeight(List<Apple> inventory, int weight) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (apple.getWeight() > weight) {
result.add(apple);
}
}
return result;
}
聪明的我，早已想到需求会变，这次直接把这个接口抽象好，内心不禁有暗暗自喜。想到世界还有自己这种程序员，就说明世界还有希望。
片段四
第二天，他又来了，我知道，又要干活了。新的需求是，过滤那些红色的且重量大于500g的苹果。代码如下:
public static List<Apple> filterApples(List<Apple> inventory, String color, int weight) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (color.equals(apple.getColor()) && apple.getWeight() > weight) {
result.add(apple);
}
}
return result;
}
不一会我就设计好了，但是却没有之前的开心了，不知道明天又会有什么新的需求，宝宝心里好苦啊。
片段五
之后令我很惊讶的是，没有新的需求提出了，我一遍暗地自喜，一遍在思考一个问题。为什么，需求变，我的代码就要变化那么大呢？需求都是和选择苹果相关，选择什么样的苹果是通过参数来传递的，那么有没有一种方法，通过一个借口来实现传递不同的参数呢？
如果熟悉设计模式的你，应该能想到策略模式。接口一致，按需传递该接口对应的实例。也是面向接口编程的一种体现。先设计一个接口，用来承载选择苹果的逻辑，代码如下:
public interface ApplePredicate {
boolean test(Apple apple);
}
现在我们可以用不同的实现来传递不同的逻辑了，如下:
//绿色苹果
public class GreenApplePredicate implements ApplePredicate {
@Override
public boolean test(Apple apple) {
return apple.getColor().equals("green");
}
}
//大苹果
public class BigApplePredicate implements ApplePredicate {
@Override
public boolean test(Apple apple) {
return apple.getWeight() > 500;
}
}
//代码主体
public static List<Apple> filterApples(List<Apple> inventory, ApplePredicate p) {
List<Apple> result = new ArrayList<>();
for (Apple apple : inventory) {
if (p.test(apple)) {
result.add(apple);
}
}
return result;
}
可以看出，代码主体以后我们就不会改变了，只要通过传入不同的行为(过滤逻辑)，就行了，而且这里只传递一个参数，却可以传递多种行为，多种行为，一个参数，是不是很nice。我又开始沾沾自喜。。感觉自己又变得厉害了，晚上回去睡得很任性。
片段六
第二天，还是没有新的需求，我们都知道，程序员没事做，这宝贵的资源就白白的浪费，别人不心疼，我都心疼。于是，自己又去捣鼓昨天的那块代码去了。
刚开始用起来还是蛮舒服的，但是用久了发现，每次一个新的逻辑都要去实现这个接口，太难受了，突然，想到了java还有匿名类，于是，之后直接用匿名类来实现这个逻辑。代码如下:
List<Apple> greenApples = filterApples(inventory, new ApplePredicate() {
@Override
public boolean test(Apple apple) {
return apple.getColor().equals("green");
}
});
这样看起来，的确比之前简洁多了，不要显式的去实现一个接口。但是细细的观察了一下，这里面真正有用的代码就这一行:
return apple.getColor().equals("green");
那么有没有什么办法，只给filterApples方法只传递这样真正逻辑性的代码呢？幸好，java8提供了行为参数化的支持。好吧，既然都支持了，还等什么，干吧，下面这一行代码就解决了。
List<Apple> greenApples = filterApples(inventory, (Apple apple) -> apple.getColor().equals("green"));
什么，我没有看错吧，这么神？你并没有看错，传递的参数叫做lambda表达式，如果还嫌不够简洁，你可以把类型去掉，像这样:
List<Apple> greenApples = filterApples(inventory, apple -> apple.getColor().equals("green"));
经历了以上几个阶段，我们重构了很多次代码，让接口能够适应需求的变化，一方面，我们又不想编写冗余的代码，通过lambda表达式来传递核心代码，程序员不在做一些不必要的工作，真的是太好了。
