blocks|key|3242016|text|第二种方法有点冗长，但它允许您在其中引用T：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3242017|for+(T+shape+:+shapes)+{
++++...
}|code-block|syntax|javascript|3242018|据我所知，这是唯一的区别。|3242019|entityMap^0|K|1|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

The second way is a bit more verbose, but it allows you to refer <code>T</code> inside it: 

<pre><code>for (T shape : shapes) {
 ...
}
</code></pre>

That's the only difference, as far as I understand.

blocks|key|300285|text|这取决于你需要做什么。如果要执行以下操作，则需要使用绑定类型参数：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|300286|public+<T+extends+Shape>+void+addIfPretty(List<T>+shapes,+T+shape)+{
++++if+(shape.isPretty())+{
+++++++shapes.add(shape);
++++}
}|code-block|syntax|javascript|300287|这里我们有一个List<T>+shapes和一个T+shape，因此我们可以安全地shapes.add(shape)。如果它被声明为List<?+extends+Shape>，您就不能安全地add到它(因为您可能有一个List<Square>和一个Circle)。|offset|length|style|CODE|300288|因此，通过为一个有界类型参数命名，我们可以选择在我们的泛型方法中的其他地方使用它。当然，这些信息并不总是必需的，所以如果你不需要知道太多关于类型的信息(例如你的drawAll)，那么通配符就足够了。|300289|即使您不再引用有界类型参数，如果您有多个边界，则仍然需要有一个有界类型参数。下面是Angelika+Langer's+Java+Generics+FAQs的一句话|300290|300291|+通配符绑定和类型参数绑定有什么区别？|blockquote|BOLD|300292|300293|通配符只能有一个界限，而类型参数可以有多个界限。通配符可以有下限，也可以有上限，而类型参数没有下限。通配符界限和类型参数界限经常被混淆，因为它们都被称为界限，并且在某种程度上具有相似的语法。…|300294|语法：|300295|类型参数绑定T扩展了类&+Interface1+&…&+InterfaceN通配符界限上限？扩展了SuperType的下界？超级SubType|300296|通配符只能有一个界限，可以是下界，也可以是上界。不允许使用通配符界限列表。|300297|在constrast中，一个类型参数可以有几个界限，但没有类型参数的下限。|300298|300299|引用自Effective+Java第二版，第28项:使用有界通配符增加API灵活性|300300|300301|为了获得最大的灵活性，请在表示生产者或消费者的输入参数上使用通配符类型。…PECS代表producer-extends，consumer-super…|300302|300303|不使用通配符类型作为返回类型。它将强制用户在客户端代码中使用通配符类型，而不是为用户提供额外的灵活性。如果使用得当，类的用户几乎看不到通配符类型。它们导致方法接受它们应该接受的参数，并拒绝它们应该拒绝的参数。如果类的用户必须考虑通配符类型，那么类的接口可能有问题。|300304|300305|应用PECS原则，我们现在可以返回到我们的addIfPretty示例，并通过编写以下代码使其更加灵活：|300306|public+<T+extends+Shape>+void+addIfPretty(List<?+super+T>+list,+T+shape)+{+…+}|300307|现在我们可以addIfPretty，比方说，Circle，to+a+List<Object>。这显然是类型安全的，但我们的原始声明还不够灵活，不能允许它。|300308|相关问题|300309|300310|Java+Generics:+What+is+PECS?|unordered-list-item|300311|Can+someone+explain+what+does++mean+and+when+should+it+be+used+and+how+this+construction+should+cooperate+with++and+?|300312|300313|300314|摘要|300315|如果类型需要多个参数，您别无选择，只能使用绑定类型参数|300316|如果类型需要下界，则别无选择，只能使用有界类型有上界，“lowerbounds|300317|
|300318|Do”|300319|300320|+in+|300321|types|300322|300323|300324|300325|entityMap|0|LINK|mutability|MUTABLE|url|http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeArguments.html#FAQ203|1|https://stackoverflow.com/questions/2723397/java-generics-what-is-pecs|2|https://stackoverflow.com/questions/2310449/can-someone-explain-what-does-super-t-mean-and-when-should-it-be-used-and-how^0|0|0|7|E|O|7|15|H|1U|L|2N|3|31|C|3G|6|0|28|7|0|15|10|0|0|0|1|I|0|0|0|0|2|0|0|0|0|0|0|0|1G|7|1X|5|0|0|0|E|3G|2|0|0|L|B|0|0|6|B|M|6|Y|C|0|0|0|0|S|1|0|0|39|2|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|2R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|2S|8|@$I|2T|J|2U|K|L]|$I|2V|J|2W|K|L]|$I|2X|J|2Y|K|L]|$I|2Z|J|30|K|L]|$I|31|J|32|K|L]|$I|33|J|34|K|L]|$I|35|J|36|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|37|8|@$I|38|J|39|K|L]]|9|@]|A|$]]|$1|O|3|P|5|6|7|3A|8|@]|9|@$I|3B|J|3C|1|3D]]|A|$]]|$1|Q|3|-4|5|6|7|3E|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|3F|8|@$I|3G|J|3H|K|U]]|9|@]|A|$]]|$1|V|3|-4|5|6|7|3I|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|3J|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|3K|8|@$I|3L|J|3M|K|U]]|9|@]|A|$]]|$1|10|3|11|5|6|7|3N|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|3O|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|3P|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|3Q|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|3R|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|3S|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|T|7|3T|8|@$I|3U|J|3V|K|L]|$I|3W|J|3X|K|L]]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|3Y|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|3Z|8|@$I|40|J|41|K|U]|$I|42|J|43|K|U]]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|44|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|45|8|@$I|46|J|47|K|L]]|9|@]|A|$]]|$1|1I|3|1J|5|D|7|48|8|@]|9|@]|A|$E|F]]|$1|1K|3|1L|5|6|7|49|8|@$I|4A|J|4B|K|L]|$I|4C|J|4D|K|L]|$I|4E|J|4F|K|L]]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|4G|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|4H|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|1R|7|4I|8|@]|9|@$I|4J|J|4K|1|4L]]|A|$]]|$1|1S|3|1T|5|1R|7|4M|8|@]|9|@$I|4N|J|4O|1|4P]]|A|$]]|$1|1U|3|-4|5|6|7|4Q|8|@]|9|@]|A|$]]|$1|1V|3|-4|5|6|7|4R|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|6|7|4S|8|@]|9|@]|A|$]]|$1|1Y|3|1Z|5|6|7|4T|8|@]|9|@]|A|$]]|$1|20|3|21|5|1R|7|4U|8|@]|9|@]|A|$]]|$1|22|3|23|5|6|7|4V|8|@]|9|@]|A|$]]|$1|24|3|25|5|1R|7|4W|8|@]|9|@]|A|$]]|$1|26|3|-4|5|1R|7|4X|8|@]|9|@]|A|$]]|$1|27|3|28|5|1R|7|4Y|8|@]|9|@]|A|$]]|$1|29|3|2A|5|6|7|4Z|8|@]|9|@]|A|$]]|$1|2B|3|-4|5|1R|7|50|8|@]|9|@]|A|$]]|$1|2C|3|-4|5|6|7|51|8|@]|9|@]|A|$]]|$1|2D|3|-4|5|6|7|52|8|@]|9|@]|A|$]]|$1|2E|3|-4|5|6|7|53|8|@]|9|@]|A|$]]]|2F|$2G|$5|2H|2I|2J|A|$2K|2L]]|2M|$5|2H|2I|2J|A|$2K|2N]]|2O|$5|2H|2I|2J|A|$2K|2P]]]]

