제네릭, 와일드카드

간단히 말해 치환형: 이거 없으면 매서드 오버로딩을 몇번을 해야되는거야.

 

로직이 비슷하고 여러 타입에대한 로직을 적용해야할때 사용하면 유용함.

//제네릭 정의
public calss Box<T>{
	public T content;
    public String toString(){
    	return content.toString();
    }
}
// 이처럼 일반적이고 타입에 종속받을 필요가 없을때 일반적인 로직
// 걍 T로 치환해버린다. 어차피 Object의 toString은 뭔타입이든 상관 XXX

//==========================================================

//제네릭 타입(클래스 or 인터페이스)
//뜬금없는 용어지만, 저런식으로 제네릭을 선언하여 사용하면 걔네들 이름이
//제네릭 타입임...

//제네릭 메소드
//클래스가 제네릭타입이라 해당 제네릭을 막 쓰는거 말고.
//메서드한테도 자체 제네릭을 달아 줄 수 가 잇음.
public calss Box<T>{
	public T t;
    public String toString(){
    	return t.toString();
    }
    
    //이건 제네릭타입에 의존하는 형태
    public T get(){
    	return t;
    }
    public void set(T t){
    	this.t = t;
    }
    //찐 제네릭 메서드
    public <K> Box<K> boxing(K k){
    	Box<K> box = new Box<K>();
        box.set(k);
        return box;
    }
}
//사용예
public Static void main(){
	//제네릭 타입 클래스를 통한 생성
	Box<Integer> box1 = new Box<>();
    box1.set(100);
    
    //제네릭 매서드를 이용한 리턴
    Box<Integer> box2 = box1.boxing(200);
}

//보기 쉬우라고 T와 K를 구분했지만, 
//제네릭의 범위는 public <제네릭> 리턴값 매소드명 을 사용한 이상
//어차피 다른 범위라고 치부하기 때문에 T 랑 T를 써도 된다. (실험함)
//다만 가독성은 스타일 알아서..

---

제네릭 타입의 범위를 아무거나 쓰도록 하는건 구현의 한계가 있음..

제네릭 아무거나 썼다가... 걍 쓰레드의 매서드인 start() 때린다고 그게 때려지겠나.. 

그래서 특정 함수나 필드를 참조해서 막 가져다 쓰고 싶은 욕구에 의해 제네릭타입 범위 지정하는

로직이 나왔다고 생각함. 그게 이유라고 생각함.

 

<T extends System> 해버리는 순간 실제 System을 상속한 변수만 매칭시킬수 있으며
System의 함수나 필드를 사용 가능하다 내부적으로!!

 

---

더 발전된 개념 와일드 카드 타입 "파라미터" <- 파라미터야!! 

1. 쓸 수 있는 범위를 좁힌다는 의도에 + extends 인지 super인지를 구별할 수 있음.
2. 제일 간과하는거 와일드카드는 메서드 타입에만 사용 가능하다는거! 이걸 알아야 다음 이해가 빠름

3. 타입제한 제네릭은 해당 타입을 상속한 애들만 치환해서 받을 수 있어!

4. 와일드카드는 이미 만들어진 녀석을 어떻게 제한하고 어떻게 처리할래? 타입치환보다 처리에 중점을 둠

5. 매서드의 책임이. 해당 파라미터를 가져와서 사용할래(R). 즉 제공해주는 역할인 제공자야. 라고생각하면

PE: Producer Extends

6. 매서드의 책임이. 해당 파라미터를 가져와서 조작할래.(CUD) 즉 뭔갈 넘겨줘야되는 소비자야. 라고 생각하면

CS: Consumer Super