【Java 基础】Java Map中的Value值如何做到可以为任意类型的值
Occasionally the average developer runs into a situation where he has to map values of arbitrary types within a particular container. However the Java collection API provides container related parameterization only. Which limits the type safe usage of HashMap
for example to a single value type. But what if you want to mix apples and pears?
Luckily there is an easy design pattern that allows to map distinct value types using Java generics, which Joshua Bloch has described as typesafe hetereogeneous container in his book Effective Java (second edition, Item 29).
Stumbling across some not altogether congenial solutions regarding this topic recently, gave me the idea to explain the problem domain and elaborate on some implementation aspects in this post.
Map Distinct Value Types Using Java Generics
Consider for the sake of example that you have to provide some kind of application context that allows to bind values of arbitrary types to certain keys. A simple non type safe implementation using String
keys backed by a HashMap
might look like this:
public class Context {
private final Map<String,Object> values = new HashMap<>();
public void put( String key, Object value ) {
values.put( key, value );
}
public Object get( String key ) {
return values.get( key );
}
[...]
}
The following snippet shows how this Context
can be used in a program:
Context context = new Context();
Runnable runnable = ...
context.put( "key", runnable );
// several computation cycles later...
Runnable value = ( Runnable )context.get( "key" );
The drawback of this approach can be seen at line six where a down cast is needed. Obviously this can lead to a ClassCastException
in case the key-value pair has been replaced by a different value type:
Context context = new Context();
Runnable runnable = ...
context.put( "key", runnable );
// several computation cycles later...
Executor executor = ...
context.put( "key", executor );
// even more computation cycles later...
Runnable value = ( Runnable )context.get( "key" ); // runtime problem
The cause of such problems can be difficult to trace as the related implementation steps might be spread wide apart in your application. To improve the situation it seems reasonable to bind the value not only to its key but also to its type.
Common mistakes I saw in several solutions following this approach boil down more or less to the following Context
variant:
public class Context {
private final <String, Object> values = new HashMap<>();
public <T> void put( String key, T value, Class<T> valueType ) {
values.put( key, value );
}
public <T> T get( String key, Class<T> valueType ) {
return ( T )values.get( key );
}
[...]
}
Again basic usage might look like this:
Context context = new Context();
Runnable runnable = ...
context.put( "key", runnable, Runnable.class );
// several computation cycles later...
Runnable value = context.get( "key", Runnable.class );
One first glance this code might give the illusion of being more type save as it avoids the down cast in line six. But running the following snippet gets us down to earth as we still run into the ClassCastException
scenario during the assignment in line ten:
Context context = new Context();
Runnable runnable = ...
context.put( "key", runnable, Runnable.class );
// several computation cycles later...
Executor executor = ...
context.put( "key", executor, Executor.class );
// even more computation cycles later...
Runnable value = context.get( "key", Runnable.class ); // runtime problem
So what went wrong?
First of all the down cast in Context#get
of type T
is ineffective as type erasure replaces unbounded parameters with a static cast to Object
. But more important the implementation does not use the type information provided by Context#put
as key. At most it serves as superfluous cosmetic effect.
Typesafe Hetereogeneous Container
Although the last Context
variant did not work out very well it points into the right direction. The question is how to properly parameterize the key? To answer this take a look at a stripped-down implementation according to the typesafe hetereogenous container pattern described by Bloch.
The idea is to use the class
type as key itself. Since Class
is a parameterized type it enables us to make the methods of Context
type safe without resorting to an unchecked cast to T
. A Class
object used in this fashion is called a type token.
public class Context {
private final Map<Class<?>, Object> values = new HashMap<>();
public <T> void put( Class<T> key, T value ) {
values.put( key, value );
}
public <T> T get( Class<T> key ) {
return key.cast( values.get( key ) );
}
[...]
}
Note how the down cast within the Context#get
implementation has been replaced with an effective dynamic variant. And this is how the context can be used by clients:
Context context = new Context();
Runnable runnable ...
context.put( Runnable.class, runnable );
// several computation cycles later...
Executor executor = ...
context.put( Executor.class, executor );
// even more computation cycles later...
Runnable value = context.get( Runnable.class );
This time the client code will work without class cast problems, as it is impossible to exchange a certain key-value pair by one with a different value type.
Where there is light, there must be shadow, where there is shadow there must be light. There is no shadow without light and no light without shadow….*
Bloch mentions two limitations to this pattern. ‘First, a malicious client could easily corrupt the type safety […] by using a class object in its raw form.’ To ensure the type invariant at runtime a dynamic cast can be used within Context#put
.
public <T> void put( Class<T> key, T value ) {
values.put( key, key.cast( value ) );
}
The second limitation is that the pattern cannot be used on non-reifiable types (see Item 25, Effective Java). Which means you can store value types like Runnable
or Runnable[]
but not List<Runnable>
in a type safe manner.
This is because there is no particular class object for List<Runnable>
. All parameterized types refer to the same List.class
object. Hence Bloch points out that there is no satisfactory workaround for this kind of limitation.
But what if you need to store two entries of the same value type? While creating new type extensions just for storage purpose into the type safe container might be imaginable, it does not sound as the best design decision. Using a custom key implementation might be a better approach.
Multiple Container Entries of the Same Type
To be able to store multiple container entries of the same type we could change the Context
class to use a custom key. Such a key has to provide the type information we need for the type safe behaviour and an identifier for distinction of the actual value objects.
A naive key implementation using a String
instance as identifier might look like this:
public class Key<T> {
final String identifier;
final Class<T> type;
public Key( String identifier, Class<T> type ) {
this.identifier = identifier;
this.type = type;
}
}
Again we use the parameterized Class
as hook to the type information. And the adjusted Context
now uses the parameterized Key
instead of Class
:
public class Context {
private final Map<Key<?>, Object> values = new HashMap<>();
public <T> void put( Key<T> key, T value ) {
values.put( key, value );
}
public <T> T get( Key<T> key ) {
return key.type.cast( values.get( key ) );
}
[...]
}
A client would use this version of Context
like this:
Context context = new Context();
Runnable runnable1 = ...
Key<Runnable> key1 = new Key<>( "id1", Runnable.class );
context.put( key1, runnable1 );
Runnable runnable2 = ...
Key<Runnable> key2 = new Key<>( "id2", Runnable.class );
context.put( key2, runnable2 );
// several computation cycles later...
Runnable actual = context.get( key1 );
assertThat( actual ).isSameAs( runnable1 );
Although this snippet works, the implementation is still flawed. The Key
implementation is used as lookup parameter in Context#get
. Using two distinct instances of Key
initialized with the same identifier and class – one instance used with put and the other used with get – would return null
on get
. Which is not what we want.
Luckily this can be solved easily with an appropriate equals
and hashCode
implementation of Key
. That allows the HashMap
lookup to work as expected.
Finally one might provide a factory method for key creation to minimize boilerplate (useful in combination with static imports):
public static Key key( String identifier, Class type ) {
return new Key( identifier, type );
}
Conclusion
‘The normal use of generics, exemplified by the collection APIs, restricts you to a fixed number of type parameters per container. You can get around this restriction by placing the type parameter on the key rather than the container. You can use Class
objects as keys for such typesafe heterogeneous containers’ (Joshua Bloch, Item 29, Effective Java).
Given these closing remarks, there is nothing left to be added except for wishing you good luck mixing apples and pears successfully…
Reference
原文地址:https://www.cnblogs.com/satire/p/15035370.html
- JavaWeb02-CSS,JS(Java真正的全栈开发)
- 数据处理——One-Hot Encoding
- JavaWeb20-文件上传;下载(Java真正的全栈开发)
- 转--每周一个GoLang设计模式之组合模式
- 简单易学的机器学习算法——Softmax Regression
- JavaWeb19-Listener ; Filter
- dataguard归档路径的问题(r7笔记第99天)
- 厚土Go学习笔记 | 34. 一个简单的 web 服务器实现
- JavaWeb18-jquery学习笔记(Java全栈开发)
- 简单易学的机器学习算法——Apriori算法
- 厚土Go学习笔记 | 29. 接口
- MySQL删除数据的简单尝试 (r7笔记第98天)
- 简单易学的机器学习算法——lasso
- 优化算法——差分进化算法(DE)
- java教程
- Java快速入门
- Java 开发环境配置
- Java基本语法
- Java 对象和类
- Java 基本数据类型
- Java 变量类型
- Java 修饰符
- Java 运算符
- Java 循环结构
- Java 分支结构
- Java Number类
- Java Character类
- Java String类
- Java StringBuffer和StringBuilder类
- Java 数组
- Java 日期时间
- Java 正则表达式
- Java 方法
- Java 流(Stream)、文件(File)和IO
- Java 异常处理
- Java 继承
- Java 重写(Override)与重载(Overload)
- Java 多态
- Java 抽象类
- Java 封装
- Java 接口
- Java 包(package)
- Java 数据结构
- Java 集合框架
- Java 泛型
- Java 序列化
- Java 网络编程
- Java 发送邮件
- Java 多线程编程
- Java Applet基础
- Java 文档注释
- Python列表操作最全面总结
- Python 0基础开发游戏:打地鼠(详细教程)VS code版本
- Python经典编程题:字符串替换
- Python字典操作总结
- 纯代码系列:Python实现验证码图片(PIL库经典用法用法,爬虫12306思路)
- Python正则表达式快速学习
- 如何上传项目到GitHub
- MySQL查询优化-基于EXPLAIN
- Python操作SQLite数据库
- Python多进程及多线程基础
- Python字符串三种格式化输出
- 你需要知道的Python代码规范性检查(pylint和flake8)
- Linux下安装python环境
- 【5】进大厂必须掌握的面试题-Java面试-spring
- Python 3.7 自动化接口测试简单实例