DateTime.Now가 메서드가 아닌 속성 인 이유는 무엇입니까?

DateTime.Now가 메서드가 아닌 속성 인 이유는 무엇입니까?

---

이 블로그 항목을 읽은 후 : http://wekeroad.com/post/4069048840/when-should-a-method-be-a-property ,

Microsoft가 C #에서 선택하는 이유가 궁금합니다.

DateTime aDt = DateTime.Now;

대신에

DateTime aDt = DateTime.Now();

• 모범 사례 : 멤버를 연속으로 두 번 호출 할 때 메서드를 사용하면 다른 결과가 생성됩니다.
• 그리고 DateTime.Now비 결정적 방법 / 속성의 완벽한 예입니다.

그 디자인에 대한 이유가 있는지 아십니까?
아니면 그저 작은 실수라면?

---

저는 C #을 통한 CLR을 믿습니다. Jeffrey Richter는 DateTime.Now가 실수라고 언급했습니다.

System.DateTime 클래스에는 현재 날짜 및 시간을 반환하는 readonly Now 속성이 있습니다. 이 속성을 쿼리 할 때마다 다른 값이 반환됩니다. 이것은 실수이며 Microsoft는 Now를 속성 대신 메서드로 만들어 클래스를 수정할 수 있기를 바랍니다.

C # 3rd Edition을 통한 CLR-페이지 243

---

실제로 결정 론적입니다. 출력은 무작위가 아니지만 꽤 예측 가능한 것을 기반으로합니다.

'현재 시간'은 항상 변경됩니다. 따라서 각 호출에서 상대적으로 "동일"하게하려면 해당 값이 호출 될 때마다 현재 시간을 반환하도록 변경되어야합니다.

편집하다:

이것은 나에게 방금 발생했습니다. 물론, 속성 getter에 대한 두 번의 후속 호출 은 중간에 속성 값이 변경된 경우 다른 결과를 반환 할 수 있습니다 . 속성은 Constants.

그래서, 그것은 (개념적으로) 일어나는 일입니다 DateTime.Now; 그 값은 후속 호출 사이에서 변경됩니다.

---

MSDN에 따르면 어떤 것이 객체의 논리적 데이터 멤버 일 때 속성을 사용해야합니다.

http://msdn.microsoft.com/en-us/library/bzwdh01d%28VS.71%29.aspx#cpconpropertyusageguidelinesanchor1

방법이 더 적절한 경우를 나열합니다. 아이러니 한 것은 메서드의 규칙 중 하나는 연속 호출이 다른 결과를 반환 할 수 있고 물론 Now가 해당 기준을 확실히 충족 할 때이를 사용하는 것입니다.

개인적으로 나는 이것이 여분의 ()에 대한 필요를 제거하기 위해 수행되었다고 생각하지만 ()의 부재는 혼란 스러웠다. VB / VBA의 이전 접근 방식에서 전환하는 데 시간이 조금 걸렸습니다.

---

지침은 그저 어렵고 빠른 규칙이 아닙니다.

이러한 지침은 상태 저장 객체를위한 것이며 실제로 속성이 객체를 변경해서는 안된다고 말합니다. DateTime.Now는 정적 속성이므로 호출해도 개체가 변경되지 않습니다. 그것은 또한 단지 시간의 자연스러운 상태를 반영하는 것이며 아무것도 바꾸지 않습니다. 단순히 끊임없이 변화하는 타이머를 관찰하는 것입니다.

따라서 요점은 개체의 상태를 변경하는 속성을 만들지 않는 것입니다. 상태가 외부 적으로 변경 되더라도 객체의 상태 만 관찰하는 속성을 만듭니다.

또 다른 예로 문자열의 길이를 살펴 보겠습니다. 이것은 속성이지만 다른 것이 문자열을 외부 적으로 변경하면 문자열의 길이가 호출마다 변경 될 수 있습니다. 그것이 기본적으로 일어나고있는 것입니다. 타이머는 외부 적으로 변경되고 있습니다. 이제는 string.Length 또는 기타 속성처럼 현재 상태를 반영합니다.

---

"메소드 대 속성"을 결정할 때 제안 된 테스트는 "연속 호출이 다른 결과를 반환 할 것"입니다. 더 나은 테스트는 유사하지만 동일한 질문은 아니라고 제안합니다. "루틴을 호출하면 동일하거나 다른 루틴에 대한 향후 호출 결과에 영향을 미칠까요?" 지금까지 가장 일반적인 이유에 의해 루틴에 나중에 호출이 이전 한 것이 될 것이라고 전 하나에서 다른 결과를 얻을 것 때문에 대부분의 경우, 두 질문에 대한 답변은 동일합니다 발생 이후 호출이 다른를 반환 그렇지 않은 경우보다 결과.

DateTime.Now의 경우 한 호출이 다른 호출이 반환하는 값에 영향을 미치는 유일한 방법은 첫 번째 호출에 소요 된 실행 시간으로 인해 두 번째 호출이 다른 경우보다 훨씬 늦게 발생하는 경우입니다. pedant는 시간의 경과를 첫 번째 호출의 상태 변경 부작용으로 간주 할 수 있지만 DateTime.Now보다 실행하는 데 더 오래 걸리는 속성이 많이 있으므로 이들 중 하나에 대한 호출은 후속 DateTime.Now 호출에서 반환 된 값을 변경할 가능성이 더 큽니다.

"시간 가져 오기"루틴이 정적 멤버가 아닌 가상 클래스 멤버 인 경우 균형을 메서드로 만드는쪽으로 이동합니다. "예상 된"구현은 객체의 상태에 영향을주지 않지만 일부 구현에는 부작용이있을 가능성이 높거나 적어도 그럴듯합니다. 예를 들어 RemoteTimeServer 개체에서 Now를 호출하면 원격 서버에서 시간을 가져 오려고 시도 할 수 있으며 이러한 시도는 시스템의 나머지 부분에 상당한 부작용을 일으킬 수 있습니다 (예 : 하나 이상의 시스템이 DNS / IP 라우팅 정보를 캐시하도록 함). , 동일한 서버에 액세스하려는 다음 시도가 100ms 더 빠르게 완료됩니다).

---

언제 메서드와 속성을 사용할 지에 대한 명쾌한 규칙이 없기 때문에 DateTime.Now는 실제로 서버 상태의 노출 된 속성을 읽는 것이므로 지속적으로 변경 될 수 있지만 DateTime.Now는 어떤 속성의 상태에도 영향을주지 않습니다. , 개체 또는 그렇지 않은 것이므로 Framework의 속성입니다.

참고 URL : https://stackoverflow.com/questions/5437972/why-is-datetime-now-a-property-and-not-a-method