Skip to content

四火的唠叨

一个纯正程序员的啰嗦

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

泛型传递

Posted on 06/09/201406/23/2019 by 四火

chain 最近在读代码的过程中,经常遇到一些利用泛型来对调用链中的参数进行类型约束的情形,特指对于调用链中后面环节的参数类型和返回值,由前面环节的参数类型来确定,我草率地把它称作泛型传递(技巧很简单,但是用得好会很有趣;我不知道这个东西正儿八经的名字叫做什么)。

在说这个事情以前,对于 Java 的泛型,还是和其它语言中有些许的不同,这里需要结合使用方法泛型和类泛型,如有不明,对于其中的使用可以参考这篇 《泛型趣谈》,而其实下面要说的内容,其实也就是这篇文章中提到的 “链式调用”。另外,也顺便提一句,“泛型” 和 “范型” 可是完全不相干的东西,相差十万八千里(若有混淆,关于 “范型”,可以移步阅读这篇文章)。

很多情况下,我们写代码要解决的直接问题就是平衡变化和不变这两部分,很多情况下需要寻找抽象的不变的那一部分,把变化的部分留给 “外部”(开发者/使用者/其它系统/调用者)去解决。处理变化点的方式有很多,简单可以分为运行时和编译期间两种,各种各样的设计模式和方法技巧,都是围绕变与不变这样的问题。

  • 对于运行时来说,处理变化问题,核心就是使用 if-else 这样的分支选择;除了这个办法,还有就是多态。
  • 对于编译期间来说,方法重载是最基本的方法,但是现在也可以用泛型来进行规约;不过,遗憾的是 Java 的泛型始终只能做到编译期间类型检查而已,编译后的字节码里面早就擦除了泛型的信息。

无论如何,利用泛型来实现参数类型的约束已经非常有用了,最近在写的一些代码,很多情况下,需要结合 Class<T> 和泛型传递来实现参数约束,如下代码:

interface Transformer<Input, Output> {
	public Output transforme(Input input);
}

class Builder {
	private static Builder instance = new Builder();

	private Builder() {
	}

	public static Builder getInstance() {
		return instance;
	}

	public <Input, Output> BuilderAfterTransformerBinding<Input, Output> bindTransformer(
			Class<? extends Transformer<Input, Output>> clazz) {
		return new BuilderAfterTransformerBinding<Input, Output>(clazz);
	}
}

class BuilderAfterTransformerBinding<Input, Output> {
	private Transformer<Input, Output> transformer;

	public BuilderAfterTransformerBinding(
			Class<? extends Transformer<Input, Output>> clazz) {
		try {
			transformer = clazz.newInstance();
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}

	public Wrapper<Output> wrap(Input input) {
		return new Wrapper<Output>(transformer.transforme(input));
	}
}

class Wrapper<T> {
	private T t;

	public Wrapper(T t) {
		this.t = t;
	}
}

这段代码中,

  • Transformer 接口就是用来把某 Input 转成 Output 之用的;
  • Builder 类是链式调用的入口;
  • Wrapper 类是一个普通的包装类;
  • BuilderAfterTransformerBinding 类是链式调用第二步的对象,对于调用者来说,他调用其中的 wrap 方法时,传入的参数(上述代码中的 Input)是由链式调用第一步的 Class 泛型所决定的,如下例调用:
byte[] byteArray = ...;
Builder.getInstance().bindTransformer(
	new Transformer<byte[], String>() {
		@Override
		public String transforme(byte[] input) {
			... ...
		}
	}.getClass())
.wrap(byteArray);

其中链式调用的第一步传入的 Class 中,定义了泛型 Input 是 byte[],Output 是 String,那么第二步 wrap 方法的入参也必须是 byte[],返回值必须为 String。

泛型传递的类型约束也是在编译期间达成的,用得好的话它的作用无法替代。在框架的代码定义上显得冗余,但是对于框架代码的客户来说,写类型确定的链式调用是很愉快的。

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

×Scan to share with WeChat

你可能也喜欢看:

  1. 泛型趣谈
  2. 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(类型系统)
  3. 一段集合操作的不同语言表达
  4. 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(引子)
  5. 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(DSL)

1 thought on “泛型传递”

  1. 童燕群 says:
    07/24/2014 at 10:52 PM

    理论上来说,可以把泛型无限的传递到更深的层次去吧?感觉这样的代码不是特别好读和调试。还是喜欢用多态和简单的模式去解决问题。都有了 Object 这个“ 超类”,好像没有什么是必须用泛型解决的。

    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 Python Spark 互联网 亚马逊 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 英语 西雅图 设计 评审 谈谈 Ops 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System and Architecture (43)
  • Distributed System (14)
  • Big Data and Machine Learning (5)
  • Frameworks and Libs (21)
  • Database (5)
  • Front-end Development (21)
  • Programming Languages (17)
  • Programming Paradigm (16)
  • Thoughts on Coding (26)
  • Testing (4)
  • Network (4)
  • Security (6)
  • Operations (14)
  • Product Design (7)
  • Internet (12)
  • Hiring and Interview (14)
  • Project and Team Management (16)
  • Engineering Culture (17)
  • Individual Development (33)
  • My Career (25)
  • Life (51)

推荐文章

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

近期评论

  • 二冰 on 入职后一些零散的感受和思考
  • soli on 再谈程序员学英语
  • Anonymous on 再谈程序员学英语
  • Anonymous on 网站性能优化的三重境界
  • Anonymous on 近况更新:第三次换工作
  • Alan on 入职后一些零散的感受和思考
  • Anonymous on 入职后一些零散的感受和思考
  • s on 入职后一些零散的感受和思考
  • 四火 on 近况更新:第三次换工作
  • ZL on 近况更新:第三次换工作
© 2023 四火的唠叨 | Powered by Minimalist Blog WordPress Theme