Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

关于接口设计,还有 Fluent Interface,这种有趣的接口设计风格

Posted on 02/07/201210/08/2024 by 四火

1 这个故事我早就想说了,可能是在好多个月前,只是一直不知道怎么说才能说合适,现在我重新整理了一下,讲述给大家。

这个故事是从下面这样一个对外暴露接口的调用开始的。

QueryUserEvent event = new QueryUserEvent();  
event.setName(name);  
event.setAge(18);  
event.setType(QueryUserEvent.TYPE_NORMAL);  
event.setSex(QueryUserEvent.SEX_MALE);  
……  
List<User> userList = userService.query(event);  

我想做的事情其实很简单,我想查询一个用户列表,可是接口参数的拼装让我感到头疼,这样的代码太过啰嗦,我希望有可读性更好的解决办法。

P 兄台说,如果我直接传入一个 user 对象,是不是可以避开了这个未必带来多少好处的 event?

User user = new User();  
user.setName(name);  
user.setAge(18);  
user.setSex(QueryUserEvent.SEX_MALE);  
……  
List<User> userList = userService.query(user, UserService.QUERY_TYPE_NORMAL);  

我有时候会考虑你说的办法的,可是,你没有解决实际的问题,我现在的最大问题在于,这一堆的 setXXX 方法,它破坏了我构造这个查询条件对象的流畅性。

他紧接着说,那要不然,我们把 setXXX 方法的劳动省下来,让构造器来替我们完成这个任务吧:

User user = new User(name, 18, QueryUserEvent.SEX_MALE, ……);  
List<User> userList = userService.query(user, UserService.QUERY_TYPE_NORMAL);  

我说,你的办法看起来不错,不过有时候按你的办法做,我的构造方法会变得臃肿无比,比如出现十多个参数;

另外还有一个问题,假如说,我的查询条件是简单的(我只需要根据年龄查询),那么其它的参数都要写成 null,类似这样子:

User user = new User(null, 18, null, null, null, null, ……);  
List<User> userList = userService.query(user, UserService.QUERY_TYPE_NORMAL);  

天,让谁去阅读这样的代码,他都不会喜欢的。

而且,有时候情形变得复杂,比如,我不是要查询 18 岁的所有 user,而是要查询大于 18 岁的所有 user,你的办法似乎行不通了呢……

你真是一个麻烦的人,他说,这样吧,我定义一个 Condition,他给查询条件带来了灵活的组装方式:

UserQueryCondition condition = new UserQueryCondition();  
condition.setAge(Condition.GREATER_THAN, 18);  
List<User> userList = userService.query(condition, UserService.QUERY_TYPE_NORMAL);  

不过,他补充道,如果在 JavaScript 中,我可以采取的办法要好得多。如果要查询 18 岁的和符合其他条件的用户,可以这样写:

userService.query({  
    name : name,  
    age : 18,  
    sex : User.SEX_MALE  
}, UserService.QUERY_TYPE_NORMAL);  

如果要大于 18 岁呢,可以这样写:

userService.query({  
    name : name,  
    greaterThan : {  
        age : 18  
    },  
    sex : User.SEX_MALE  
}, UserService.QUERY_TYPE_NORMAL);  

不过,他接着说,在 Java 里面好像还没有类似简洁的表示方法……

万幸的是,有一种接口连续调用的风格,叫做 “Fluent Interface”,可以让这个问题写成这样一种有趣的实现:

List<User> userList = new UserService().setName(name).setAge(18).setSex(User.SEX_MALE).query(UserService.QUERY_TYPE_NORMAL);  

大于 18 岁的话,这样写:

List<User> userList = new UserService().setName(name).greaterThan(new User().setAge(18)).setSex(User.SEX_MALE).query(UserService.QUERY_TYPE_NORMAL);  

我想,这样的设计如果在数学计算的时候,会显得有用得多,看这样一个算式:

ln(sin((x+y) 的平方))

如果用传统的方式来实现的话,应该类似这样子:

Math.log(Math.sin(Math.sqrt(x + y)))  

显然,它的可读性不如 Fluent Interface 来得好:

new MyNumber(x+y).sqrt().sin().log()  

这样的例子还有很多,比如在 JQuery 中的使用,在 EasyMock 中的使用等等。看下面的例子,这样构建一个 DOM 树,是不是比单纯的字符串拼接,要好理解一些呢?

$("#div1")  
    .div({id:"subDIV"})  
        .h1("A Title")  
            .a({href:"xxx"})  
            .a()  
        .h1()  
    .div();  

《CommandQuerySeperation》这篇文章把一个对象的方法大致分成下面两种:

Queries: Return a result and do not change the observable state of the system (are free of side effects).

Commands: Change the state of a system but do not return a value.

对于 Fluent Interface 而言,它的接口调用既改变了对象的状态,又返回了对象(this 或其他),并不属于上面的两种类型。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. DAO 的演进
  2. 如何思考面向对象
  3. 画圆画方的故事
  4. EasyMock、EasyMock Class Extension 和 PowerMock
  5. 分页的那些事儿

2 thoughts on “关于接口设计,还有 Fluent Interface,这种有趣的接口设计风格”

  1. Kwanwoo says:
    04/02/2021 at 12:13 AM

    建造者模式!

    Reply
  2. clonne says:
    05/27/2014 at 1:04 PM

    然而很遗憾的是,程序设计的实际设计会面临着极为庞大和恐怖的细节问题。现代软件,最棘手的就是多线程、错误处理、… 这些大问题,现代软件还必须要一定的容错性甚至要有一点自我修复的能力,所以这些接口也都得用繁琐的方式,因为必须时刻判断是否出错了,是否有问题。而这种链式调用方法,也只是理论上可行,只能在小范围使用。现代软件太难做了,细节太多,而经常是不得不面对这些细节,不得不控制这些细节。一切理论上可行的,都会因为细节问题而很难实际应用。

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • rocky on 关于时间管理的一点新的感悟
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme