잊지 않겠습니다.

데이터 맴버 대신에 항상 Property를 이용하라
  1. public data member를 줄이고, 이를 확립시키기 위한 방법으로 property를 주로 이용하라.
  2. 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() : 인스턴스의 생성, 삭제시에 증가/감소로 값이 만들어진다. 

  

foreach 루프가 더 유용하다.
  • 모든 collection에서 최고의 순회 코드를 만들어 낼 수 있다.
  • Length property를 밖으로 꺼내는 것은 가장 느린 코드를 만들어낸다!! 
  • 안정적이다. 
    • 읽기 전용으로 동작한다.
    • 올바른 형변환을 나타낸다.
  • 다차원 배열일때도 더 확실하게 동작한다. [영상처리에는 영 안좋을것 같다. -_-]
Posted by Y2K
,