[代码风格]fluent-style(day1)-为何存在

2021-02-22  本文已影响0人  铜炉

前言

今天纠结了好久如何能把fluentStyle的第一个问题,为什么存在FluentStyle这个问题想个示例讲明白说清楚,花了好长时间。最后总算是有一个自己还相对来说比较满意的结果,能够记录一下了。

FluentStyle的启发

其实说实在的,因为并不是创造FluentStyle的人,所以现在考量它为什么存在,有些马后炮的意味,为赋新词强说愁,为找意义强找理由。

不过呢,为了不那么上纲上线非要弄出个123不可,经过几个小时的思考,我决定还是回归本源,为什么一开始看到这个风格会有悸动,为什么使用这个风格的时候会感觉很爽利,这个感觉一定是来自于某种痛点的消除,可能是对于美感的感受,可能是对于效率的追求。

所以,就聊聊这个感受。

java虽然是面向对象的语言,但是实际工作中,还是要写很多很多的流程性问题,比如随便写一个接口,就要面对非法入参的判断,执行逻辑的时候又要考虑有没有白名单?有没有定制规则?要不要数据转化,要不要数据封装?要不要发什么消息?要不要...等等一系列问题,写了系分之后,还是有那么1234567的步骤,可是实际再写起来,总是各个节点都有可能阻塞,又增加了很多的null值判断,为了安全写了一堆的不好看的代码,写起来也很烦,总是打断思路。

然而FluentStyle这种流式风格在我面前出现时,第一时间的反应就是,这个东西可能帮我解决这个问题!所以要说它为什么存在,可能也是某个大佬在写代码的时候被这种感受所疯狂折磨。

举个小小的例子

举一个不太恰当的例子,比如一个人一天要做人多事情(业务流程),要去工作,要打电话,要发短信等等,这些任务和行为发生之后,人还是那个人,只不过一天的举动变多了。如果要去实现这样一个模型,我们的处理办法可能是

  // 要打一个电话
boolean res =  Person.dadainhua();
if (!res) {
    System.out.println("电话没打通!")
} else{
    System.out.println("打通了一个电话")
}

// 要办一个工作
boolean res =  Person.dowork();
if (!res) {
    System.out.println("工作失败了")
} else{
    System.out.println("工作完成!")
}

// 又要办一个工作
boolean res =  Person.dowork();
if (!res) {
    System.out.println("工作失败了")
} else{
    System.out.println("工作完成!")
}
...


当然,我们也可以封装代码,把单元的行为抽离出来,写起来也没这么多冗余代码,但是呢,明显感觉到,每一个行为和行为之间是断层的,就像是一个人总是有发呆的那么一会儿,就感觉很不舒适。

正常来讲,我们每天的生活,可能是打个电话,发几个消息,工作一会,在工作一会,然后吃点饭,然后玩玩手机,等等,时间是连续的,人的行为也是连续的,而传统的代码书写方式确实会让人感觉这种阻塞。

让我们换一个方法试试呢?

public class Person {

    /**
     * 一天做的事
     */
    private ThingsCollect thingsCollect;

    public Person(ThingsCollect thingsCollect) {
        this.thingsCollect = thingsCollect;
    }

    public static class ThingsCollect {
        /**
         * 工作事项
         */
        List<String> works = new ArrayList<>();
        /**
         * 打电话
         */
        List<String> phones = new ArrayList<>();
        /**
         * 发消息
         */
        List<String> messages = new ArrayList<>();
        /**
         * 吃东西
         */
        List<String> foods = new ArrayList<>();
        /**
         * 行动
         */
        List<String> moves = new ArrayList<>();

        private void asserts(String thing) {
            if ("".equals(thing)) {
                throw new RuntimeException();
            }
        }

        ThingsCollect doJob(String job) {
            asserts(job);
            this.works.add(job);
            return this;
        }

        ThingsCollect callPhone(String phone) {
            asserts(phone);
            this.phones.add(phone);
            return this;
        }

        ThingsCollect writeMessage(String message) {
            asserts(message);
            this.messages.add(message);
            return this;
        }

        ThingsCollect eatFood(String food) {
            asserts(food);
            this.foods.add(food);
            return this;
        }

        ThingsCollect walk(String walk) {
            asserts(walk);
            this.moves.add(walk);
            return this;
        }

        Person collectDay() {
            return new Person(this);
        }

    }

    public static ThingsCollect start() {
        ThingsCollect thingsCollect = new ThingsCollect();
        return thingsCollect;
    }


    public static void main(String[] args) {
        Person person = Person
                .start()
                .eatFood("早餐")
                .walk("去上班")
                .doJob("写三行代码")
                .doJob("改五个bug")
                .writeMessage("吐槽bug")
                .callPhone("bug太多开了一个CR会")
                .writeMessage("回来继续吐槽bug")
                .walk("收工回家")
                .eatFood("吃增肥夜宵")
                .collectDay();

    }

}

我们把每天做的事情收集成了一个集合,然后人的行为会向这个集合中增加动作,我们不用关心先做了什么后做了什么,只需要一路流畅的把事情xi

把每天的行为列出来,我们的行为都累加到这个集合里。每天开始的时候,我们焕然一新,start了一天的行程,最终忙忙碌碌结束了一天,并作了总结。这样一个链路下来,在书写代码的时候没有阻塞,思路一致跟着行为时连贯性的去执行,的确达到了流畅

ps

by the way每天想日更,如果提前命题,真的会增大沉没成本,在这个问题深入了一两个小时之后,发现好像说不太清楚的时候真的很要命,换命题又觉得前两个小时白费,不换又不敢保证能不能写的出来,纠结。。。

上一篇下一篇

猜你喜欢

热点阅读