안녕하세요, 34번째 시간입니다.

이번 챕터는 확장 메서드는 절대 오버로드 하지 마라, 입니다. LINQ 챕터에 들어오기전 나온 확장메서드가 여기서 또 나왔네요. 내용 자체는 길지도 않고 그리 어렵지 않습니다만, 확장 메서드에 대한 지식 조금 필요하니 바로 오신 분들은 확장 메서드에 대해 공부하고 보는 것을 추천합니다.

설명

1. 확장 메서드는 설계 의도를 나타내는 방법으로는 좋지 않다. 그 이유는 대부분의 확장메서드는 기존에 개발된 타입을 개선하기 위해서이지, 본질적인 동작 방식을 변경하기 위한 의도는 아니기 때문이다.

2. 따라서, 타입을 확장하기 위해서 동일한 기법을 사용하려 할 수도 있을 것이고, 네임 스페이스를 달리하여 여러 가지 버전의 확장 메서드를 정의하려고 할 수도 있으나, 그렇게 해서는 안된다.

3. 그렇게 할수도 있고, 그 방법이 나쁜것은 아니지만, 적절하다고는 볼 수 없으며 그 방법보다 좋은 대안이 많다. 이로 인해 확장 메서드를 과도하게 사용하거나 잘못 사용하면 메서드 충돌로 인해 유지보수 비용이 급격히 증가하는 곤경에 처할 수 있다.

결론

결론 특정 타입에 대해 동작하는 확장 메서드는 하나의 세트로 간주해야 한다. 확장 메서드를 여러 네임스페이스에 걸쳐 오버로드해서는 안 된다. 동일한 원형의 확장 메서드를 여러 개 만들어야 할 경우라도 절대 그렇게 해서는 안된다. 대신 메서드의 이름을 달리하고 정적 메서드로 작성하는 것은 고려해볼 법하다. 그래야만 컴파일러가 using 문장을 기반으로 오버로드된 메서드 중 하나를 선택하는 이상한 상황이 벌어지지 않는다.