It depends on what you need to do. You need to use the bounded type parameter if you wanted to do something like this:

<pre><code>public &lt;T extends Shape&gt; void addIfPretty(List&lt;T&gt; shapes, T shape) {
 if (shape.isPretty()) {
 shapes.add(shape);
 }
}
</code></pre>

Here we have a <code>List&lt;T&gt; shapes</code> and a <code>T shape</code>, therefore we can safely <code>shapes.add(shape)</code>. If it was declared <code>List&lt;? extends Shape&gt;</code>, you can NOT safely <code>add</code> to it (because you may have a <code>List&lt;Square&gt;</code> and a <code>Circle</code>).

So by giving a name to a bounded type parameter, we have the option to use it elsewhere in our generic method. This information is not always required, of course, so if you don't need to know that much about the type (e.g. your <code>drawAll</code>), then just wildcard is sufficient.

Even if you're not referring to the bounded type parameter again, a bounded type parameter is still required if you have multiple bounds. Here's a quote from <a href="http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeArguments.html#FAQ203" rel="noreferrer">Angelika Langer's Java Generics FAQs</a>

<blockquote>
 What is the difference between a wildcard bound and a type parameter bound?
 
 A wildcard can have only one bound, while a type parameter can have several bounds. 
 A wildcard can have a lower or an upper bound, while there is no such thing as a lower bound for a type parameter. 
 
 Wildcard bounds and type parameter bounds are often confused, because they are both called bounds and have in part similar syntax. […]
 
 Syntax:

