专栏首页麦洛的历劫之路一段代码被老大要求重构了六次,我心态崩了

一段代码被老大要求重构了六次,我心态崩了

前言

Hi,大家好,我是麦洛。我又回来啦?

进来给大家八卦一段,看看我自己都去干啥了?话说最近公司接了一个农产品交易网站新项目,因为一段代码重构问题差点和老大干起来,本来以为是老大故意刁难我。最后还是发现是我太菜了?,事情是这个样子滴!

在周例会上,老大告知我们最近接了一个农产品交易平台,主要用于全省农产品线上交易。首当其中,就是要把我们甘肃省的黄河蜜推销出去,我就被安排卖瓜!嗷,不,卖瓜这个功能我负责开发?;很快我设计下面的类来定义瓜 Melon 类:

/**
 * 瓜
 * @author Milo Lee
 * @date 2021-04-07 13:21
 */
public class Melon {
    /**品种*/
    private final String type;
    /**重量*/
    private final int weight;
    /**产地*/
    private final String origin;

    public Melon(String type, int weight, String origin) {
        this.type = type;
        this.weight = weight;
        this.origin = origin;
    }
    // getters, toString()方法省略
}

经过一顿CRUD骚操作,写完了瓜类增删改查工作,交工下班?。

第一次 按类型筛选瓜类

第二天,老大给我提了一个问题,说增加能够按瓜类型对瓜进行过滤。这不很简单吗?于是,于是我创建了一个 Filters 类, 实现了一个filterMelonByType方法

/**
 * @author Milo Lee
 * @date 2021-04-07 13:25
 */
public class Filters {

    /**
     * 根据类型筛选瓜类
     * @param melons 瓜类
     * @param type 类型
     * @return
     */
    public static List<Melon> filterMelonByType(List<Melon> melons, String type) {

        List<Melon> result = new ArrayList<>();
        for (Melon melon: melons) {
            if (melon != null && type.equalsIgnoreCase(melon.getType())) {
                result.add(melon);
            }
        }
        return result;
    }
}


搞定,我们来测试一下

    public static void main(String[] args) {
        ArrayList<Melon> melons = new ArrayList<>();
        melons.add(new Melon("羊角蜜", 1, "泰国"));
        melons.add(new Melon("西瓜", 2, "三亚"));
        melons.add(new Melon("黄河蜜", 3, "兰州"));
        List<Melon> melonType = Filters.filterMelonByType(melons, "黄河蜜");
        melonType.forEach(melon->{
        System.out.println("瓜类型:"+melon.getType());
        });
    }

没毛病,拿给老大看看去,老大看了我的代码说:如果我让你在增加一个按重量筛选瓜类,你打算怎么写?回去考虑一下吧,这家伙不会故意找我茬把??

第二次 按重量筛选瓜类

回到座位的我心想,上次我已经实现了按类型筛选瓜类,那我给他copy一份改改吧!

如下所示:

    /**
     * 按照重量过滤瓜类
     * @param melons
     * @param weight
     * @return
     */
    public static List<Melon> filterMelonByWeight(List<Melon> melons, int weight) {

        List<Melon> result = new ArrayList<>();
        for (Melon melon: melons) {
            if (melon != null && melon.getWeight() == weight) {
                result.add(melon);
            }
        }
        return result;
    }

public static void main(String[] args) {
      ArrayList<Melon> melons = new ArrayList<>();
        melons.add(new Melon("羊角蜜", 1, "泰国"));
        melons.add(new Melon("西瓜", 2, "三亚"));
        melons.add(new Melon("黄河蜜", 3, "兰州"));
        List<Melon> melonType = Filters.filterMelonByType(melons, "黄河蜜");
        melonType.forEach(melon->{
            System.out.println("瓜类型:"+melon.getType());
        });

        List<Melon> melonWeight = Filters.filterMelonByWeight( melons,3);
        melonWeight.forEach(melon->{
            System.out.println("瓜重量:"+melon.getWeight());
        });
    }

