2013-05-21 11 views
3

이 요구 사항은 피어 개발자가 다양한 유형의 확장 방법을 하나의 xxxExt 클래스로 혼합하는 슬픔에 의해 유도됩니다. 컴파일러가 가져온 네임 스페이스를보고 해상도를 처리하기 때문에 여전히 작동합니다. 그러나 중첩 유형에 관해서는 유지가 쉽지 않습니다.클래스의 확장 메서드를 특정 형식으로 제한 할 수 있습니까?

특정 xxExt 클래스로 작성 될 수있는 유형 확장자를 제한 할 수 있습니까? 수동 규칙을 순환시키는 것이 잘 작동하지 않습니다 ... 아마도 컴파일러 수준 제한이 아니라면 정적 코드 분석과 같은 것일 수 있습니까?

코드 (이 클래스에서 제한하고자하는 코드는 IsActiveRisk 메서드입니다).

public static class TradeDataExt{ 
    public static bool IsActiveTrade(this TradeData tradeData){...} 

    public static bool IsActiveRisk(this RiskData riskData) {...} 


} 

이 기능은 가능한 "확실한"기능이 아닙니다. 의견/제안이 도움이 될 것입니다.

+7

왜 그냥'공공 부울이 isActive 이러한 넣지 마십시오 {얻을 {...}}'은'TradeData'와'RiskData' 클래스에서? 이것은 나에게 이해가되지 않는다. 귀하가 이미 관리하고있는 클래스의 확장 기능을 왜 사용합니까? –

+0

+1로 @HighCore가 – lexeRoy

+1

을 제안했습니다. 이해가됩니다 ... TradeData/RiskData 라이브러리에 액세스하지 못할 수도 있습니다 !! –

답변

0

우선, 당신이 예제를 작성하고 확장 메서드의 더 중요한 키워드를 잊어 버린 것처럼 보입니다. 매개 변수 바로 앞에 키워드 "this"가 누락되었습니다. :)

난 당신이 의미 같은데요 :

public static class TradeDataExt 
{ 
    public static bool IsActiveTrade(this TradeData tradeData){...} 
    public static bool IsActiveRisk(this RiskData riskData) {...} 
} 

좋아, 첫 번째 포인트는 말했다, 지금의 당신의 질문을 살펴 보자 :

이이 요구 사항은 개발자가 피어 슬픔에 의해 구동 다른 유형에 방법을 섞는다 xxxExt 종류로. 컴파일러가 를 보았기 때문에 아직도 유효하다 수입품을 보아서 네임 스페이스.

실제로 확장 메서드가 작동하는 방법의 진실과 정반대입니다.

정적 메서드를 사용하여 정적 클래스를 선언하면 "namespace"를 사용하고 클래스 이름이 아닌 것으로 선언하면 자동으로 사용할 수 있습니다! (같은 정적 클래스의 부분 클래스 인 여러 .cs 파일을 가진 프로젝트가있는 시나리오가 아닌 경우 ..... 내가 생각하는 것 이상으로 생각합니다)

이 예제를 살펴보십시오.

namespace Gabriel.Extensions 
{ 
    public static class ClassWithSameName 
    { 
     public static bool IsActiveTrade(this TradeData tradeData){...} 
    } 
} 

namespace John.Extensions 
{ 
    public static class ClassWithSameName 
    { 
     public static bool IsAGoodDeal(this TradeData tradeData){...} 
    } 
} 

예제를 보면 두 클래스 모두 이름이 같지만 서로 다른 네임 스페이스에 있으므로 명시 적으로 각 네임 스페이스의 "사용"을 선언 할 때만 TradeData 클래스가 확장됩니다. 그래서 나는 이것이 당신을위한 길이라고 말하고 싶습니다 :

생성되는 유형 확장자를 제어하기 위해 네임 스페이스를 사용해야하므로 XXXX.Extensions.Validation, XXXXX.Extensions.Calculation과 같은 네임 스페이스를 가질 수 있습니다. XXXXX.Extensions.ServicesProvider 등 ... 같은 네임 스페이스에서 모두를 사용하는 대신 (복잡한 일이 발생할 수 있기 때문에) ... 동일한 네임 스페이스에서 수백 가지의 확장 메서드를 추가하는 것은 모두 최선의 방법이 아닙니다.

코드는 다음과 같아야합니다

namespace TradeDataExtensions.Validation 
{ 
    public static class ClassWithSameName 
    { 
     public static bool IsActiveTrade(this TradeData tradeData){...} 
    } 
} 

namespace TradeDataExtensions.Analytics 
{ 
    public static class ClassWithSameName 
    { 
     public static decimal ExpectedReturn(this TradeData tradeData){...} 
    } 
} 
+0

예,이 질문을 직접 입력하십시오. 그것을 포함했습니다. 네임 스페이스에 관해서, 나는 당신이 말한 것과 같은 의미였습니다. 사용자는 확장 클래스 네임 스페이스를 사용해야합니다. 접근법은 사용 가능해 보이지만 다시 제한적이지는 않습니다. –

+0

글쎄, 솔직히 말해서, 이것은 기술적 문제 이외의 관리 문제 인 것 같다. 왜 "확장"이라고 불리는 것을 제한 할 수 있습니까? 제 요점은 개발자가 원하는 네임 스페이스를 지정하고 원하는 방식으로 사용하도록 강요 할 수 있다는 것입니다. (네임 스페이스가 특정 유형 만 확장하는지 테스트하기 위해 일부 리플렉션을 사용할 수도 있습니다.) –

+0

올바른 방법을 정의하지 않으면 개발자가 일부 코드를 수행하려는 경우 해당 코드가 수행됩니다. 확장 메쏘드를위한 전체 솔루션을 검사하는 약간의 성찰을 작성하더라도 여전히 헬퍼 클래스를 만들고 TradeHelper.IsActiveTrade (무역)를 좋아할 수 있습니다. 당신이 필요로하는 것은 패턴과 표준을 정의하는 것이며, 팀은 당신과 함께 일할 준비가되어있을 것입니다. 행운을 빈다 : D –

관련 문제