<pre><code> type parameter bound T extends Class &amp; Interface1 &amp; … &amp; InterfaceN

 wildcard bound 
 upper bound ? extends SuperType
 lower bound ? super SubType
</code></pre>
 
 A wildcard can have only one bound, either a lower or an upper bound. A list of wildcard bounds is not permitted. 
 
 A type parameter, in constrast, can have several bounds, but there is no such thing as a lower bound for a type parameter. 
</blockquote>

Quotes from Effective Java 2nd Edition, Item 28: Use bounded wildcards to increase API flexibility:

<blockquote>
 For maximum flexibility, use wildcard types on input parameters that represent producers or consumers. […] PECS stands for producer-<code>extends</code>, consumer-<code>super</code> […]
 
 Do not use wildcard types as return types. Rather than providing additional flexibility for your users, it would force them to use wildcard types in client code. Properly used, wildcard types are nearly invisible to users of a class. They cause methods to accept the parameters they should accept and reject those they should reject. If the user of the class has to think about wildcard types, there is probably something wrong with the class's API.
</blockquote>

Applying the PECS principle, we can now go back to our <code>addIfPretty</code> example and make it more flexible by writing the following:

<pre><code>public &lt;T extends Shape&gt; void addIfPretty(List&lt;? super T&gt; list, T shape) { … }
</code></pre>

Now we can <code>addIfPretty</code>, say, a <code>Circle</code>, to a <code>List&lt;Object&gt;</code>. This is obviously typesafe, and yet our original declaration was not flexible enough to allow it.

<h3>Related questions</h3>

<ul>
<li><a href="https://stackoverflow.com/questions/2723397/java-generics-what-is-pecs">Java Generics: What is PECS?</a></li>
<li><a href="https://stackoverflow.com/questions/2310449/can-someone-explain-what-does-super-t-mean-and-when-should-it-be-used-and-how">Can someone explain what does <code>&lt;? super T&gt;</code> mean and when should it be used and how this construction should cooperate with <code>&lt;T&gt;</code> and <code>&lt;? extends T&gt;</code>?</a></li>
</ul>

<hr>

<h3>Summary</h3>

<ul>
<li>Do use bounded type parameters/wildcards, they increase flexibility of your API</li>
<li>If the type requires several parameters, you have no choice but to use bounded type parameter</li>
<li>if the type requires a lowerbound, you have no choice but to use bounded wildcard</li>
<li>"Producers" have upperbounds, "consumers" have lowerbounds</li>
<li>Do not use wildcard in return types</li>
</ul>

