반응형 C#52 [Effective C#] Item26 제네릭 인터페이스와 논 제네릭 인터페이스를 함께 구현하라 C#의 제네릭을 사용하면 컴파일 타임에 타입을 미리 체크하여 에러를 사전에 잡을 수 있고, 컴파일러가 직접 타입을 캐스팅 해줘서 편하고 다른 타입이지만 동일한 코드를 사용할때, 코드 재사용성을 높여줘서 아주 유용하다. 그렇다면 왜 이렇게 편한 제네릭 인터페이스가 있는데 논제네릭 인터페이스도 같이 구현하라고 하는걸까? 논제네릭 인터페이스를 함께 구현해야 하는 이유 제네릭이 생기기 이전에 개발된 코드들을 무시할 수 있다면 좋겠지만 유감스럽게도 무시하는 것이 어렵다. 새로운 라이브러리를 개발할 대 제네릭 타입뿐 아니라 고전적인 방식도 함께 지원한다면 라이브러리의 활용도를 더 높일 수 있다. 만약 제네릭 타입이 아닌 방식을 지원하겠다고 결정했다면 다음 3가지 요소에 대해서는 논제네릭 방식을 지원해야 한다. 1... 2022. 10. 26. [Effective C#] Item 25 타입 매개변수로 인스턴스 필드를 만들 필요가 없다면 제네릭 메서드를 정의하라 제네릭을 사용하다 보면 무심코 제네릭 클래스를 만드는 게 습관이 되어버릴 수도 있다. 하지만 유틸리티 성격의 클래스를 만드는 경우에는 제네릭 클래스를 만드는 것보다 일반 클래스에 제네릭 메서드를 구현하는 것이 더 좋다. 왜 제네릭 메서드로?? 왜 제네릭 메서드로 구현하는 것이 좋은가? 우선, 제네릭 클래스를 작성하면 컴파일러 입장에서는 전체 클래스에 대하여 타입 매개변수에 대한 제약 조건을 고려하여 컴파일을 해야 하지만 일반 클래스 내에 제네릭 메서드들을 배치하면 가 메서드 별로 제약 조건을 다르게 설정할 수 있다. 제네릭 클래스로 작성하여 제약 조건의 범위가 넓어지면 넓어질수록 코드를 수정하기가 점점 더 까다로워진다. 정리하자면, 타입 매개변수로 인스턴스 필드를 만들어야 하는 경우에는 제네릭 클래스를 .. 2022. 10. 25. [Effective C#] Item24 베이스 클래스나 인터페이스에 대해서 제네릭을 특화하지 말라 제네릭 메서드를 포함한 여러 개의 오버로드된 메서드가 있는 경우, 컴파일러는 제네릭 메서드의 타입 매개변수가 다른 타입으로 다양하게 변경될 수 있음을 고려하여 오버로드된 메서드 중 하나를 선택한다. 그런데 자칫 이러한 동작 방식을 제대로 인지하지 못 할 경우, 응용프로그램이 이상하게 동작할 수도 있다. 하지만, 개발자는 컴파일러가 오버로드된 메서드 중 어떤 메서드르 선태갛는지 정확히 알고 있어야한다. 우선, 코드를 살펴보자. public class MyBase { } public interface IMessageWriter { void WriteMessage(); } public class MyDerived : MyBase, IMessageWriter { void IMessageWriter.WriteMe.. 2022. 10. 25. [Effective C#] Item 23 타입 매개변수에 대해 메서드 제약 조건을 설정하려면 델리게이트를 활용하라1 언뜻 보면 C#에서 제약 조건을 설정하느 방법에는 한계가 많은 것 같다. 베이스 클래스 타입이나 특정 인터페이스로 제약 조건을 설정하거나, class 타입이나 struct 타입으로 형태를 제한하거나, 매개변수가 없는 생성자를 가져야 한다는 조건 정도를 설정하는게 끝인 것 같다. 임의 static 메서드를 반드시 구현해야 한다거나 매개변수를 취하는 생성자를 반드시 구현하도록 제약 조건을 설정할 수는 없다. 제한적이지만 인터페이스를 통해서 제약 조건을 설정할 수는 있지만 추가적으로 해야 할 작업이 너무 많고 기본적인 구조도 해칠 수 있다. 이를 위해서 메서드의 원형에 부합하는 델리게이트를 작성하는 것이 좋다. 인터페이스를 이용한 메서드 제약 어떤 제네릭 클래스에 대해 타입 매개변수 T가 반드시 Add() 메.. 2022. 10. 11. 이전 1 ··· 5 6 7 8 9 10 11 ··· 13 다음 반응형