모어 이펙티브 C#(2판) - 맛보기

}
=> $"{FirstName} {LastName}";
기존 코드가 암묵적 속성을 사용했었다면, 데이터 검증을 위해 명시적 속성으로 변경하더라도
검증에 필요한 코드를 모두 한 곳에 둘 수 있다. 이후에도 데이터 필드에 직접 접근하지 않고
속성 접근자를 사용하면 검증 코드를 계속 한 곳에만 유지하면 된다.
이러한 장점에도 불구하고 암묵적 속성에는 중요한 제약이 하나 있다. 바로 Serializable 특
성 attribute 을 사용한 타입에는 사용할 수 없다는 것이다. 클래스를 위한 영구 파일 저장소의 포맷
은 암묵적 속성을 위해 컴파일러가 자동 생성한 뒷단 필드의 이름에 영향을 받는다. 그런데 이
필드의 이름이 변경되지 않을 것임을 보장할 수가 없다. 더 구체적으로 말하면, 클래스를 수정
한 후 다시 컴파일하면 뒷단 필드의 이름이 변경될 수 있다.
이런 제약에도 불구하고 암묵적 속성은 개발자의 시간을 절약해주며 코드 가독성을 높여줄 뿐
아니라, 필드를 수정할 때 값을 검증하기 위한 코드를 추가하는 경우에도 검증 코드를 단 한 군
데만 둘 수 있도록 도와준다. 코드를 이처럼 깔끔하게 유지하면 유지 보수하기도 편하다.
아이템 3: 값 타입은 변경 불가능한 것이 낫다
변경 불가능한 타입(불변 타입) immutable type 은 이해하기 쉬운데, 한 번 생성된 후에는 그 값을 변
경할 수 없는 타입을 말한다. 변경 불가능한 타입으로 객체를 생성할 때 매개변수를 검증했다
면, 그 객체의 상태는 항상 유효하다고 할 수 있다. 객체의 내부 상태를 변경할 수 없기 때문이
다. 또한 생성 후 상태 변경을 허용하지 않기 때문에 불필요한 오류 확인에 들이는 노력을 많이
줄일 수 있다. 변경 불가능한 타입은 본질적으로 멀티스레드에 대해서도 안전 thread safe 하다, 즉,
여러 스레드가 동일한 콘텐츠에 접근해도 안전하며, 내부 상태를 변경할 수 없으므로 여러 스
레드가 항상 동일한 값에 접근하게 된다. 같은 이유로 호출자 측으로 객체를 노출하더라도 안
전하다.
변경 불가능한 타입은 해시 기반의 컬렉션에서도 빛을 발한다. Object.GetHashCode ()
가 반환하는 값은 반드시 인스턴스별로 고정된 값 instance invariant 이어야 하는데(아이템 10:
GetHashCode()의 위험성을 이해하라 참조), 변경 불가능한 타입에서는 항상 성립하는 조건이다.
30 모어 이펙티브 C#