blocks|key|3242073|text|在您的示例中，您实际上不需要使用T，因为您在其他任何地方都不使用该类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3242074|但是如果你做了类似这样的事情：|3242075|public+<T+extends+Shape>+T+drawFirstAndReturnIt(List<T>+shapes){
++++T+s+=+shapes.get(0);
++++s.draw(this);
++++return+s;
}|code-block|syntax|javascript|3242076|或者像多基因润滑剂所说的，如果你想将列表中的类型参数与另一个类型参数相匹配：|3242077|public+<T+extends+Shape>+void+mergeThenDraw(List<T>+shapes1,+List<T>+shapes2)+{
++++List<T>+mergedList+=+new+ArrayList<T>();
++++mergedList.addAll(shapes1);
++++mergedList.addAll(shapes2);
++++for+(Shape+s:+mergedList)+{
++++++++s.draw(this);
++++}
}|3242078|在第一个示例中，您获得了比仅返回形状更多的类型安全性，因为您可以将结果传递给可能接受Shape的子级的函数。例如，您可以将一个List<Square>传递给我的方法，然后将结果Square传递给一个只接受Square的方法。如果你使用'?‘您将不得不将结果形状强制转换为Square，这将不是类型安全的。|offset|length|style|CODE|3242079|在第二个示例中，您将确保两个列表具有相同的类型参数(不能使用'?'，因为每个列表都有'?‘是不同的)，这样您就可以创建一个包含这两个元素的所有元素的列表。|3242080|entityMap^0|0|0|0|0|0|1R|C|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|11|8|@$O|12|P|13|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

In your example you don't really need to use T, since you don't use that type anywhere else.

But if you did something like:

<pre><code>public &lt;T extends Shape&gt; T drawFirstAndReturnIt(List&lt;T&gt; shapes){
 T s = shapes.get(0);
 s.draw(this);
 return s;
}
</code></pre>

or like polygenlubricants said, if you want to match the type parameter in the list with another type parameter:

<pre><code>public &lt;T extends Shape&gt; void mergeThenDraw(List&lt;T&gt; shapes1, List&lt;T&gt; shapes2) {
 List&lt;T&gt; mergedList = new ArrayList&lt;T&gt;();
 mergedList.addAll(shapes1);
 mergedList.addAll(shapes2);
 for (Shape s: mergedList) {
 s.draw(this);
 }
}
</code></pre>

In the first example you get a bit more type safety then returning just Shape, since you can then pass the result to a function that may take a child of Shape. For example you may pass a <code>List&lt;Square&gt;</code> to my method, and then pass the resulting Square to a method that only takes Squares. If you used '?' you would have to cast the resulting Shape to Square which would not be type safe.

