Wild Flower

특히 프로퍼티를 읽고/쓰는 경우 C#은 이러한 개념을 처리하는 데 있어 좀 더 깔끔한 방법을 제공한다. get과 set 메소드간의 관계는 Java나 C++에서 유지하는 것에 비해 C#은 고유한 방식을 취한다. 이러한 접근법에는 많은 이점이 있다. 이는 프로그래머로 하여금 프로퍼티의 관점에서 생각하도록 하는데, 프로퍼티가 읽기/쓰기인지, 읽기 전용인지, 혹은 그것이 전혀 프로퍼티가 아니어야 할지에 있어 가장 자연스러운 방식이기 때문이다. 만약 여러분이 프로퍼티의 이름을 변경하고자 할 경우 여러분은 단지 한 곳만 살펴보면 된다(필자는 각각의 접근자 메소드와 설정자 메소드가 서로 수 백 라인이나 떨어져 있던 것도 본적이 있다). 주석은 딱 한 번만 달면 되고 서로 동기화가 안맞는 일은 발생하지 않을 것이다. 그러한 작업은 IDE에서 도와주는 것이 적합하겠지만(사실 필자도 그렇게 하기를 권장한다) 한 가지 기억해야할 프로그래밍에서 가장 중요한 원칙은 현실의 문제에서 일정한 거리를 둔 추상화(abstraction)를 위해 노력하는 것이다. 프로퍼티를 지원하는 언어는 좀 더 나은 추상화의 이점을 누리게 해줄 것이다.

이것의 장점을 누리는 데 있어 한 가지 발생가능한 논쟁거리는 여러분이 이 문법을 이용하여 필드를 조작하는지 아니면 프로퍼티를 조작하고 있는지를 모른다는 것이다. 그러나 Java에서(물론 C#에서도) 설계되어 있는 정말로 복잡한 로직을 가진 거의 대부분의 모든 클래스에서는 public 필드를 갖지 않는다. 필다는 일반적으로 제한된 접근 수준(private/protected/default)을 가지며 오직 접근자/설정자 메소드만를 통해 외부로 노출되는데, 이것 보다는 더 나은 문법을 가지는 게 낫다. 또한 IDE가 코드를 읽어들여 프로퍼티를 다른 색상으로 강조하거나 그것이 프로퍼티인지 아닌지를 나타내는 코드완성 기능을 제공하도록 하는 것이 좋다. 또한 만약 한 클래스가 잘 설계되어 있을 경우, 그 클래스의 사용자는 오직 그 클래스의 명세에만 신경써야 하고 그 클래스의 구현에는 신경쓰지 말아야 함을 주의해야 한다. 다른 발생가능한 논쟁거리는 그렇게 하는 것이 덜 효율적이라는 것이다. 사실 좋은 컴파일러는 단지 필드를 리턴하기만 하는 기본 접근자 메소드를 인라인 시켜 필드만큼 빠르게 만들어 줄 수 있다. 마지막으로 접근자/설정자에 비해 필드를 사용하는 것이 좀 더 효율적이더라도 프로퍼티에 기반한 소스코드를 건드리지 않고 나중에 필드를 프로퍼티로 변경할 수 있도록 하는 것이 좋다.

출처 : http://decoder.tistory.com/96