공용 속성 및 개인 필드를 사용해야합니까 아니면 데이터에 공용 필드를 사용해야합니까?

공용 속성 및 개인 필드를 사용해야합니까 아니면 데이터에 공용 필드를 사용해야합니까?

---

내가 본 대부분의 코드에서 (그래서 thecodeproject.com에서이 작업을 내 코드에서 수행하는 경향이 있음) 클래스에 포함 된 모든 개별 필드에 대해 공용 속성이 생성되는 것을 보았습니다. 다음과 get; set;같은 기본 유형 :

private int myInt;
public int MyInt 
{
     get { return myInt; }
     set { myInt = value }
}

제 질문은 이것이 어떻게 다른가요?

public int MyInt;

퍼블릭 필드 대신 속성을 사용해야한다면이 특정한 경우에 왜 사용해야합니까? (저는 getter와 setter가 실제로 특별한 것을 수행하거나 private 필드의 값을 반환 / 설정하는 대신 하나의 get 또는 set (읽기 / 쓰기 전용) 만있는 더 복잡한 예제에 대해 이야기하는 것이 아닙니다). 추가 캡슐화를 추가하지 않고 IntelliSense에서 멋진 아이콘 만 제공하고 클래스 다이어그램의 특수 섹션에 배치합니다!

---

이 기사 http://blog.codinghorror.com/properties-vs-public-variables/를 참조하십시오.

구체적으로 특별히

• 리플렉션은 변수와 속성에서 다르게 작동하므로 리플렉션에 의존하는 경우 모든 속성을 사용하는 것이 더 쉽습니다.
• 변수에 대해 데이터 바인딩 할 수 없습니다.
• 변수를 속성으로 변경하는 것은 주요 변경 사항입니다.

---

세 가지 이유 :

1. 속성처럼 하위 클래스의 필드를 재정의 할 수 없습니다.
2. 결국 더 복잡한 getter 또는 setter가 필요할 수 있지만 필드 인 경우 변경하면 API가 중단됩니다.
3. 협약. 그것이 바로 그 방법입니다.

나는 내가 생각하지 않는 더 많은 이유가 있다고 확신합니다.

.Net 3.x에서는 다음과 같은 자동 속성을 사용할 수 있습니다.

public int Age { get; set; }

다음과 같이 개인 필드를 직접 선언하는 오래된 학교 방식 대신 :

private int age;

public int Age
{
    get { return age; }
    set { age = value; }
}

이렇게하면 필드를 만드는 것처럼 간단하지만 주요 변경 문제는 없습니다.

---

개인 필드 이름 과 실제로 이름 필드 값을 가져오고 설정 하는 간단한 공용 속성 이름 을 만들 때

public string Name
{
   get { return name; }
}

이 속성을 클래스 외부의 모든 곳에서 사용 하고 언젠가이 클래스 의 Name 속성이 실제로 lastName 필드를 참조한다고 결정하면 (또는 "My name :"+ name) 문자열을 반환하려는 경우 속성 내부의 코드 :

public string Name
{
   get { return lastName; //return "My name: "+name; }
}

외부 코드의 모든 곳에서 공용 필드 이름 을 사용하는 경우 사용한 모든 곳에서 이름 을 lastName 으로 변경해야 합니다.

---

글쎄 그것은 차이를 만듭니다. 공용 데이터는 개체 인스턴스가 알지 못해도 변경 될 수 있습니다. 게터와 세터를 사용하면 객체는 항상 변경 사항을 인식합니다.

데이터를 캡슐화하는 것은 더 나은 구조화 된 디자인을 향한 첫 번째 단계 일 뿐이며 그 자체가 최종 목표는 아닙니다.

---

다음과 같은 경우 속성을 사용해야합니다.

1. 속성의 데이터를 어떤 형식으로 직렬화해야하는 경우.
2. 파생 클래스의 속성을 재정의해야하는 경우.
3. 일부 로직으로 get 및 set 메소드를 구현할 때. 예를 들어, 싱글 톤 패턴을 구현할 때.
4. 인터페이스에서 파생 된 경우 속성이 선언되었습니다.
5. Reflection과 관련된 특정 문제가있을 때.

---

때에 따라 다르지?

이 바로 가기를 만들었 기 때문에 항상 getter 및 setter를 사용합니다.

public int Foo {get; 세트; }

At compile time it is translated. Now you can't get fancy with it, but it is there, and if you need to get fancy you just spell it out later.

However public, private, protected... it's all a matter of who you want to be able to tweak the data. We use inheritance a lot and this is a very common method for us, so that only chidren can edit certain properties.

protected _foo;  
public Foo  
{  
    get { return _foo; }
} //lack of set intentional.

---

There are many reasons why.

Mainly:

• You can do some other functions when the variable is set
• You can prevent setting and provide only get
• Some 'things' only work on properties (DataBinding, for example)
• You can hide the implementation of the property [perhaps it is a ViewState variable, in ASP.NET).

---

The point is - what if further down the line you want to make sure that every time myInt is referenced something special happens (a log file is written to, it's changed to 42 etc)? You can't do that without getters and setters. Sometimes it's wise to program for what you might need, not what you need right now.

---

Actually, if you're using Silverlight, you'll realise that fields cannot be set a static resources and thus you'll have to use a property (even to access a const).

I've realised that when I tried to federate the region names I use in Composite Guidance (PRISM).

However, that's just a language limitations and apart from static/const fields I alsways use properties.

---

The idea is you should not accidentally/unintentionally change the value of a class private field outside. When you use get and set, that means you are changing the class private field intentionally and knowingly.

---

Setting a value into a private field only changes that field,but making them in property you can handle another arguments for example,you can call a method after setting a value

private string _email;
public string Email
{
    get
    {
        return this._email;
    }
    set
    {
        this._email = value;
        ReplaceList(); //**
    }
}

---

In simpler words, answer to your question is the access modifiers i.e. public and private.

If you use:

public int myInt;
public int MyInt 
{
     get { return myInt; }
     set { myInt = value }
}

then both MyInt property and myInt variable is available in the project to be modified. Means, if your class suppose A is inherited by class suppose B, then myInt and MyInt both are available for modification and no check can be applied. Suppose you want myInt value can be set in derive class if some particular condition pass.

This can be achieved only by making field private and property to be public. So that only property is available and conditions can be set based on that.

---

I can't believe that with 11 answers, nobody has said this:

Not all private fields should be exposed as public properties. You should certainly use properties for anything that needs to be non-private, but you should keep as much of your class private as possible.

ReferenceURL : https://stackoverflow.com/questions/1277572/should-i-use-public-properties-and-private-fields-or-public-fields-for-data