developer tip

제네릭의 멋진 점은 무엇이며 왜 사용합니까?

copycodes 2020. 10. 6. 08:23
반응형

제네릭의 멋진 점은 무엇이며 왜 사용합니까?

나는이 소프트볼을 공원에서 치고 싶은 사람에게 줄 것이라고 생각했다. 제네릭이란 무엇이며 제네릭의 장점은 무엇이며 왜, 어디서, 어떻게 사용해야합니까? 상당히 기본적으로 유지하십시오. 감사.

  • 형식이 안전한 코드 / 사용 라이브러리 메서드를 작성할 수 있습니다. 즉, List <string>은 문자열 목록이 보장됩니다.
  • 제네릭이 사용 된 결과 컴파일러는 유형 안전성을 위해 코드에서 컴파일 타임 검사를 수행 할 수 있습니다. 즉, 문자열 목록에 int를 넣으려고합니까? ArrayList를 사용하면 덜 투명한 런타임 오류가 발생합니다.
  • boxing / unboxing (.net이 값 유형을 참조 유형으로 또는 그 반대로 변환해야하는 경우 )을 피하거나 객체에서 필요한 참조 유형으로 캐스트 하는 것을 방지하므로 객체를 사용하는 것보다 빠릅니다 .
  • 동일한 기본 동작을 가진 많은 유형에 적용 할 수있는 코드를 작성할 수 있습니다. 즉, Dictionary <string, int>는 Dictionary <DateTime, double>과 동일한 기본 코드를 사용합니다. 제네릭을 사용하여 프레임 워크 팀은 앞서 언급 한 이점과 함께 두 가지 결과를 모두 달성하기 위해 하나의 코드 만 작성하면되었습니다.

반복하는 게 정말 싫어요. 나는 내가해야하는 것보다 더 자주 같은 것을 타이핑하는 것을 싫어한다. 나는 약간의 차이를 가지고 여러 번 재조정하는 것을 좋아하지 않습니다.

만드는 대신 :

class MyObjectList  {
   MyObject get(int index) {...}
}
class MyOtherObjectList  {
   MyOtherObject get(int index) {...}
}
class AnotherObjectList  {
   AnotherObject get(int index) {...}
}

재사용 가능한 클래스를 하나 만들 수 있습니다 ... (어떤 이유로 원시 컬렉션을 사용하지 않으려는 경우)

class MyList<T> {
   T get(int index) { ... }
}

저는 이제 3 배 더 효율적이고 하나의 복사본 만 유지하면됩니다. 더 적은 코드를 유지하고 싶지 않은 이유는 무엇입니까?

이는 다른 클래스와 상호 작용해야하는 a Callable<T>또는 a 와 같은 컬렉션이 아닌 클래스에도 해당됩니다 Reference<T>. 유형 안전 버전을 만들기 위해 Callable<T>및 Future<T>기타 모든 관련 클래스를 확장 하시겠습니까?

나는하지 않는다.

타입 캐스트를 할 필요가 없다는 것은 컴파일 타임에 타입 검사를 수행하기 때문에 자바 제네릭의 가장 큰 장점 중 하나입니다 . 이것은 ClassCastException런타임에 던질 수있는 s 의 가능성을 줄이고 더 강력한 코드로 이어질 수 있습니다.

그러나 나는 당신이 그것을 완전히 알고 있다고 생각합니다.

Generics를 볼 때마다 두통이 생깁니다. Java의 가장 좋은 부분은 단순하고 최소한의 구문과 제네릭이 단순하지 않고 상당한 양의 새로운 구문을 추가한다는 점입니다.

처음에는 제네릭의 이점도 보지 못했습니다. 1.4 구문에서 Java를 배우기 시작했습니다 (당시 Java 5가 나왔음에도 불구하고). 제네릭을 접했을 때 작성해야 할 코드가 더 많다는 느낌이 들었고 이점을 이해하지 못했습니다.

최신 IDE를 사용하면 제네릭으로 코드를 더 쉽게 작성할 수 있습니다.

대부분의 현대적이고 괜찮은 IDE는 제네릭, 특히 코드 완성으로 코드 작성을 지원할만큼 똑똑합니다.