程序员最喜欢的方式,CV搞定,哈哈。但是我发现filterByWeight()filterByType() 非常相似,就是过滤条件不同。我心想,老大不会让我写一个按类型和重量筛选瓜类吧。拿着我的代码去给老大看,果不其然,怕什么来什么?。

第三次 按类型和重量筛选瓜类

为了满足完成老大的任务,我将上面的代码进行了糅合,很快写了如下的代码

    /**
     * 按照类型和重量来筛选瓜类
     * @param melons
     * @param type
     * @param weight
     * @return
     */
    public static List<Melon> filterMelonByTypeAndWeight(List<Melon> melons, String type, int weight) {

        List<Melon> result = new ArrayList<>();
        for (Melon melon: melons) {
            if (melon != null && type.equalsIgnoreCase(melon.getType()) && melon.getWeight() == weight) {
                result.add(melon);
            }
        }
        return result;
    }

老大看了我的代码说,看来你还是没有理解我的意思。假如今天不光我,还有客户继续这样提需求。

那么 Filters 将会有很多这样类似的方法,也就是说写了很多样板代码(代码冗余但又不得不写);

在我们程序员看来,这是不能接受的。如果继续添加新的过滤条件,则代码将变得难以维护且容易出错。你去了解一下lambda表达式函数式接口知识点,再修改一下你的代码。我已经确定了,他就是和我过不去?

第四次 将行为作为参数传递

经过上面的三番折腾。我发现理论上Melon类的任何属性都有可能作为过滤条件,这样的话我们的Filter类将会有大量的样板代码,而且有些方法会非常复杂。

其实我们可以发现,我们每写一个方法,都对应一种查询行为,查询行为必然对应一种过滤条件。有没有办法我们写一个方法,将查询行为作为参数传递进去,从而返回我们的结果呢?

那么给它取了一个名字:行为参数化,在下图中进行了说明(左侧显示了我们现在拥有的;右侧显示了我们想要的),有没有发现样板代码会明显减少?

如果我们将过滤条件视为一种行为,那么将每种行为视为接口的实现是非常直观的。经过分析我们发现以上所有这些行为都有一个共同点:过滤条件boolean 类型的返回 。抽象一个接口如下

public interface MelonPredicate {
  boolean test(Melon melon);
}

例如,过滤 黄河蜜可以这样写: HHMMelonPredicate

public class HHMMelonPredicate implements MelonPredicate {

     @Override
     public boolean test(Melon melon) {
       return "黄河蜜".equalsIgnoreCase(melon.getType());

     }

}

以此类推,我们也可以过滤一定重量的瓜:

public class WeightMelonPredicate implements MelonPredicate {

     @Override
     public boolean test(Melon melon) {
       return melon.getWeight() > 5000;
     }

}


其实熟悉设计模式的同学应该知道这就是:策略设计模式

主要思想就是让系统在运行时动态选择需要调用的方法。所以我们可以认为 MelonPredicate 接口统一了所有专用于筛选瓜类的算法,并且每种实现都是一种策略,我们也可以把它理解为一种行为。

目前,我们利用策略设计模式,将查询行为进行了抽象。我们还需要一个方法接收 MelonPredicate 参数。于是我定义了 filterMelons() 方法,如下所示:

public static List<Melon> filterMelons(List<Melon> melons, MelonPredicate predicate) {
    
    List<Melon> result = new ArrayList<>();
    for (Melon melon: melons) {
      if (melon != null && predicate.test(melon)) {
        result.add(melon);
      }

    }  
    return result;
}


大功告成,测试一下,果然比之前好用多了,再让老大瞅瞅去

List<Melon> hhm = Filters.filterMelons(melons, new HHMMelonPredicate());

List<Melon> weight = Filters.filterMelons(melons, new WeightMelonPredicate());


第五次 一次性加了100个过滤条件

