blocks|key|2811825|text|为了给出一个快速的答案，而不是深入讨论良好的编程实践...|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2811826|我将使用：|2811827|private+<X>+X+genericGet(String+property)+{

}

public+String+getString(String+property)+{+
//...+checks+on+property+(String+specific)...
Object+obj+=+genericGet(property);
//...+checks+if+obj+is+what+is+expected+and+if+good+return+it
return+obj;+
}

public+Date+getDate(String+property)+{+
//...+checks+on+property+(Date+specific)...
Object+obj+=+genericGet(property);
//...+checks+if+obj+is+what+is+expected+and+if+good+return+it
return+obj
}|code-block|syntax|javascript|2811828|向私有genericGet发出通知。这样，我就可以检查get属性是否是我等待接收的东西，并以正确的方式处理它。|2811829|我可以根据属性在getString依赖中添加检查，以确保答案将是String对象。|2811830|我可以对属性中的getDate做其他检查，以确保它将是将返回的日期。|2811831|等等。|2811832|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

To give a quick answer, without going in deep about good-programming-practice...

I would use:

<pre><code>private &lt;X&gt; X genericGet(String property) {

}

public String getString(String property) { 
//... checks on property (String specific)...
Object obj = genericGet(property);
//... checks if obj is what is expected and if good return it
return obj; 
}

public Date getDate(String property) { 
//... checks on property (Date specific)...
Object obj = genericGet(property);
//... checks if obj is what is expected and if good return it
return obj
}
</code></pre>

make notice to the private genericGet.
This way I can check if the get property is what I m waiting to receive and handle it in a correct way.

I could add checks in the getString depends on the property to make sure that the answer will be a String object.

I could do other checks for getDate in property to make sure it will be a date as will be returned.

Etc...

blocks|key|190791|text|我更喜欢使用泛型转换。为什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|190792|190793|显式转换总是更难维护。当您阅读代码时，您根本不知道此方法可能返回什么。更重要的是，该方法被错误使用并在运行期间出现某些类的可能性相当高，|unordered-list-item|190794|类类型转换更难维护。在我看来，你用这种方式创建了一些可以被称为意大利面式代码的东西，|190795|，|190796|，当你创建像getString和getDate这样的方法时，你给你的类提供了非常清晰的接口。更重要的是，总是可以获得String和Date以外的其他类的对象，因为您还提供了泛型方法。|offset|length|style|CODE|190797|190798|entityMap^0|0|0|0|0|0|6|9|G|7|1M|6|1T|4|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|X|8|@$L|Y|M|Z|N|O]|$L|10|M|11|N|O]|$L|12|M|13|N|O]|$L|14|M|15|N|O]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$]]

I would prefer to use generic cast. Why?

<ul>
<li>The explict cast is always more difficult to maintain. When you read the code you simply don't know what this method might return. What is more, the probability that the method will be used in wrong way and some <code>ClassCastException</code> will ocurr during runtimme is quite high.</li>
<li>Class cast is even more difficult to maintain. In my opinion you create in this way something which might be called as spaghetti code.</li>
<li>When you create methods like <code>getString</code> and <code>getDate</code> you give very clear interface to your class. What is more it's always possible to get objects of other classes than <code>String</code> and <code>Date</code> because you provide also the generic method.</li>
</ul>

blocks|key|192933|text|正如您已经提到的，上述所有方法都是危险的，并且可能会在运行时导致ClassCastException。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|192934|如果确实有必要，我更喜欢的“泛型转换”方法，因为它使接口显式和自扩展(在本例中，将genericGet设置为私有)。当然，您必须为容器中的每个class创建样板代码。因此，'Class.cast'的优点是您不需要这些样板方法。|BOLD|192935|结论:如果容器中有定义良好的类数量，我会选择“泛型转换”。如果你需要支持无数的类，我建议使用‘Class.cast’。|192936|更新：‘显式转换’确实有一个优点--调用者(容器的用户)会得到一个提醒，即存在类转换风险！|192937|只是一个观点..。|192938|entityMap^0|W|I|0|C|7|2E|C|15|A|1Z|5|0|0|3|6|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@$9|U|A|V|B|H]|$9|W|A|X|B|H]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|I|3|J|5|6|7|12|8|@]|D|@]|E|$]]|$1|K|3|L|5|6|7|13|8|@$9|14|A|15|B|H]]|D|@]|E|$]]|$1|M|3|N|5|6|7|16|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|P|$]]

