[C#] 속성 대 방법

빠른 질문 : 언제 C #에서 속성을 사용하기로 결정하고 언제 메소드를 사용하기로 결정합니까?

우리는이 논쟁에 바쁘고 우리가 재산이나 방법을 사용해야하는지 논란의 여지가있는 부분을 발견했습니다. 한 가지 예는 다음과 같습니다.

public void SetLabel(string text)
{
    Label.Text = text;
}

이 예에서는 LabelASPX 페이지의 컨트롤입니다. 이것을 방법으로 만들 것인지 아니면 속성으로 할 것인지 결정 (이 경우)을 지배 할 수있는 원칙이 있습니까?

가장 일반적이고 포괄적 인 답변을 받아들이지 만, 내가 제시 한 예에 대해서도 언급하겠습니다.



답변

로부터 속성 및 메서드 사이의 선택 클래스 라이브러리 개발을위한 디자인 가이드 라인의 섹션 :

일반적으로 메소드는 조치를 나타내고 특성은 데이터를 나타냅니다. 속성은 필드와 같이 사용되어야하며 속성이 계산적으로 복잡하거나 부작용을 발생시키지 않아야합니다. 다음 지침을 위반하지 않으면 경험이 적은 개발자가 속성을 더 쉽게 사용할 수 있으므로 방법보다는 속성을 사용하는 것이 좋습니다.


답변

네, 당신이하고있는 모든 것이 가져오고 설정하는 것이라면, 속성을 사용하십시오.

여러 데이터 멤버에 영향을 줄 수있는 복잡한 작업을 수행하는 경우 방법이 더 적합합니다. 또는 getter가 매개 변수를 사용하거나 setter가 값 매개 변수 이상을 사용하는 경우.

가운데에는 선이 약간 흐려질 수있는 회색 영역이 있습니다. 단단하고 빠른 규칙은 없으며 다른 사람들이 때로는 무언가가 재산인지 방법인지 의견에 동의하지 않을 것입니다. 중요한 것은 자신 이하는 방식 (또는 팀이하는 방식)과 (상대적으로) 일관성을 유지하는 입니다.

그것들은 대체로 상호 교환 가능하지만 속성은 구현이 비교적 “단순”하다는 것을 사용자에게 신호합니다. 아, 그리고 구문은 조금 더 깨끗합니다.

일반적으로 말하자면, get 또는 set으로 시작하고 0 또는 1 개의 매개 변수 (각각)를 사용하는 메소드 이름을 작성하면 특성의 주요 후보라는 철학이 있습니다.


답변

속성은 개체에서 데이터를 주입하거나 검색하는 방법입니다. 클래스 내의 변수 또는 데이터에 대한 추상화를 만듭니다. Java의 getter 및 setter와 유사합니다.

메서드는 작업을 캡슐화합니다.

일반적으로 속성을 사용하여 단일 비트의 데이터 또는 판매 세와 같은 클래스에서 작은 계산을 노출합니다. 장바구니의 항목 수와 비용에서 파생됩니다.

데이터베이스에서 데이터를 검색하는 것과 같이 작업을 만들 때 메서드를 사용합니다. 움직이는 부분이있는 작업은 방법의 후보입니다.

코드 예제에서 클래스를 포함하는 외부에서 액세스 해야하는 경우 속성으로 래핑합니다.

public Label Title
{
   get{ return titleLabel;}
   set{ titleLabel = value;}
}

텍스트 설정 :

Title.Text = "Properties vs Methods";

Label의 Text 속성 만 설정하면 다음과 같이하십시오.

public string Title
{
   get{ return titleLabel.Text;}
   set{ titleLabel.Text = value;}
}

텍스트 설정 :

Title = "Properties vs Methods";


답변

객체의 실제 속성을 설정하는 경우 속성을 사용합니다.

작업 / 기능을 수행하는 경우 방법을 사용하십시오.

귀하의 예에서는 설정되는 명확한 속성입니다.

그러나 기능이 AppendToLabel 인 경우 메소드를 사용합니다.


답변

MSDN을 검색 한 결과, 메소드 작성 에 대한 몇 가지 훌륭한 지침을 제공 하는 특성 대 메소드 에 대한 참조를 찾았습니다 .

  • 작업은과 같은 변환 Object.ToString입니다.
  • 작업 캐시는 사용자에게 결과 캐싱을 고려해야한다는 의사 소통을하기에 충분히 비쌉니다.
  • get 접근자를 사용하여 속성 값을 얻는 것은 관찰 가능한 부작용이 있습니다.
  • 멤버를 두 번 연속으로 호출하면 다른 결과가 생성됩니다.
  • 실행 순서가 중요합니다. 유형의 속성은 어떤 순서로든 설정하고 검색 할 수 있어야합니다.
  • 멤버는 정적이지만 변경할 수있는 값을 반환합니다.
  • 멤버가 배열을 반환합니다. 배열을 반환하는 속성은 매우 잘못 될 수 있습니다. 일반적으로 사용자가 내부 상태를 변경할 수 없도록 내부 배열의 사본을 반환해야합니다. 이는 사용자가 자신이 색인화 된 속성이라고 쉽게 가정 할 수 있다는 사실과 함께 비효율적 인 코드로 이어집니다.

답변

“Property”라는 이름 만 보면됩니다. 무슨 뜻인가요? 사전은 여러 가지 방법으로 사전을 정의하지만이 경우 “필수 또는 특유의 속성 또는 사물의 품질”이 가장 적합합니다.

행동의 목적에 대해 생각하십시오. 실제로, “필수 또는 특유의 속성”을 변경 또는 검색하고 있습니까? 예제에서 함수를 사용하여 텍스트 상자의 속성을 설정하고 있습니다. 어리석은 것 같아요?

속성은 실제로 함수입니다. 모두 getXXX () 및 setXXX ()로 컴파일됩니다. 그것은 단지 구문 설탕으로 그것들을 숨기지 만, 과정에 의미 론적 의미를 제공하는 설탕입니다.

속성과 같은 속성을 생각하십시오. 자동차에는 많은 속성이 있습니다. 색상, MPG, 모델 등. 모든 속성을 설정할 수있는 것은 아니며 일부는 계산할 수 있습니다.

한편, 방법은 행동입니다. GetColor는 속성이어야합니다. GetFile ()은 함수 여야합니다. 경험의 또 다른 규칙은 객체의 상태를 변경하지 않으면 기능이어야한다는 것입니다. 예를 들어 CalculatePiToNthDigit (n)은 연결된 Math 객체의 상태를 실제로 변경하지 않기 때문에 함수 여야합니다.

이것은 약간 혼란 스러울 수 있지만 실제로는 객체가 무엇인지, 무엇을 나타내는 지 결정하는 것으로 요약됩니다. 그것이 속성인지 함수인지 파악할 수 없다면 어떤 것이 중요하지 않을 수 있습니다.


답변

시맨틱 속성은 객체의 속성입니다. 메소드는 객체의 동작입니다.

레이블은 속성이며 속성으로 만드는 것이 더 합리적입니다.

객체 지향 프로그래밍과 관련하여 동작의 일부와 속성에 대한 명확한 이해가 있어야합니다.

자동차 {색상, 모델, 브랜드}

자동차에는 색상, 모델 및 브랜드 속성이 있으므로 의미 상 자동차에 자체 색상을 설정하도록 요청하지 않기 때문에 SetColor 또는 SetModel 메소드를 갖는 것은 의미가 없습니다.

따라서 속성 / 메소드 사례를 실제 객체에 매핑하거나 시맨틱 관점에서 보면 혼란이 사라질 것입니다.