就在我沾沾自喜时候,老大又给他泼了一盆冷水。他说你以为我们的平台就买黄河蜜啊,如果前前后后有几十种瓜品种,我给你列出100种过滤条件,你怎么办?

我的心里一万个草泥马在奔腾啊?!老大是不是存心和我过不去啊!虽然经过上次改造,我的代码已经足够灵活,但是如果突然增加100个过滤条件,我仍然需要编写100个策略类来实现 每一个过滤条件。然后我们需要将策略传递给 filterMelons() 方法。

有没有不需要创建这些类的办法那?聪明的我很快发现可以使用java匿名内部类

如下所示:

List<Melon> europeans = Filters.filterMelons(melons, new MelonPredicate() {

     @Override

     public boolean test(Melon melon) {

       return "europe".equalsIgnoreCase(melon.getOrigin());

     }

});


虽然向前跨了一大步,但好像无济于事。我还是需要编写大量的代码实现此次需求。设计匿名内部类的目的,就是为了方便 Java 程序员将代码作为数据传递。有时候,匿名内部类看这比较复杂,这时候,我突然想起来老大让我学的lambda表达式,我可以用它来简化

List<Melon> europeansLambda = Filters.filterMelons(
  melons, m -> "europe".equalsIgnoreCase(m.getOrigin())
);

果然看这帅多了!!!,就这样,我又一次成功完成了任务。我兴冲冲的拿着代码让老大去看看。

第六次 引入泛型

老大看着我的代码说,嗯,不错!脑袋终于开窍了。现在你考虑一下,我们的平台是做农产品的,也就是肯定不止瓜这一类水果,如果换做其他的水果,你的代码如何修改?

目前我们的MelonPredicate仅支持 Melon 类。这家伙怎么搞?说不定哪天他要买蔬菜、海参可怎么搞,总不能给他再创建好多类似MelonPredicate的接口吧。这个时候突然想起老师讲过的泛型,该它发挥作用了!

于是我定义了一个新接口Predicate

@FunctionalInterface
public interface Predicate<T> {

  boolean test(T t);

}


接下来,我们重写该 filterMelons() 方法并将其重命名为 filter()

public static <T> List<T> filter(List<T> list, Predicate<T> predicate) {
  
 List<T> result = new ArrayList<>();

    for (T t: list) {

      if (t != null && predicate.test(t)) {

        result.add(t);

      }

    }  

    return result;

}


现在,我们可以这样过滤瓜类 :

List<Melon> watermelons = Filters.filter(

  melons, (Melon m) -> "Watermelon".equalsIgnoreCase(m.getType()));


同样的,我们也可以对数字做同样的事情:

List<Integer> numbers = Arrays.asList(1, 13, 15, 2, 67);

List<Integer> smallThan10 = Filters.filter(numbers, (Integer i) -> i < 10);


回过头来复盘一下,我们发现自从使用Java 8函数式接口和lambda表达式后,代码发生了明显的变化。

不知道细心的伙伴有没有发现我们上面的 Predicate 接口上面多了一个@FunctionalInterface 上的注解,它就是标记函数式接口的。

至此,我们通过一个需求的演变过程,了解了lambda和函数式接口的概念,同时也加深对它们的理解。其实熟悉java8的朋友都知道,在我们的 java.util.function 包下包含40多个此类接口

函数式接口lambda表达式组成了一个强大的团队。根据上面的例子,我们知道函数式接口是我们行为的高度抽象,lambda表达式我们可以看出这种行为的具体实现的一个实例。

Predicate<Melon> predicate = (Melon m)-> "Watermelon".equalsIgnoreCase(m.getType());

简而言之Lambda

lambda表达式由三部分组成,如下图所示:

以下是lambda表达式各部分的描述:

  • 在箭头的左侧,是在lambda表达式主体中使用的参数。
  • 在箭头的右侧,是lambda主体 。
  • 箭头只是lambda参数和主体的分隔符。