다음 Map<String, Integer>은 HashMap. 입력해야하는 코드는 다음과 같습니다.

Map<String, Integer> m = new HashMap<String, Integer>();

그리고 실제로 새로운 HashMap. 그러나 실제로 Eclipse가 필요한 것을 알기 전에이 정도만 입력해야했습니다.

Map<String, Integer> m = new Ha Ctrl+Space

사실, HashMap후보 목록에서 선택해야 했지만 기본적으로 IDE는 제네릭 유형을 포함하여 추가 할 항목을 알고있었습니다. 올바른 도구를 사용하면 제네릭을 사용하는 것이 나쁘지 않습니다.

또한 유형이 알려져 있으므로 일반 컬렉션에서 요소를 검색 할 때 IDE는 해당 개체가 이미 선언 된 유형의 개체 인 것처럼 작동합니다. 개체의 유형을 알기 위해 IDE를 캐스팅 할 필요가 없습니다. 이다.

제네릭의 주요 이점은 새로운 Java 5 기능과 잘 어울리는 방식에서 비롯됩니다. 다음은 정수를 a에 던지고 Set합계를 계산 하는 예입니다 .

Set<Integer> set = new HashSet<Integer>();
set.add(10);
set.add(42);

int total = 0;
for (int i : set) {
  total += i;
}

이 코드에는 세 가지 새로운 Java 5 기능이 있습니다.

첫째, 프리미티브의 제네릭 및 오토 박싱은 다음 행을 허용합니다.

set.add(10);
set.add(42);

정수는 10으로되어 오토 박싱 Integer의 값 10. (그리고 동일 42). 그런 다음 s 를 보유하는 것으로 알려진에 Integer던져집니다 . 던지려고 하면 컴파일 오류가 발생합니다.SetIntegerString

다음으로 for-each 루프는 다음 세 가지를 모두 취합니다.

for (int i : set) {
  total += i;
}

첫째, Set포함하는 Integers는 for-each 루프에서 사용됩니다. 각 요소는로 선언 되며은 기본 형식으로 다시 unboxed int되므로 허용됩니다 . 그리고이 unboxing이 발생한다는 사실은 제네릭을 사용 하여 .IntegerintIntegerSet

Generics는 Java 5에 도입 된 새로운 기능을 결합하는 접착제가 될 수 있으며 코딩을 더 간단하고 안전하게 만듭니다. 그리고 대부분의 경우 IDE는 좋은 제안을 할 수있을만큼 똑똑하므로 일반적으로 더 많이 입력하지 않아도됩니다.

솔직히 Set예제 에서 볼 수 있듯이 Java 5 기능을 사용하면 코드가 더 간결하고 강력해질 수 있다고 생각합니다.

편집-제네릭이없는 예

다음은 Set제네릭을 사용하지 않은 위의 예입니다. 가능하지만 정확히 유쾌하지는 않습니다.

Set set = new HashSet();
set.add(10);
set.add(42);

int total = 0;
for (Object o : set) {
  total += (Integer)o;
}

(참고 : 위 코드는 컴파일 타임에 확인되지 않은 변환 경고를 생성합니다.)

제네릭이 아닌 컬렉션을 사용하는 경우 컬렉션에 입력되는 유형은 유형의 개체입니다 Object. 따라서이 예에서 a Object는 add세트 로 편집되는 것입니다.

set.add(10);
set.add(42);

위의 줄에서 오토 박싱은 기본 int값 10이며 42.NET Framework Integer에 추가되는 객체 로 오토 박싱 되고 Set있습니다. 그러나 컴파일러가 어떤 유형 을 예상 해야하는지 알 수있는 유형 정보가 없기 때문에 Integer객체가 Objects 로 처리된다는 점 을 명심 하십시오 Set.

