Effective C#

책 보면서 정리 ...

• 멤버 엑세스에 프로퍼티 사용

세터와 게터를 사용하란 말씀. 실제 닷넷 프레임워크 내부에서도 프로퍼티 접근이 아니면 멤버 데이터 접근이 불가능하게 되어 있고 그렇게 권하고 있다. 아마 C# 3.0 부터는 단순한 입출력을 위한 프로퍼티는 자동으로 생성되기도 합니다.
이 내용은 OOP의 캡슐화에 대한 내용과 같다.
또한 최근 잦은 이슈의 병렬프로그래밍에서도 직접 멤버를 억세스하는 것 보다 메서드 형태의 프로퍼티 사용이 더욱 효과적이다.
그 외 가상, 추상, 인터페이스 등의 언어적 특성에 대한 내용은 패스!
C#의 Indexer 기능 때문에라도 프로퍼티를 추천. (인덱서는 클래스당 하나만 가능. 즉, 타입당 하나만 가능. this 를 사용하는 이유기도 하고...)
당연하겠지만 IL 코드에서 직접 퍼블릭 멤버를 억세스하는 것과 프로퍼티를 통한 억세스를 하는 것이 다르게 컴파일 된다.

예를 보면

public class Customer {
    public string Name;
}

Customer cs1 = new Customer();
string member1 = cs1.Name;
cs1.Name = "Dont Use this";

위 처럼 사용하지 말란 말.
아래처럼 코딩하란 말.

public class Customer {
    // 3.0 이전 코드
    private string name;
    public string Name {
        get { return name; }
        set { name = value; }
    }
    // 3.0 부터는 아래처럼 사용 가능합니다.
    public string Name {
        get;
        set;
    }
}

Customer cs1 = new Customer();
string member1 = cs1.Name;
cs1.Name = "Do Use this";

실제 사용하는 법은 다를게 없지만 IL 도 다르고 속도에도 큰 영향이 없다고 한다.
흠 OOP 개발이라면 다 이렇게 하지 않나 ㅋㅋ

• const 보다 readonly 가 좋을 때가 있다.
  

C#의 상수형은 컴파일타임의 상수와 런타임의 상수 두 종류가 있기 때문이다. 적절한 상수형을 알고 사용하는 것이 아무래도 좋지 않겠냐는 것이다.
 

const 는 컴파일타임에 결정되고
readonly 는 런타임에 결정된다.

당연히 컴파일타임의 상수가 빠르지만 유연성이 떨어진다. 컴파일타임 상수는 절대로 값이 바뀌지 않을 상수에 사용한다. 예상한 내용이다. const 는 컴파일 때 값이 치환된다. 반면 readonly 는 런타임때 치환된다. 그 전에는 해당 값(상수)에 대한 참조가 위치한다.
이런 차이로 인해 const 값는 한계가 있다. 당연한 것이 실제 값이 할당 되는 시점이 컴파일 할 때이기 때문이다. const 는 숫자, 문자 및 문자열에 대한 선언만 가능하다. 반면 readonly 는 어떤 자료형이라도 가능하다.

이 차이의 근본적인 이슈는 배포에 있다.

const 로 상수를 처리하고 프로그램 배포 이후 특정 모듈 패치시에 상수값이 변경된 경우 프로그램 전체를 재 컴파일해서 배포해야하는 문제가 발생되지 않을 것이다. 반면 readonly 일 경우 수정된 부분만 패치하여도 참조로 상수값을 처리하였기 때문에 좀 더 안전한 프로그램으로 관리될 것이다.

물론 성능에는 const 가 더 빠르기 때문에 절대로 값이 변하지 않을 곳에 사용할 것.

• 타입 cast 보다 is 나 as 가 좋다.
  

is 명령은 해당 값이 특정한 타입으로 변경 가능한지 확인하기 위해 사용한다.
as 는 해당 값을 특정한 타입으로 변환하여 처리한다.

즉, 강제적인 캐스팅을 자제해달라는 말인 것 같다. as 로 캐스팅하는 것이 안전하다고 한다.

코드를 한번 보자.

object o = Factory.GetObject();
try {
    Mytype t;
    t = (Mytype) o;
    if (t != null) {
        // t
    } else {
        // null 에러 처리
    }
} catch {
    // casting 오류
}

기존의 C 스타일이다. try, catch 에 대한 낭비가 있다. 캐스팅에 대한 컴파일 에러 출력이 불가능하다 런타임 에러 예측이 가능하지만 컴파일 시에는 불가능하다.

object o = Factory.GetObject();
Mytype t = o as Mytype;
if (t != null) {
    // Mytype 형의 t 에 대한 처리
} else {
    // 예외 발생 대신 에러 처리 - 캐스팅 실패
}

만약 타입변환이 실패한다면 컴파일 에러를 알려줄 수 있다. 더 안전한 코딩이 가능하다.

as 연산자는 캐스팅이 실패할 경우 null 을 반환한다.

is 연산자는 as 연산자로 캐스팅이 불가능할 경우 해당 타입을 판별하기 위한 명령으로 사용하는 것이 좋다. 중복연산을 방지하자.

object o = Factory.GetValue();
Mytype t = null;
if (o is Mytype) {
    t = o as Mytype;
    // t 처리 코드
}

위와 같은 코드는 중복 연산에 해당된다고 볼 수 있다. as 연산을 통해 리턴값이 null 인지 판별하면 그만이다.

나머지 책 보면서 정리해보도록 하겠음... 오늘은 여기까지.