와일드카드 사용 지침 Guidelines for Wildcard Use
제네릭을 가진 프로그래밍을 배울 때 보다 더 혼란스러운 측면 중 하나는 언제 상위 경계 와일드카드를 사용하는 지와 언제 하위 경계 와일드카드를 사용하는 지를 결정하고 것입니다.
이 페이지는 코드를 디자인 할 때 따라야 할 몇 가지 지침을 제공합니다.
이 논의의 목적을 위해, 변수를 2개의 함수 중 하나를 제공하는 것이 생각하는 것이 도움이 됩니다:
One of the more confusing aspects when learning to program with generics is determining when to use an upper bounded wildcard and when to use a lower bounded wildcard. This page provides some guidelines to follow when designing your code.
For purposes of this discussion, it is helpful to think of variables as providing one of two functions:
- 변수 "In" An "In" Variable
- "in" variable는 코드에 데이터를 serves up합니다.
2개의 arguments를 가진 copy메소드(copy(src, dest)를 상상해보십시오. - src argument는 copy될 데이터를 제공하기 때문에 그것은 "in" parameter입니다.
An "in" variable serves up data to the code. Imagine a copy method with two arguments: copy(src, dest). The src argument provides the data to be copied, so it is the "in" parameter. - 변수 "Out" An "Out" Variable
- 변수 "out"은 다른 곳에서 사용할 데이터를 보유합니다.
copy 예제 copy(src, dest)에서, dest argument는 데이터를 수용하기 때문에 그것은 "out" parameter입니다.
An "out" variable holds data for use elsewhere. In the copy example, copy(src, dest), the dest argument accepts data, so it is the "out" parameter.
Of course, some variables are used both for "in" and "out" purposes — this scenario is also addressed in the guidelines.
You can use the "in" and "out" principle when deciding whether to use a wildcard and what type of wildcard is appropriate. The following list provides the guidelines to follow:
Wildcard Guidelines:
- An "in" variable is defined with an upper bounded wildcard, using the extends keyword.
- An "out" variable is defined with a lower bounded wildcard, using the super keyword.
- In the case where the "in" variable can be accessed using methods defined in the Object class, use an unbounded wildcard.
- In the case where the code needs to access the variable as both an "in" and an "out" variable, do not use a wildcard.
These guidelines do not apply to a method's return type. Using a wildcard as a return type should be avoided because it forces programmers using the code to deal with wildcards.
A list defined by List<? extends ...> can be informally thought of as read-only, but that is not a strict guarantee. Suppose you have the following two classes:
class NaturalNumber { private int i; public NaturalNumber(int i) { this.i = i; } // ... } class EvenNumber extends NaturalNumber { public EvenNumber(int i) { super(i); } // ... }
Consider the following code:
List<EvenNumber> le = new ArrayList<>(); List<? extends NaturalNumber> ln = le; ln.add(new NaturalNumber(35)); // compile-time error
Because List<EvenNumber> is a subtype of List<? extends NaturalNumber>, you can assign le to ln. But you cannot use ln to add a natural number to a list of even numbers. The following operations on the list are possible:
- You can add null.
- You can invoke clear.
- You can get the iterator and invoke remove.
- You can capture the wildcard and write elements that you've read from the list.
You can see that the list defined by List<? extends NaturalNumber> is not read-only in the strictest sense of the word, but you might think of it that way because you cannot store a new element or change an existing element in the list.
« DopZaClub »
'Java 배우기' 카테고리의 다른 글
Erasure of Generic Types 제네릭 타입의 이레이저 (0) | 2016.01.24 |
---|---|
Type Erasure 이레이저 타입 (0) | 2016.01.24 |
Wildcard Capture and Helper Methods 와일드카드 캡처 및 헬퍼 메소스 (0) | 2016.01.24 |
Wildcards and Subtyping 와일드카드 및 서브타이핑 (0) | 2016.01.24 |
Lower Bounded Wildcards 로우여 바운디드 와일드카드 (0) | 2016.01.24 |
댓글