for (Object o : set) {

이것이 중요한 부분입니다. for-each 루프가 작동하는 이유는 존재하는 경우 with 형식 정보 를 반환하는 인터페이스를 Set구현 하기 때문 입니다. ( , 즉)IterableIteratorIterator<T>

그러나 유형 정보가 없기 때문에는 as 에서 값을 Set반환하는 an Iterator을 반환 하므로 for-each 루프에서 검색되는 요소가 유형 이어야합니다 .SetObjectObject

에서 Object가 검색 Set되었으므로 Integer추가를 수행하려면 수동으로로 캐스팅해야합니다 .

  total += (Integer)o;

여기서, 타입 변환은에서 수행 Object내지 An Integer. 이 경우, 우리는 이것이 항상 작동한다는 것을 알고 있지만, 수동 형변환은 항상 다른 곳에서 사소한 변경이 이루어지면 손상 될 수있는 취약한 코드라고 느끼게합니다. (나는 모든 타입 캐스트가 ClassCastException일어나기를 기다리고 있다고 느낀다 . 그러나 나는 탈선한다 ...)

은 Integer이제로 박싱되어 int상기에 또한 수행 할 수있는 int변수 total.

Java 5의 새로운 기능이 제네릭이 아닌 코드와 함께 사용할 수 있다는 것을 설명 할 수 있기를 바랍니다.하지만 제네릭으로 코드를 작성하는 것만 큼 깨끗하고 간단하지는 않습니다. 그리고 제 생각에는 Java 5의 새로운 기능을 최대한 활용하려면 제네릭을 조사해야합니다. 최소한 컴파일 시간 검사를 통해 잘못된 typecast가 런타임에 예외를 던지는 것을 방지 할 수 있다면 말입니다.

당신은 1.5이 출시되기 직전 자바 버그 데이터베이스를 검색한다면, 당신은 일곱 배나 더 많은 버그를 찾을 것 NullPointerException이상을 ClassCastException. 따라서 버그 나 최소한 약간의 연기 테스트 후에도 지속되는 버그를 찾는 것은 훌륭한 기능이 아닌 것 같습니다.

제네릭의 큰 장점은 코드에 중요한 유형 정보를 문서화한다는 것 입니다. 해당 유형 정보를 코드로 문서화하지 않으려면 동적으로 유형이 지정된 언어를 사용하거나 적어도 암시적인 유형 추론이있는 언어를 사용합니다.

객체의 컬렉션을 자체적으로 유지하는 것은 나쁜 스타일이 아닙니다 (하지만 일반적인 스타일은 캡슐화를 효과적으로 무시하는 것입니다). 오히려 당신이하는 일에 달려 있습니다. 컬렉션을 "알고리즘"으로 전달하는 것은 제네릭을 사용하여 (컴파일시 또는 전에) 확인하기가 약간 더 쉽습니다.

Java의 Generics는 파라 메트릭 다형성을 용이하게 합니다. 유형 매개 변수를 사용하여 유형에 인수를 전달할 수 있습니다. String foo(String s)모델 과 같은 메소드 가 특정 문자열뿐만 아니라 모든 문자열에 대한 일부 동작을 나타내는 것처럼, 모델 s과 같은 List<T>유형은 특정 유형뿐만 아니라 모든 유형에 대한 일부 동작 입니다. 모든 유형 에 대해 요소가 s 인 유형이List<T> 있다고 말합니다 . 그래서 실제로 유형 생성자 입니다. 유형을 인수로 취하고 결과로 다른 유형을 구성합니다.TListTList

다음은 내가 매일 사용하는 제네릭 유형의 몇 가지 예입니다. 첫째, 매우 유용한 일반 인터페이스 :

public interface F<A, B> {
  public B f(A a);
}

이 인터페이스는 말한다 몇 개의 유형, A및 B, (라는 함수있다 f소요) A과를 반환 B. 이 인터페이스를 구현하는 경우 A와 B같은 당신이 기능 제공으로, 당신이 원하는 어떤 종류의 수 있습니다 f전자를 소요하고 후자를 반환합니다. 다음은 인터페이스 구현의 예입니다.

F<Integer, String> intToString = new F<Integer, String>() {
  public String f(int i) {
    return String.valueOf(i);
  }
}

제네릭 이전 에는 키워드를 사용하여 서브 클래 싱 하여 다형성을 달성했습니다 extends. 제네릭을 사용하면 실제로 서브 클래 싱을 없애고 대신 파라 메트릭 다형성을 사용할 수 있습니다. 예를 들어 모든 유형에 대한 해시 코드를 계산하는 데 사용되는 매개 변수화 된 (일반) 클래스를 고려하십시오. Object.hashCode ()를 재정의하는 대신 다음과 같은 일반 클래스를 사용합니다.

public final class Hash<A> {
  private final F<A, Integer> hashFunction;

  public Hash(final F<A, Integer> f) {
    this.hashFunction = f;
  }

  public int hash(A a) {
    return hashFunction.f(a);
  }
}

이는 상속을 사용하는 것보다 훨씬 더 유연합니다. 부서지기 쉬운 계층 구조를 잠그지 않고 구성 및 매개 변수 다형성을 사용하는 주제를 유지할 수 있기 때문입니다.

Java의 제네릭은 완벽하지 않습니다. 유형을 통해 추상화 할 수 있지만, 예를 들어 유형 생성자를 통해 추상화 할 수는 없습니다. 즉, "모든 유형 T에 대해"라고 말할 수 있지만 "유형 매개 변수 A를 사용하는 모든 유형 T에 대해"라고 말할 수 없습니다.

여기에 Java 제네릭의 이러한 한계에 대한 기사를 썼습니다.

제네릭의 큰 장점 중 하나는 서브 클래 싱을 피할 수 있다는 것입니다. 서브 클래 싱은 확장하기 어려운 취약한 클래스 계층 구조와 전체 계층 구조를 보지 않고는 개별적으로 이해하기 어려운 클래스를 생성하는 경향이 있습니다.

제네릭 전에 Wereas 당신은 같은 클래스를 가질 수 Widget확장 FooWidget, BarWidget그리고 BazWidget, 제네릭 단일 제네릭 클래스 가질 수 Widget<A>소요 Foo, Bar또는 Baz생성자을 제공하기에 Widget<Foo>, Widget<Bar>등을 Widget<Baz>.

Generics는 boxing 및 unboxing의 성능 저하를 방지합니다. 기본적으로 ArrayList 대 List <T>를 살펴보십시오. 둘 다 동일한 핵심 작업을 수행하지만 List <T>는 개체로 /로부터 상자를 만들 필요가 없기 때문에 훨씬 빠릅니다.

사용자 정의 유형을 정의하는 빠른 방법을 제공하기 때문에 좋아합니다.

예를 들어 문자열과 정수로 구성된 구조를 정의한 다음 이러한 구조의 배열에 액세스하는 방법에 대한 전체 개체 및 메서드 집합을 구현해야하는 대신 사전을 만들 수 있습니다.

Dictionary<int, string> dictionary = new Dictionary<int, string>();

그리고 컴파일러 / IDE가 나머지 무거운 작업을 수행합니다. 특히 사전을 사용하면 첫 번째 유형을 키로 사용할 수 있습니다 (반복되는 값 없음).

Generics의 가장 큰 이점은 코드 재사용입니다. 많은 비즈니스 개체가 있고 동일한 작업을 수행하기 위해 각 엔터티에 대해 매우 유사한 코드를 작성한다고 가정 해 보겠습니다. (IE Linq에서 SQL 작업으로).

제네릭을 사용하면 주어진 기본 클래스에서 상속하는 모든 유형이 주어지면 작동 할 수있는 클래스를 만들거나 다음과 같이 주어진 인터페이스를 구현할 수 있습니다.

public interface IEntity
{

}

public class Employee : IEntity
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int EmployeeID { get; set; }
}