As you already mentioned all of the above approaches are dangerous and may lead to <code>ClassCastException</code>s during runtime. 

If it is really necessary I'd prefer the 'generic cast' approach as it makes the interface explicit and self-expanatory (make the <code>genericGet</code> private in this case). Of course you have to create boilderplate code for each <code>class</code> in your container. So the advantage of 'Class.cast' is that you do not need those boilerplate methods.

Conclusion: If there is a well-defined number of classes in the container I'd go with 'generic cast'. In case you are required to support an endless number of classes I'd go with ' Class.cast'

Update: 'Explicit Cast' does have one advantage - the caller (user of the container) gets a reminder that there is a class-cast risk!

Just an opinion...

blocks|key|192946|text|就我个人而言，将许多不同的对象放在一个地方，然后检查您想要返回的内容似乎有点错误。也许你可以将持有者存储在那个BadlyCreatedClass中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|192947|类似于：|192948|class+Holder+{
++++private+long+id;
++++private+String+name;
++++private+Date+dateofBirth;

++++//getters+and+setters
}|code-block|syntax|javascript|192949|然后根据id进行检索，因此不需要强制转换。|192950|你也可以告诉我们你想做什么。|192951|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Personally, keeping lots of different objects in a single place and then checking what you want to return seems a bit wrong. May be you can store Holders in that BadlyCreatedClass.

Something like:

<pre><code>class Holder {
 private long id;
 private String name;
 private Date dateofBirth;

 //getters and setters
}
</code></pre>

Then retrieve based on id, no casting thus required.

You could also tell us what you are trying to do.

blocks|key|3024638|text|因为所有选项都涉及类型转换，所以它们都以某种方式“不安全”，并且可能在ClassCastExceptions中失败。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3024639|我绝对推荐使用像getString()、getDate()这样的帮助器方法来处理通常存储在这个对象中的常见类型。这些方法对于所有三个选项都很有用，因为这样可以减少对象的用户必须编写的代码。|3024640|但是你仍然需要一种方法从你的对象接收“不常见的”类型。为此，我会使用显式强制转换或类强制转换。原因是我认为这两种方式是最常用的。即使泛型方法调用可以很好地工作，我认为像obj.genericGet<String>("myproperty");这样的方法调用并不是每个java开发人员都知道的。这在实践中是很少见的。|3024641|我个人认为，即使我不喜欢将类型转换移动到对象的用户，也会将getObject()方法添加到帮助器方法中。这样做的好处是你将有一个一致的接口，如果我看到像getString()或getDate()这样的方法，这就是我所期望的。|3024642|entityMap^0|Z|J|0|8|B|K|9|0|2C|11|0|T|B|24|B|2G|9|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|M|$]]

Because all options involve a type cast they are all somehow "insecure" and can fail with <code>ClassCastExceptions</code>.

I would definitely recommend to use helper methods like <code>getString()</code>, <code>getDate()</code> for common types that are often stored within this object. These methods are useful with all three options because the reduce the code the user of the object has to write.

But you still need a way to receive "uncommon" types from your object. For this I would go with the explicit cast or the class cast. The reason for this is that I think that these two ways are the ones that are mostly used. Even if the generic method call would work fine I think method calls like <code>obj.genericGet&lt;String&gt;("myproperty");</code> are something not every java developers is aware of. It is rarely seen in practice. 

Personally is would add an <code>getObject()</code> method to the helper methods even if I don't like to move the type cast to the user of the object. The advantage of this is that you would have a consistent interface and this is what I would expect if I see methods like <code>getString()</code> or <code>getDate()</code>.

blocks|key|192978|text|泛型强制转换方法会导致编译器发出未经检查的警告。未经检查的警告表明，在运行时没有(完全)检查强制转换，即，即使值不是正确的类型，它也可能成功。这可能导致变量保存的值与其声明的类型不兼容，这种情况被Java+Language+Specification称为heap+pollution。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|192979|下面的程序演示了这一点：|192980|class+Holder+{
++++Object+value;

++++Holder(Object+value)+{
++++++++this.value+=+value;
++++}

++++<T>+T+get()+{
++++++++return+(T)+value;
++++}
}

