元组在计算机领域有着特殊的意义，这个名字听起来似乎有些陌生， 平时在写代码也基本没什么应用场景， 然而， 出人意料的是， 元组跟程序设计密切相关， 可能有的同学不知道， 关系数据库中的「纪录」的另一个学术性的名称就是「元组」， 一条记录就是一个元组， 一个表就是一个关系， 纪录组成表， 元组生成关系， 这就是关系数据库的核心理念。
元组是关系数据库不可脱离的部份， 但是在程序设计中， 元组并不显得那么不可或缺。 有一些编程语言本身就自带元组的语法， 比如说python、F#、haskell、scala等，另一些更为流行的编程语言却不带元组语法， 如Java、JavaScript、c++、c#等。
元组并不像数组、对象那样是不可缺少的编程元素，但是， 使用它却能对编写代码带来很多的便利，尤其是当一个函数需要返回多个值的情况下。对于这种情况， 普遍的做法是定义一个对象，把函数需要返回的值作为对象的属性设置，然后把函数的返回值类型设为这个对象的类型， 函数直接返回这个对象就相当于返回多个值了。或者可以让这个函数返回一个map数据结构，具体的数据存在这个map里面。 然而， 这两种做法各有缺陷， 第一种方法虽然可靠， 然而代码会显的异常臃肿。需求本身很简单， 只要让函数返回多个值 ， 然而用这种方法却需要事先定义好一个类型， 然后再实例化，再设置实例属性， 最后返回， 这样做的编码效率也未免太低了些。 第二种方法虽然快捷，却不够安全， 在函数的内部或许知道map里存储着什么样的值， 然而在函数外部， 却只知道这个函数的返回值是一个map，至于map里面存有哪些值，是什么类型都是一无所知的， 在多人开发的项目中这种弊端尤其明显 ，可悲的是这种做法在一些动态类型的语言中是首选的方案，这也是动态类型语言被吐槽安全性、可读性差的根本原因之一。 因此， 解决这类问题最好的方案就是使用元组。
在语法本身支持元组的语言中， 元组是用括号表示的，如(int,bool,string)就是一个三元组类型， 它的值可以是(1,true,"abc")。 需要注意是的每一个元组类型都是唯一的， (int,bool)，(bool,int)，(string,double)虽然都是二元组， 然而它们却是不同的元组， 假如把这里的某一个元组作为函数的返回值， 在可读性和安全性方面虽然不如前面讲的第一种使用自定义类型的方案， 然而却比第二种使用map的方案要好的多， 至少使用元组能知道函数会返回几个值， 这些值又分别是什么类型， 而且它还有第二种使用map的方案编码简单快捷的优势。
另人遗憾的是， 像java、c++、c#之类行业内主流的编程语言都不内置元组这一项特性，要使用元组必须自行实现，所幸现在这些编程语言都支持泛型， 实现非内置元组也变的异常简单， 但是毕竟是非语言内置的语法元素，使用起来肯定不如原生元组来的便捷。
下面介绍一个第三方的Java元组库类库，名称叫做Javatuples，有自己的官方主页， github star数也有几百，在Java元组库领域差不多起着垄断的地位了。
Javatuples定义的元组最大长度为10， 其实我觉得10元组的元素数量已经是太多了， 基本上没有什么可读性可言了。 元组类的定义如下
Unit<A> (1 element) Pair<A,B> (2 elements) Triplet<A,B,C> (3 elements) Quartet<A,B,C,D> (4 elements) Quintet<A,B,C,D,E> (5 elements) Sextet<A,B,C,D,E,F> (6 elements) Septet<A,B,C,D,E,F,G> (7 elements) Octet<A,B,C,D,E,F,G,H> (8 elements) Ennead<A,B,C,D,E,F,G,H,I> (9 elements) Decade<A,B,C,D,E,F,G,H,I,J> (10 elements)
这些原型类都是泛型类， 所以尖括号中的字母可以使用任意类型来代替。 下面是一个三元组的代码示例
举一反三，其余的元组类型也是同样的使用方式。
因为Java的元组并非语言自身支持， 因此代码看起来Java味十足， 显得不那么优雅。然而， 写代码时除了书写便捷能提高效率以外，更要注重的是代码本身所表达的意途， 在这里就是利用元组本身的含意（作用）来对代码进行增强， 至于是用什么方式书写其实只是次要的。
最后， 要注意的是泛型尖括号里面的类型不能是Java的基本类型， 如果要使用基本类型那也必须是经过装箱的基础类型，如int形必须转成Integer，bool型对应Boolean类型。
本文转自 sshpp 51CTO博客，原文链接：http://blog.51cto.com/12902932/1928061，如需转载请自行联系原作者