public class Company : IEntity
{
    public string Name { get; set; }
    public string TaxID { get; set }
}

public class DataService<ENTITY, DATACONTEXT>
    where ENTITY : class, IEntity, new()
    where DATACONTEXT : DataContext, new()
{

    public void Create(List<ENTITY> entities)
    {
        using (DATACONTEXT db = new DATACONTEXT())
        {
            Table<ENTITY> table = db.GetTable<ENTITY>();

            foreach (ENTITY entity in entities)
                table.InsertOnSubmit (entity);

            db.SubmitChanges();
        }
    }
}

public class MyTest
{
    public void DoSomething()
    {
        var dataService = new DataService<Employee, MyDataContext>();
        dataService.Create(new Employee { FirstName = "Bob", LastName = "Smith", EmployeeID = 5 });
        var otherDataService = new DataService<Company, MyDataContext>();
            otherDataService.Create(new Company { Name = "ACME", TaxID = "123-111-2233" });

    }
}

위의 DoSomething 메서드에서 다른 유형이 주어 졌을 때 동일한 서비스를 재사용하는 것에 주목하십시오. 정말 우아합니다!

작업에 제네릭을 사용하는 다른 많은 이유가 있습니다. 이것이 제가 가장 좋아하는 것입니다.

  • 형식화 된 컬렉션-사용하고 싶지 않더라도 다른 라이브러리, 다른 소스에서 처리해야 할 가능성이 높습니다.

  • 클래스 생성시 일반 입력 :

    공개 클래스 Foo <T> {공개 T get () ...

  • 캐스팅 회피-나는 항상 다음과 같은 것을 싫어했습니다.

    new Comparator {public int compareTo (Object o) {if (o instanceof classIcareAbout) ...

인터페이스가 객체로 표현되기 때문에 존재해야하는 조건을 본질적으로 확인하는 곳입니다.

제네릭에 대한 나의 초기 반응은 당신의 반응과 비슷했습니다. "너무 지저분하고, 너무 복잡합니다." 내 경험으로는 그것들을 조금 사용한 후에 익숙해지며, 그것들이없는 코드는 덜 명확하고 덜 편안하다고 느낍니다. 그 외에도 나머지 자바 세계에서는이를 사용하므로 결국 프로그램을 사용해야합니다.

좋은 예를 들어 보자. Foo라는 클래스가 있다고 상상해보십시오.

public class Foo
{
   public string Bar() { return "Bar"; }
}

예제 1 이제 Foo 개체의 컬렉션을 원합니다. LIst 또는 ArrayList의 두 가지 옵션이 있으며 둘 다 유사한 방식으로 작동합니다.

Arraylist al = new ArrayList();
List<Foo> fl = new List<Foo>();

//code to add Foos
al.Add(new Foo());
f1.Add(new Foo());

위의 코드에서 Foo 대신 FireTruck 클래스를 추가하려고하면 ArrayList가이를 추가하지만 Foo의 Generic List로 인해 예외가 발생합니다.

예 2 :

이제 두 개의 배열 목록이 있고 각각에 대해 Bar () 함수를 호출하려고합니다. ArrayList는 Object로 채워져 있으므로 bar를 호출하기 전에 캐스트해야합니다. 그러나 Foo의 Generic List는 Foos 만 포함 할 수 있으므로 Bar ()를 직접 호출 할 수 있습니다.

foreach(object o in al)
{
    Foo f = (Foo)o;
    f.Bar();
}

foreach(Foo f in fl)
{
   f.Bar();
}

메서드 / 클래스의 핵심 개념이 매개 변수 / 인스턴스 변수의 특정 데이터 유형 (연결된 목록, 최대 / 최소 함수, 이진 검색)에 밀접하게 연결되지 않은 메서드 (또는 클래스)를 작성한 적이 없습니다. 등).

혹시 컷 - 앤 - 붙여 재사용이나 강한 타이핑을 손상시키지을 (내가 원하는 예를 들어, 당신이에 의지하지 않고 algorthm / 코드를 재사용 할 수 싶지 않은 적이 List하지 않은, 문자열의 List것들을 내가 희망 문자열!)?

당신이해야하는 이유의 싶지는 제네릭 (또는 뭔가 더 나은)를 사용합니다.

제네릭은 클래스에서 사용되는 것이 아니라 메서드에서도 사용할 수 있음을 잊지 마십시오. 예를 들어 다음 스 니펫을 사용하십시오.

private <T extends Throwable> T logAndReturn(T t) {
    logThrowable(t); // some logging method that takes a Throwable
    return t;
}

간단하지만 매우 우아하게 사용할 수 있습니다. 좋은 점은 메서드가 주어진 모든 것을 반환한다는 것입니다. 이는 호출자에게 다시 던져 져야하는 예외를 처리 할 때 도움이됩니다.

    ...
} catch (MyException e) {
    throw logAndReturn(e);
}

요점은 메소드를 통해 유형을 전달함으로써 유형을 잃지 않는다는 것입니다. Throwable제네릭없이 할 수있는 모든 것 대신에 올바른 유형의 예외를 throw 할 수 있습니다 .

이것은 제네릭 메서드에 대한 간단한 사용 예입니다. 제네릭 메서드로 할 수있는 몇 가지 다른 깔끔한 작업이 있습니다. 내 생각에 가장 멋진 것은 제네릭으로 추론하는 유형입니다. 다음 예제 (Josh Bloch의 Effective Java 2nd Edition에서 발췌)를 사용하십시오.

...
Map<String, Integer> myMap = createHashMap();
...
public <K, V> Map<K, V> createHashMap() {
    return new HashMap<K, V>();
}

이것은 많은 작업을 수행하지 않지만 제네릭 유형이 길거나 중첩 될 때 약간의 혼란을 줄입니다 (예 :) Map<String, List<String>>.

Mitchel이 지적했듯이 주요 이점은 여러 클래스를 정의 할 필요없이 강력한 타이핑입니다.

이렇게하면 다음과 같은 작업을 수행 할 수 있습니다.

List<SomeCustomClass> blah = new List<SomeCustomClass>();
blah[0].SomeCustomFunction();

제네릭이 없으면 blah [0]을 올바른 유형으로 캐스팅해야 해당 함수에 액세스 할 수 있습니다.

어쨌든 jvm은 캐스트합니다. 일반 유형을 "Object"로 취급하고 원하는 인스턴스화에 대한 캐스트를 생성하는 코드를 암시 적으로 생성합니다. Java 제네릭은 구문상의 설탕 일뿐입니다.

이것이 C # 질문이라는 것을 알고 있지만 제네릭 은 다른 언어에서도 사용되며 사용 / 목표는 매우 유사합니다.

Java 컬렉션은 Java 1.5부터 제네릭을 사용 합니다. 그래서, 그것들을 사용하기 좋은 곳은 자신 만의 컬렉션과 같은 객체를 만들 때입니다.

거의 모든 곳에서 볼 수있는 예는 두 개의 객체를 보유하지만 일반적인 방식으로 이러한 객체를 처리해야하는 Pair 클래스입니다.

class Pair<F, S> {
    public final F first;
    public final S second;

    public Pair(F f, S s)
    { 
        first = f;
        second = s;   
    }
}

이 Pair 클래스를 사용할 때마다 처리 할 객체의 종류를 지정할 수 있으며 런타임이 아닌 컴파일 타임에 모든 유형 캐스트 ​​문제가 표시됩니다.

제네릭은 'super'및 'extends'키워드로 정의 된 경계를 가질 수도 있습니다. 예를 들어, 제네릭 타입을 다루고 싶지만 그것이 Foo라는 클래스 (setTitle 메서드가 있음)를 확장하는지 확인하고 싶다면 :

public class FooManager <F extends Foo>{
    public void setTitle(F foo, String title) {
        foo.setTitle(title);
    }
}

그 자체로는 그다지 흥미롭지는 않지만 FooManager를 다룰 때마다 MyClass 유형을 처리하고 MyClass가 Foo를 확장한다는 것을 알고 있으면 유용합니다.

Sun Java 문서에서 "왜 제네릭을 사용해야합니까?"에 대한 응답 :

"Generics는 컬렉션의 유형을 컴파일러에 전달하여 확인할 수있는 방법을 제공합니다. 컴파일러가 컬렉션의 요소 유형을 알게되면 컴파일러는 컬렉션을 일관되게 사용했는지 확인하고 삽입 할 수 있습니다. 컬렉션에서 가져온 값에 대한 올바른 캐스트 ... 제네릭을 사용하는 코드가 더 명확하고 안전합니다 .... 컴파일러는 컴파일 타임에 유형 제약 조건이 런타임에 위반되지 않았는지 확인할 수 있습니다 [강조]. 프로그램이 경고없이 컴파일되면 런타임에 ClassCastException이 발생하지 않는다고 확실하게 말할 수 있습니다. 특히 대규모 프로그램에서 제네릭을 사용하는 결과는 가독성과 견고성 이 향상 됩니다. [강조] "

제네릭을 사용하면 강력한 형식의 개체를 만들 수 있지만 특정 형식을 정의 할 필요는 없습니다. 가장 유용한 예는 List 및 유사한 클래스라고 생각합니다.

일반 목록을 사용하면 원하는대로 목록 목록 목록을 가질 수 있으며 항상 강력한 유형을 참조 할 수 있습니다. 변환 할 필요가 없습니다. 또는 배열 또는 표준 목록을 사용하는 것과 같은 것입니다.

제네릭을 사용하면 모든 개체를 보유 할 수 있어야하는 개체 및 데이터 구조에 대해 강력한 유형을 사용할 수 있습니다. 또한 일반 구조 (boxing / unboxing)에서 개체를 검색 할 때 지루하고 값 비싼 typecast를 제거합니다.

둘 다 사용하는 한 가지 예는 연결 목록입니다. 연결 목록 클래스가 객체 Foo 만 사용할 수 있다면 어떤 소용이 있을까요? 모든 종류의 개체를 처리 할 수있는 연결 목록을 구현하려면 목록에 개체 유형이 하나만 포함되도록하려면 연결 목록과 가상 노드 내부 클래스의 노드가 제네릭이어야합니다.

컬렉션에 값 유형이 포함되어있는 경우 컬렉션에 삽입 할 때 개체에 대해 상자 / 개봉 할 필요가 없으므로 성능이 크게 향상됩니다. resharper와 같은 멋진 애드온은 foreach 루프와 같은 더 많은 코드를 생성 할 수 있습니다.

Generics (특히 Collections / Lists와 함께) 사용의 또 다른 장점은 컴파일 시간 유형 검사를 얻는 것입니다. 이것은 객체 목록 대신 일반 목록을 사용할 때 매우 유용합니다.

가장 큰 이유는 유형 안전성 을 제공하기 때문입니다.

List<Customer> custCollection = new List<Customer>;

반대로

object[] custCollection = new object[] { cust1, cust2 };

간단한 예입니다.

요약하면 제네릭을 사용하면 수행하려는 작업을보다 정확하게 지정할 수 있습니다 (더 강력한 입력).

다음과 같은 몇 가지 이점이 있습니다.

  • 컴파일러는 사용자가 원하는 작업에 대해 더 많이 알고 있기 때문에 형식이 호환 될 것임을 이미 알고 있기 때문에 많은 형식 캐스팅을 생략 할 수 있습니다.

  • 이것은 또한 프로그램의 수정에 대한 이전 피드백을 얻습니다. 이전에는 런타임에 실패 했었던 것 (예 : 객체를 원하는 유형으로 캐스팅 할 수 없기 때문에), 이제 컴파일 타임에 실패하고 테스트 부서가 암호화 버그 보고서를 제출하기 전에 실수를 수정할 수 있습니다.

  • 컴파일러는 권투 방지 등과 같은 더 많은 최적화를 수행 할 수 있습니다.

추가 / 확장 할 몇 가지 사항 (.NET 관점에서 말하면) :

일반 유형을 사용하면 역할 기반 클래스 및 인터페이스를 만들 수 있습니다. 이것은 이미 더 기본적인 용어로 언급되었지만 유형에 구애받지 않는 방식으로 구현되는 클래스로 코드를 디자인하기 시작하여 재사용 가능성이 높은 코드를 생성합니다.

메서드에 대한 일반적인 인수는 동일한 작업을 수행 할 수 있지만, 캐스팅에 "Tell Do n't Ask"원칙을 적용하는데도 도움이됩니다.

예를 들어 SpringORM 및 Hibernate로 구현 된 GenericDao에서 사용합니다.

public abstract class GenericDaoHibernateImpl<T> 
    extends HibernateDaoSupport {

    private Class<T> type;

    public GenericDaoHibernateImpl(Class<T> clazz) {
        type = clazz;
    }

    public void update(T object) {
        getHibernateTemplate().update(object);
    }

    @SuppressWarnings("unchecked")
    public Integer count() {
    return ((Integer) getHibernateTemplate().execute(
        new HibernateCallback() {
            public Object doInHibernate(Session session) {
                    // Code in Hibernate for getting the count
                }
        }));
    }
  .
  .
  .
}

제네릭을 사용함으로써이 DAO의 구현은 개발자가 GenericDao를 서브 클래 싱하여 설계된 엔티티 만 전달하도록합니다.

public class UserDaoHibernateImpl extends GenericDaoHibernateImpl<User> {
    public UserDaoHibernateImpl() {
        super(User.class);     // This is for giving Hibernate a .class
                               // work with, as generics disappear at runtime
    }

    // Entity specific methods here
}

내 작은 프레임 워크가 더 강력합니다 (필터링, 지연 로딩, 검색과 같은 것 포함). 예를 들어 보겠습니다.

I, like Steve and you, said at the beginning "Too messy and complicated" but now I see its advantages

Obvious benefits like "type safety" and "no casting" are already mentioned so maybe I can talk about some other "benefits" which I hope it helps.

First of all, generics is a language-independent concept and , IMO, it might make more sense if you think about regular (runtime) polymorphism at the same time.

For example, the polymorphism as we know from object oriented design has a runtime notion in where the caller object is figured out at runtime as program execution goes and the relevant method gets called accordingly depending on the runtime type. In generics, the idea is somewhat similar but everything happens at compile time. What does that mean and how you make use of it?

(Let's stick with generic methods to keep it compact) It means that you can still have the same method on separate classes (like you did previously in polymorphic classes) but this time they're auto-generated by the compiler depend on the types set at compile time. You parametrise your methods on the type you give at compile time. So, instead of writing the methods from scratch for every single type you have as you do in runtime polymorphism (method overriding), you let compilers do the work during compilation. This has an obvious advantage since you don't need to infer all possible types that might be used in your system which makes it far more scalable without a code change.

Classes work the pretty much same way. You parametrise the type and the code is generated by the compiler.

Once you get the idea of "compile time", you can make use "bounded" types and restrict what can be passed as a parametrised type through classes/methods. So, you can control what to be passed through which is a powerful thing especially you've a framework being consumed by other people.

public interface Foo<T extends MyObject> extends Hoo<T>{
    ...
}

No one can set sth other than MyObject now.

Also, you can "enforce" type constraints on your method arguments which means you can make sure both your method arguments would depend on the same type.

public <T extends MyObject> foo(T t1, T t2){
    ...
}

Hope all of this makes sense.

I once gave a talk on this topic. You can find my slides, code, and audio recording at http://www.adventuresinsoftware.com/generics/.

Using generics for collections is just simple and clean. Even if you punt on it everywhere else, the gain from the collections is a win to me.

List<Stuff> stuffList = getStuff();
for(Stuff stuff : stuffList) {
    stuff.do();
}

vs 

List stuffList = getStuff();
Iterator i = stuffList.iterator();
while(i.hasNext()) {
    Stuff stuff = (Stuff)i.next();
    stuff.do();
}

or

List stuffList = getStuff();
for(int i = 0; i < stuffList.size(); i++) {
    Stuff stuff = (Stuff)stuffList.get(i);
    stuff.do();
}

That alone is worth the marginal "cost" of generics, and you don't have to be a generic Guru to use this and get value.

Generics also give you the ability to create more reusable objects/methods while still providing type specific support. You also gain a lot of performance in some cases. I don't know the full spec on the Java Generics, but in .NET I can specify constraints on the Type parameter, like Implements a Interface, Constructor , and Derivation.

참고URL : https://stackoverflow.com/questions/77632/what-is-cool-about-generics-why-use-them

반응형

'developer tip' 카테고리의 다른 글

MySQL 날짜 / 시간 값을 System.DateTime으로 변환 할 수 없습니다.  (0) 2020.10.06
Android 용 ViewPager의 현재 페이지 번호는 어떻게 얻습니까?  (0) 2020.10.06
MVC, C # 및 jQuery를 사용하여 CSV로 내보내기  (0) 2020.10.06
웹 서버가없는 스프링 부트  (0) 2020.10.06
C # 코드가 컴파일되지 않습니다.  (0) 2020.10.06

'developer tip'의 다른글

  • 현재글제네릭의 멋진 점은 무엇이며 왜 사용합니까?

관련글

댓글

티스토리툴바