lambda的匿名类版本如下:

List<Melon> europeans = Filters.filterMelons(melons, new Predicate<Melon>() {

 @Override

 public boolean test(Melon melon) {

   return "Watermelon".equalsIgnoreCase(melon.getType());

 }

});

现在,如果我们查看lambda表达式及其匿名类版本,可以从下面四方面来描述lambda表达式

我们可以将 lambda 表达式定义为一种 简洁、可传递的匿名函数,首先我们需要明确 lambda 表达式本质上是一个函数,虽然它不属于某个特定的类,但具备参数列表、函数主体、返回类型,甚至能够抛出异常;其次它是匿名的,lambda 表达式没有具体的函数名称;lambda 表达式可以像参数一样进行传递,从而简化代码的编写。

Lambda支持行为参数化,在前面的例子中,我们已经证明这一点。最后,请记住,lambda表达式只能在函数式接口的上下文中使用。

总结

在本文中,我们重点介绍了函数式接口的用途和可用性,我们将研究如何将代码从开始的样板代码现演变为基于函数式接口的灵活实现。希望对大家理解函数式接口有所帮助,谢谢大家。

本文分享自微信公众号 - 今日Java(JavaToday),作者:麦洛

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Spring+SpringMVC+MyBatis+easyUI整合进阶篇(七)一次线上Mysql数据库崩溃事故的记录

    作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载。 文章简介 工作这几...

    程序员十三
  • 东汉末年,他们把「服务雪崩」玩到了极致(干货)

    话说东汉末年,曹操、孙权、刘备在赤壁市进行了一次争夺老大位置的大战,这就是有名的赤壁之战。

    悟空聊架构
  • zookeeper核心之ZAB协议就这么简单!

    我们都知道 Zookeeper 是基于 ZAB 协议实现的,在介绍 ZAB 协议之前,先回顾一下 Zookeeper 的起源与发展。

    java之旅
  • Spring+SpringMVC+MyBatis+easyUI整合进阶篇(八)线上Mysql数据库崩溃事故的原因和处理

    前文提要 承接前文《一次线上Mysql数据库崩溃事故的记录》,在文章中讲到了一次线上数据库崩溃的事件记录,建议两篇文章结合在一起看,不至于摸不着头脑。 由于时间...

    程序员十三
  • 遥想当年你因为什么成为了一名程序员

    兄弟姐妹们,还记得自己成为一名程序员的初心吗?遥想公瑾当年,不,遥想我当年,似乎是“命中注定”走上这条路的。因为不在计划之内嘛,所以走了很多弯弯路。

    Java周某人
  • geotrellis使用(七)记录一次惨痛的bug调试经历以及求DEM坡度实践

         眼看就要端午节了,屌丝还在写代码,话说过节也不给轻松,折腾了一天终于解决了一个BUG,并完成了老板安排的求DEM坡度的任务,那么就分两段来表。 一、B...

    魏守峰
  • 大数据时代的裸奔

    我以维克托·迈尔·舍恩伯格肯尼思·库克耶所著的《大数据时代》为基础,又参考了其它书籍文献,结合我以前学习过的数据仓库和数据挖掘知识,把内容进行了提炼和总结。

    华章科技
  • 微服务应该这么搞,才能少踩坑!

    微服务越来越火。很多互联网公司,甚至一些传统行业的系统都采用了微服务架构。体会到微服务带来好处的同时,很多公司也明显感受到微服务化带来的一系列让人头疼的问题。本...

    Bug开发工程师
  • Legacy Code Base如何做重构?

    这些特征如果同时出现在你面前,我猜你离崩溃的边缘不远了,如果后边还跟着一个PM催进度,你估计要怀疑IT人生了。不过,如果你有机会遇到这样的场景,那首先恭喜你,你...

    袁慎建@ThoughtWorks

扫码关注云+社区

领取腾讯云代金券