class+C<T>+{
++++T+value;

++++C(Holder+h)+{
++++++++value+=+h.get();
++++}
}

public+class+Test+{
++++public+static+void+main(String+[]+args)+throws+IOException+{
++++++++Holder+holder+=+new+Holder("Hello");
++++++++C<Integer>+c+=+new+C<Integer>(holder);
++++++++System.out.println("I+just+put+a+String+into+a+variable+of+type+Integer");

++++++++//+much+later,+possibly+in+a+different+part+of+your+program
++++++++c.value.longValue();+//+throws+ClassCastException
++++}
}|code-block|syntax|javascript|192981|因此，我强烈建议使用检查类型转换。检查普通类型转换(第一种方法)和反射类型转换(第三种方法)。但是，反射强制转换不适用于参数化类型(List<String>.class无法编译...)。|style|CODE|192982|因此，最简单和最灵活的安全解决方案是普通的强制转换。|192983|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.2^0|3J|E|0|0|0|0|1U|I|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|14|8|@$A|15|B|16|M|N]]|9|@]|C|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|18|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

The generic cast approach causes the compiler to emit an unchecked warning. An unchecked warning indicates that the cast is question is not (fully) checked at runtime, i.e. it may succeed, even if the value is not of the proper type. This can cause a variable to hold a value not compatible with its declared type, a situation the Java Language Specification calls <a href="http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.2" rel="nofollow">heap pollution</a>.

The following program demonstrates this:

<pre><code>class Holder {
 Object value;

 Holder(Object value) {
 this.value = value;
 }

 &lt;T&gt; T get() {
 return (T) value;
 }
}

class C&lt;T&gt; {
 T value;

 C(Holder h) {
 value = h.get();
 }
}

public class Test {
 public static void main(String [] args) throws IOException {
 Holder holder = new Holder("Hello");
 C&lt;Integer&gt; c = new C&lt;Integer&gt;(holder);
 System.out.println("I just put a String into a variable of type Integer");

 // much later, possibly in a different part of your program
 c.value.longValue(); // throws ClassCastException
 }
}
</code></pre>

Therefore, I strongly recommend using a checked cast. Both the ordinary cast (your first approach), and the reflective cast (your third approach) are checked. However, the reflective cast will not work with parametrized types (<code>List&lt;String&gt;.class</code> doesn't compile ...). 

The simplest and most flexible safe solution therefore is the ordinary cast.

I have a badly created container object that holds together values of different java types(String, Boolean etc ..)

<pre><code>public class BadlyCreatedClass {
 public Object get(String property) {
 ...;
 }
};
</code></pre>

And we extract values from it in this way

<pre><code>String myStr = (String) badlyCreatedObj.get("abc");
Date myDate = (Date) badlyCreatedObj.get("def");
</code></pre>

I am forced to write some new code using this object and I am trying to see if there is clean way to do this. More specifically which method from the below is preferred ?

Explicit Cast

<pre><code>String myStr = (String) badlyCreatedObj.get("abc")
Date myDate = (Date) badlyCreatedObj.get("def");
</code></pre>

Using generic cast

<pre><code>public &lt;X&gt; X genericGet(String property) {

}

public String getString(String property) { 
return genericGet(property); 
}

public Date getDate(String property) { 
return genericGet(property); 
}
</code></pre>

Using Class.cast

<pre><code>&lt;T&gt; T get(String property, Class&lt;T&gt; cls) {
 ;
}
</code></pre>

I have gone through several related questions on SO <a href="https://stackoverflow.com/questions/1959022/java-generic-function-how-to-return-generic-type">Java generic function: how to return Generic type</a> , <a href="https://stackoverflow.com/questions/2669326/java-generic-return-type">Java generic return type</a> all of them seem to say the such typecasting is dangerous, ALthough I dont see much difference between the three, given this which method would you prefer ?

Thanks

Java generics and typecasting

编译器

容器

Java

我有一个错误创建的容器对象，它将不同java类型(字符串、布尔值等)的值保存在一起。public class BadlyCreatedClass {    public Object get(String property) {        ...;    }};我们以这种方式从其中提取值String myStr =...

问Java泛型和类型转换
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java泛型和类型转换EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java泛型和类型转换
EN