2012-01-11 2 views
6

싱글 톤 클래스를 구현했으며 작성한 메서드가 '봉인 클래스에 선언 된 새로운 보호 된 멤버'라는 경고를 계속받습니다. 빌드에 영향을 미치지는 않지만 나중에 문제가 발생할 경우 경고를 무시하고 싶지는 않습니다. 봉인 된 클래스가 상속받을 수없는 클래스라는 것을 이해합니다. 따라서 메서드를 재정의 할 수는 없지만 다음 코드를 사용하면 경고 메시지가 나타납니다 (싱글 톤 디자인 사용으로 인한 것입니까?) :'봉인 된 클래스의 보호 된 멤버'경고 (싱글 톤 클래스)

namespace WPFSurfaceApp 
{ 
public sealed class PresentationManager 
{ 
    PresentationManager() 
    { 
    } 

    protected void MethodName() 
    { 
    } 

    public static PresentationManager Instance 
    { 
     get 
     { 
      return Nested.instance; 
     } 
    } 

    class Nested 
    { 
     // Explicit static constructor to tell C# compiler 
     // not to mark type as beforefieldinit 
     static Nested() 
     { 
     } 

     internal static readonly PresentationManager instance = new PresentationManager(); 
    } 
} 

EDIT : 경고는 MethodName() 메소드에 관한 것입니다. 편집 : public void MethodName()을 protected void MethodName()으로 변경하십시오.

+0

'Nested' 클래스를 private로 설정하면 어떻게됩니까? –

+3

나는 거기에서 보호되는 어떤 것도 보지 않을 것이다 ... –

+0

아무 일도 없었는데, 경고는 여전히 거기에있다. 솔직히 말해서 싱글 톤 디자인과 아무런 관련이 없을 것이라고 생각합니다. 봉인 된 클래스 대 액세스 한정자와 관련이 있습니다.하지만이를 언급하고 중첩 된 클래스 코드를 포함시켜야한다고 생각했습니다. –

답변

14

경고는 protected이 상속 될 수없는 클래스에서 의미가 없기 때문에 경고입니다. 논리적으로는 sealed 클래스의 경우 정확히 private과 같습니다.

오류 자체는 아니지만 컴파일러는 private 대신 protected을 사용하면 아무런 이점도 얻지 못할 것이며 사용자가 의도 한대로 수행하지 않을 수도 있습니다. 봉인 된 클래스에 존재할 수없는 하위 클래스에서 볼 수 있음).

그래, 안전하게 무시해도 상관 없지만 protected 명의 회원이 sealed 클래스에 속하는 것은 논리적으로 일관성이 없습니다. 그것이 어떤 의미를하지 않기 때문에

MSDN 항목은 Compiler Warning CS0628

+0

고맙습니다 James, 지금 이해합니다. 그것은 하나의 자식 클래스가 없기 때문에 모든 자식 클래스로부터 보호하는 것은 의미가 없다는 것입니다. 무의미한 코딩과 달리 잘못되었을 수있는 것에 대한 경고 일 수 있다고 생각했습니다. 아마 그걸 알고 있었을 것입니다. 여러 번 빌드를 한 후에도 경고를 공개로 변경했기 때문에 혼란 스러웠습니다. 고마워. –

4

것이 분명하다. 클래스가 MSDN으로

을 상속하지 못할 경우 protected 멤버의 사용을 될 것입니다 무엇 상속 유형에 액세스 할 수 있습니다 또는 멤버를 오버라이드 (override) 있도록

유형이 보호 된 멤버를 선언했다. 정의상 봉인 된 유형을 상속받을 수는 없습니다. 즉, 봉인 된 유형의 보호 된 메소드는 이라고 부를 수 없습니다.

2

직접 코드를 검토 할 때를 생각해보십시오. 당신이 볼 수있는 한 이해가되지 않는 것을 보게됩니다. 가능한 가능성은 다음과 같습니다.

  1. 개발자는 어리석은 짓을했습니다.
  2. 개발자는 자신에게 명확한 목적을 위해 너무 영리한 작업을 수행했습니다.
  3. 개발자는 평균 시간 내에 발생한 변경으로 더 이상 의미가없는 적절한 것을 수행했습니다.
  4. 개발자는 아직 이해할 수없는 일을했지만 계획된 변경이 발생하면이를 수행 할 것입니다.

첫 번째 경우에는 수정해야합니다.

두 번째 경우에는 문서화해야합니다.

세 번째 경우에는 변경해야합니다. 실용적인 차이는 거의 없지만 코드가 더 이해가 될 것이며 약간의 성능 향상 효과가있을 수 있습니다.

네 번째 경우에는 문서를 당분간 문서화해야하고 나중에 변경하지 말고 변경하거나 다시 작성해야합니다.

어느 쪽이든, 당신은 그들과 논의하고 싶습니다.

보호 된 멤버를 봉인 된 클래스에 추가하는 것은 마찬가지입니다. 왜 당신이 그것을했는지, 위의 네 가지 경우 중 어느 것이 적용되는지는 알 수 없지만, 그 중 하나는 무엇인지를 결정할 수 없습니다. 이 경고는 이것을 강조합니다. 네 가지 경우 중 어느 것이 적용되는지에 따라 네 가지 조치 중 적용되는 것을 수행하십시오.

0

나는 C#으로 놀고 있다고 말합니다. 진심으로 !!
정적 클래스에서는 정적 클래스를 인스턴스화 할 수 없으므로 보호 된 멤버를 선언 할 수 없다고합니다. 실제로 정적 클래스에 protected 멤버를 작성하면 빌드 중에 오류가 발생합니다.
봉인 된 클래스에서는 빌드하는 동안 경고를 표시합니다. 정적 클래스처럼, 봉인 된 클래스도 오류가 아닌 경고를 제공해야합니다. 이 차이가 있다면 왜 그럴까요?