가장 좋은 방법은 필드

Question

나는 기본 클래스 같은이 보호 노출. FxCop을 통해 실행하면 표시되는 인스턴스 필드를 선언하지 않는 것에 대해 불만을 제기하고이를 개인 필드로 변경하고이를 보호 된 속성으로 표시 할 것을 권장합니다.

의견이 있으십니까? 나는이 메시지가 무시 될 수 있다고 생각하고있다.

Answer 1

모든 클래스에는 클라이언트 코드에 의해 두 가지 용도가 사용됩니다. 즉, 클래스를 참조하는 코드와 클래스를 상속하는 코드가 있습니다. 널리 사용되는 두 번째 종류의 사용은 훨씬 단단히 결합 된 것으로 널리 알려져 있습니다. 학급의 변화가 직접 내부 역학에 영향을 미칩니다. 이렇게 노출 된 멤버를 보호하면 기본 클래스의 변경 사항으로 인해 파생 클래스가 각 기본 코드와 파생 클래스의 코드를 비교하지 않고 예측할 수없는 방식으로 작동하는 방식에 영향을 미칩니다. 마찬가지로 파생 된 클래스는 기본 클래스의 내부를 수정할 수 있습니다.

이와 같이 내부 데이터 멤버를 공개하려면 개인 데이터 멤버를 보호 된 속성으로 포장하십시오 (gisresearch가 제안하는 것처럼). 이러한 속성 (보호 된 메서드와 함께)은 클래스의상속 인터페이스를 구성합니다. 외부의 클라이언트에 노출 된 인터페이스 (공용 메소드 및 속성 정의 또는 명시 적 인터페이스 구현을 통하든)와 마찬가지로이 인터페이스는 특히 대규모 코드베이스에서 관리해야하는 항목입니다. 인터페이스는 변경할 수 있지만 의식적인 결정으로 변경해야합니다.

보호 된 데이터 멤버를 직접 사용하는 경우 기본 클래스와 파생 클래스 간의 종속성을 훨씬 덜 제어 할 수 있습니다. 나를 믿어라. 변화가 어떤 영향을 미칠지를 결정할 수 없다하더라도 매우 불쾌한 일이 될 수있다.

Answer 2

FxCop의 조언은 소리입니다. 보호 된 필드를 파생 클래스 direclty에 노출시키고 싶지는 않습니다. 기본 클래스에 의해 관리되는 상태는 기본 클래스에 의해 관리되어야하며 파생 클래스에 의해 직접 수정되지 않아야합니다.

Answer 3

기본적으로합니다 FxCop은

private object m_commandArgument; 

protected object CommandArgument 
{ 
    get { return m_commandArgument; } 
    set { m_commandArgument =value} 
} 

이이 OO 캡슐화 규칙 - (세 OO 규칙 중 하나)에 기반을해야하는 것이 좋습니다. 할당 전에 값을 확인하고 파생 된 클래스에서 직접 조작하지 않도록 할 수 있습니다.

Answer 4

속성을 사용하십시오. 멤버 변수를 private로 변경 한 다음 각 멤버 변수에 대해 보호 된 속성을 설정합니다.

감사합니다,
프랭크

Answer 5

는 가장 좋은 방법은, 클래스 필드는 개인 로 표시해야하며, getter/setter 속성

그래서 대신

protected object m_commandArgument; 

사용

에 싸여

private object m_commandArgument; 

protected object CommandArgument {get; set;} 

이것에 대한 몇 가지 장점이 있지만 간단한 사용법은 세터에서 예외 처리/유효성 검사가 될 것입니다.

private string _email; 
protected string Email 
{ 
    get { return _email; } 
    set 
    { 
     if(value.IndexOf("@") > 0) 
      _email = value; 
     else 
      throw new ArgumentException("Not a valid Email"); 
    } 
} 

Answer 6

폴 알렉산더는 정확하며 FxCop도 마찬가지입니다.

필드를 비공개로 만들고 파생 클래스가 변수를 직접 변경하지 못하도록 속성을 통해 노출하려고합니다. 속성을 통과하도록 강요하면 기본 클래스에 수정 사항의 유효성을 검사하거나 거부 할 수있는 기회가 부여됩니다.