데이터 맴버 대신에 항상 Property를 이용하라
- public data member를 줄이고, 이를 확립시키기 위한 방법으로 property를 주로 이용하라.
- IL에서 접근하는 방식상 Property로 작성이 될때에, 코드의 호환성이 좀더 더 유지된다.
const보다는 readonly가 더 좋다.
- compile type : runtype 상수 보다는 다소 빠르지만 유연성이 떨어진다. (const)
- 수행 성능이 매우 중요할 때 사용.
- 상수의 값이 절대로 바뀌지 않을 때에 사용.
- 내장 자료형태, enum, string에서만 사용 가능하다. [DateTime에서는 사용 불가능]
- Program의 버젼등을 적어놓는데에는 반드시 const가 되어야지 된다.
- runtype : 프로그램의 수행시에 평가 된다.(readonly)
- 수행 성능의 개선 효과가 크다.
- 유연성이 증가 된다.
- const형으로 정의된 public 상수에 대한 갱신은 매우 신중히 고려되어야지 된다.
- 값이 바뀌는 경우에는 반드시 전체 컴파일을 해주어야지 된다.
cast 보다는 is와 as가 좋다
- 좀더 안정적인 방법이다.
- 사용자가 정의한 형변환 연산자의 존재를 고려하지 않기 때문에 runtime의 수행성능 효율도 올라간다.
- 형 변환시에 어떤 상태로 동작하게 되는지를 결정하고, 이를 판단 가능하다.
- 변환이 되지 않을 때에는 null의 반환으로 편하게 확인이 가능하다.
- value 형태에서는 동작하지 않는다.
- 형변환는 가능한한 피하는 것이 좋다
#if 대신 Condition Attribute를 이용하라.
- #if~#endif문은 정의된 내용을 기반으로 Program의 코드를 제어한다.
- 가독성이 떨어지는 단점이 있다.
- [Condition("DEBUG")] : DEBUG가 정의가 된 상태에서만 compile이 되는 구문으로 만들어진다.
- 다수의 Condition이 결정되는 경우, or로 움직이게 된다.
항상 ToString()을 작성하라.
- 객체의 표현 방법을 쉽게 출력 가능하다.
- System.Object의 override 형태로서, 다양한 방법으로 작성이 가능하다.
- .NET Framework에서는 항상 자신의 형태를 ToString()을 통해서 표현하게 된다.
- IFormattable interface의 작성 규칙
- 일반적인 출력 형태를 위해 "G" 문자열을 지원해야지 된다.
- 비어있는 문자열과 null을 고려해줘야지 된다.
- "G" 문자열과 비어있는 문자열, null의 반환 값은 항시 동일해야지 된다.
value 타잎과 reference 타잎을 구분하라
- value type : 다형적이지 않기 때문에 application이 직접 다루는 값을 정의하는데 주로 사용된다.
- struct 타잎으로 구성된다.
- 값을 저장하는 용도로만 제한하는 것이 좋다.
- 모든 struct type을 seal 형태로만 사용하는 것을 고려할 것
- 저 수준의 자료 저장소로만 생각하자
- reference type : 다형적이기 때문에 application의 동작을 정의하는 데에 주로 사용한다.
- class 타잎으로 구성된다.
- 배열의 형태시에 메모리 할당에서 시간이 더 많은 공간을 조각내게 된다.
- 객체 공간 (heap)을 조각내게 되는데, 속도가 전체적으로 떨어지게 된다.
- Value 타잎을 사용해야지 되는 경우 판단 (4개가 모두 OK가 나오는 경우에만 사용할것!!)
- 데이터를 저장하는데에만 이용되는가?
- 모든 public interface가 내부적인 값을 획득하거나 수정하기 위해서만 사용되는가?
- 상속될 가능성이 전혀 없는가?
- 다형적으로 다루어져야 할 필요가 없는가?
Immutable atomic value 타잎으로 작성하라
- 생성된 이후에는 마치 상수와 같이 변경될 수 없는 타잎이다.
- 단일의 요소로 분리할 수 있는 부분은 구조체로 작성하는 것이 좋다.
- 타잎에 아무런 의미없는 get/set property를 만들지 말자.
value 타잎을 사용할 땐 0이라는 값이 의미를 가질 수 있도록 하라
- 기본적으로 .NET Framework는 value 타잎으로 만들 때에, 0로 값을 초기화 한다.
- [Flags] : Bit 연산이 가능하게 하는 Attribute
- 이 때에는 특히 0의 값의 연산이 되지 않을 때에는 사용에 문제가 생긴다.
ReferenceEquals(), static Equals(), instance Equals(), operator==의 상호 연관성을 이해하라.
- public static bool ReferenceEquals(object left, object right)
- public static bool Equals(object left, object right)
- public virtual bool Equals(object right)
- public static bool operator==(Myclass left, Myclass right)
- ReferenceEquals() : 반드시 재정의 하면 안된다.
- 두 개의 변수가 동일 객체를 참조하는 경우 true를 반환한다.
- value 형태에서는 반드시 false를 반환한다.
- static Object.Equals() : 반드시 재정의 하면 안된다.
- 타잎을 명확하게 알기 힘든 변수들 간에 비교를 수행
- Reference 타잎에서는 ReferenceEquals()와 동일하다.
- value 타잎에서는 주어진 변수의 타잎이 같고, 내용이 일치하는 경우에서만 true가 반환된다.
- instance에서의 Object.Equals() : 재정의가 필요할 때도 있다.
- 동일성의 의미를 확인한다.
- 절대로 예외를 발생해서는 안된다.
- 반드시 this.GetType()에서 타잎을 획득해야지 된다.(상속 받은 내용의 경우 예상 외의 결과가 나타날 수 있다.)
- value 형태에서는 반드시 재정의 되어야지 된다.
- reference 형태에서는 동작 방식에 따라 재정의가 수행되어야지 된다.
- operator==
- value 형태에서는 반드시 재정의 되어야지 된다.
- reference 형태에서는 동작 방식에 따라 재정의가 수행되어야지 된다.
- instance에서의 Object.Equals()가 재정의되는 경우에만 반드시 재정의 되어야지 된다.
GetHashCode()의 함정에 유의하라
- 단 한가지 경우에만 재정의 해야지 된다.
- Dictionary와 같이 Hash code를 기반으로 하는 key로 활용될 때 이외에는 절대 재정의 되어서는 안된다.
- 재정의 하는 경우 다음의 규칙을 반드시 지켜야지 된다.
- 객체가 동일한 경우, 같은 Hash code를 반환하도록 만들어야지 된다.
- 인스턴스가 생성된 후에, 변경되지 않아야지 된다. : Type내의 불변의 값을 이용해서 만들어준다.
- integer 형태에서 표현되어야지 된다.
- System.Object.GetHashCode() : 인스턴스의 생성, 삭제시에 증가/감소로 값이 만들어진다.