.Net에서 확장 메서드를 사용하는 모범 사례는 무엇입니까?

Question

나는 이것이 모든 방식으로 사용되는 것을 보았고 잘못된 방식으로 사용했다는 비난을 받았습니다. 가리키다).

그렇다면 확장 방법을 사용하는 가장 좋은 방법은 무엇이라고 생각하시나요?

개발팀은 확장 방법 라이브러리를 생성하고 이를 다양한 프로젝트에 배포해야 합니까?

오픈소스 프로젝트 형태로 공통 확장 방법 모음이 있어야 할까요?

업데이트:조직 전체의 확장 방법 라이브러리를 만들기로 결정했습니다.

Answer 1

프레임워크 디자인 지침 2판의 향후 릴리스에는 확장 메서드 구현에 대한 몇 가지 지침이 있지만 일반적으로 다음과 같습니다.

"의미상 의미가 있는" 확장 메서드만 정의해야 하며 모든 구현과 관련된 도우미 기능을 제공해야 합니다.

또한 모든 .NET 언어가 확장 메서드를 확장으로 호출할 수 있는 것은 아니므로 System.Object를 확장하지 않아야 합니다.(예를 들어 VB.NET에서는 이를 정적 확장 클래스의 일반 정적 메서드로 호출해야 합니다.)

인터페이스를 확장하지 않는 한 확장 유형과 동일한 네임스페이스에 확장 메서드를 정의하지 마세요.

"실제" 메서드와 동일한 시그니처를 사용하여 확장 메서드를 정의하지 마세요. 호출되지 않기 때문입니다.

Answer 2

당신은 한 번 살펴보고 싶을 수도 있습니다 http://www.codeplex.com/nxl 그리고 http://www.codeplex.com/umbrella 둘 다 확장 메서드 라이브러리입니다.나는 개인적으로 소스 코드를 본 적이 없지만 거기 있는 사람들이 당신에게 좋은 조언을 줄 수 있을 것이라고 확신합니다.

Answer 3

내 프레임워크를 사용하는 사람들은 이 메서드가 유용하다고 생각할 가능성이 높지만 최종 개발자가 확장 메서드 라이브러리를 선택할 수 있는 대량 배포의 경우 Utils 클래스의 핵심 라이브러리에 확장 메서드를 포함시켰습니다. 사람들이 참조나 using 문을 추가하거나 필요한 경우 간단히 추가할 수 있도록 모든 확장을 자신의 네임스페이스, 심지어 자신의 프로젝트 파일에 넣는 것이 좋습니다.

Core.Extensions.Base64Encode(str);

내 Utils 수업은 전 세계에서 가장 친한 친구입니다. 확장 방법이 등장하기 전이었고 우리 관계를 강화하는 데만 도움이 되었습니다.제가 적용할 가장 큰 규칙은 가능한 경우 사람들에게 어떤 확장 프레임워크를 사용할지 선택할 수 있는 기회를 주는 것입니다.

Answer 4

Objective-C 언어에는 1990년대 초반부터 "카테고리"가 있었습니다.이는 본질적으로 .NET 확장 방법과 동일합니다.모범 사례를 찾을 때 Objective-C(Cocoa 및 NeXT) 개발자가 어떤 경험 법칙을 생각해 냈는지 확인하고 싶을 수도 있습니다.

브렌트 시몬스 (Mac OS X 및 iPhone용 NetNewsWire RSS 리더 작성자)가 오늘 자신의 블로그에 대해 게시했습니다. 카테고리 사용에 대한 새로운 스타일 규칙 그리고 조금 있었어요 코코아 커뮤니티에서의 토론 그 포스트 주변에요.

Answer 5

Extension 메서드가 어떤 목적으로 사용되는지에 따라 다르다고 생각합니다.

• 프로젝트의 특정 비즈니스 요구 사항(기본 데이터 유형 또는 사용자 정의 개체에 연결되어 있는지 여부)과 관련된 확장 메서드는 여러 프로젝트에 배포되는 라이브러리에 포함되어서는 안 됩니다.
• 기본 데이터 유형(int, string 등)과 관련된 확장 메서드 또는 더 넓은 적용 범위를 갖는 제네릭을 패키지화하여 프로젝트 전체에 배포할 수 있습니다.

응용 프로그램이 거의 없는 확장 메서드를 전체적으로 포함하지 않도록 주의하세요. 확장 메서드는 인텔리센스를 방해하고 혼란 및/또는 오용을 초래할 수 있습니다.

Answer 6

Extensions에 대해 처음 알았을 때 나는 정말 그것을 너무 많이 사용하고 남용했습니다.

대부분의 경우 나는 여러 가지 이유로 확장 메서드 사용을 중단하기 시작했습니다.

내가 사용을 중단한 몇 가지 이유는 위의 Scott의 블로그 링크에 나와 있습니다. 예를 들어 "자신이 소유하지 않은 유형을 확장하기 전에 두 번 생각해 보세요."확장 중인 유형의 소스를 제어할 수 없는 경우 프로젝트를 최신 .NET 버전으로 이동하는 등 소스 유형에 일부 추가/변경 사항이 있으면 나중에 문제/충돌이 발생할 수 있습니다.최신 .NET 버전에 확장과 동일한 이름의 메서드가 포함되어 있으면 누군가가 당황하게 될 것입니다.

내가 확장 메소드 사용을 중단한 주된 이유는 코드를 읽어도 메소드의 소스가 어디에 있는지, 누가 그것을 "소유"하는지 빨리 알 수 없기 때문입니다.

코드를 읽는 것만으로는 메서드가 확장인지 아니면 해당 유형의 표준 NET API 메서드인지 알 수 없습니다.

Intellisense 메뉴는 정말 빨리 지저분해질 수 있습니다.