In the second example you ensure that both lists have the same type parameter (which you can't do with '?', since each '?' is different), so that you can create a list that contains all elements from both of them.

blocks|key|299837|text|考虑下面James+Gosling第四版的Java+Programming中的示例，其中我们想要合并2个SinglyLinkQueue：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|299838|public+static+<T1,+T2+extends+T1>+void+merge(SinglyLinkQueue<T1>+d,+SinglyLinkQueue<T2>+s){
++++//+merge+s+element+into+d
}

public+static+<T>+void+merge(SinglyLinkQueue<T>+d,+SinglyLinkQueue<?+extends+T>+s){
++++++++//+merge+s+element+into+d
}|code-block|syntax|javascript|299839|上述两种方法都具有相同的功能。那么哪一个更可取呢？答案是第二个。用作者自己的话说：|299840|“一般规则是尽可能使用通配符，因为使用通配符的代码通常比具有多个类型参数的代码更具可读性。在决定是否需要类型变量时，请问问自己，该类型变量是用于关联两个或多个参数，还是用于关联参数类型和返回类型。如果答案是否定的，则通配符应该就足够了。”|offset|length|style|BOLD|299841|注意:在书中只给出了第二种方法，类型参数名称是S而不是'T‘。书中没有介绍第一种方法。|299842|entityMap^0|0|0|0|0|3B|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@$K|W|L|X|M|N]]|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|$]]

Consider following example from The Java Programming by James Gosling 4th edition below where we want to merge 2 SinglyLinkQueue:

<pre><code>public static &lt;T1, T2 extends T1&gt; void merge(SinglyLinkQueue&lt;T1&gt; d, SinglyLinkQueue&lt;T2&gt; s){
 // merge s element into d
}

public static &lt;T&gt; void merge(SinglyLinkQueue&lt;T&gt; d, SinglyLinkQueue&lt;? extends T&gt; s){
 // merge s element into d
}
</code></pre>

Both of the above methods have the same functionality. So which is preferable? Answer is 2nd one. In the author's own words : 

"The general rule is to use wildcards when you can because code with wildcards
is generally more readable than code with multiple type parameters. When deciding if you need a type
variable, ask yourself if that type variable is used to relate two or more parameters, or to relate a parameter
type with the return type. If the answer is no, then a wildcard should suffice." 

Note: In book only second method is given and type parameter name is S instead of 'T'. First method is not there in the book.

blocks|key|3242163|text|据我所知，在不需要类型参数的情况下，通配符允许更简洁的代码(例如，因为它在几个地方被引用，或者因为需要多个边界，如其他答案中详细描述的那样)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3242164|在链接中，您指出我(在“泛型方法”下)阅读了以下提示此方向的语句：|3242165|3242166|泛型方法允许使用类型参数来表达方法和/或其返回类型的一个或多个参数的类型之间的依赖关系。如果没有这样的依赖，就不应该使用泛型方法。|blockquote|3242167|3242168|..。|3242169|使用通配符比声明显式类型参数更清晰、更简洁，因此应尽可能首选通配符。|3242170|3242171|通配符还有一个优点，即它们可以在方法签名之外使用，作为字段、局部变量和数组的类型。|3242172|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|X|8|@]|9|@]|A|$]]|$1|M|3|J|5|6|7|Y|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Z|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|Q|$]]

As far as I understand, the wildcard allows for more concise code in situations where a type parameter is not required (e.g. because it's referenced at several places or because multiple bounds are required as detailed in other answers).

In the link you indicate I read (under "Generic Methods") the following statements which hint in this direction:

<blockquote>
 Generic methods allow type parameters to be used to express
 dependencies among the types of one or more arguments to a method
 and/or its return type. If there isn't such a dependency, a generic
 method should not be used.
 
 [...]
 
 Using wildcards is clearer and more concise than declaring explicit
 type parameters, and should therefore be preferred whenever possible.
 
 [...]
 
 Wildcards also have the advantage that they can be used outside of
 method signatures, as the types of fields, local variables and arrays.
</blockquote>

Recently, I read this article:
<a href="http://download.oracle.com/javase/tutorial/extra/generics/wildcards.html" rel="noreferrer">http://download.oracle.com/javase/tutorial/extra/generics/wildcards.html</a>

My question is, instead of creating a method like this:

<pre><code>public void drawAll(List&lt;? extends Shape&gt; shapes){
 for (Shape s: shapes) {
 s.draw(this);
 }
}
</code></pre>

I can create a method like this, and it works fine:

<pre><code>public &lt;T extends Shape&gt; void drawAll(List&lt;T&gt; shapes){
 for (Shape s: shapes) {
 s.draw(this);
 }
}
</code></pre>

Which way should I use? Is wildcard useful in this case?

Java: bounded wildcards or bounded type parameter?

Java

最近，我读到了这篇文章：我的问题是，与其创建这样的方法，不如：public void drawAll(List<? extends Shape> shapes){ for (Shape s: shapes) { s.draw(this); }}我可以创建一个这样的方法，它工作得很好：publi...

问Java:有界通配符还是有界类型参数？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java:有界通配符还是有界类型参数？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java:有界通配符还是有界类型参数？
EN