C#의 Generic을 다루다보면 한 가지 불편한 점을 확인할 수 있는데, where 절에 의하여 값 형식인지 아닌지 제한이 가능함에도 실질적인 다른 값 형식들 (대표적으로 Integer, Boolean, Double, 각종 나열상수 및 구조체들)로의 변환이 문법적으로 허용되지 않는 것을 볼 수 있습니다.
형식 안정성에 관한 문제가 발생하기 때문에 이와 같은 동작은 온당한 것이지만 가끔 문제가 됩니다. 다음의 코드를 보기로 합니다.
public static T CastValue<T>(this object o, T fallback)
where T : struct
{
if (o is string)
{
string temp = (string)o;
if (RegexCache.NumberExpression.IsMatch(temp))
return (T)Convert.ChangeType(Double.Parse(temp), typeof(T));
else if (Boolean.TrueString.Equals(temp))
return (T)Convert.ChangeType(true, typeof(T));
else if (Boolean.FalseString.Equals(temp))
return (T)Convert.ChangeType(false, typeof(T));
}
if (o == null || o is DBNull || o.Equals(DBNull.Value))
return fallback;
else
return (T)o;
}
Convert.ChangeType 메서드는 이런 경우 진가를 발휘합니다. 비록 형식 안정성의 원칙에 어긋나지만 프로그래머에게 자유를 선사한다고 볼 수 있습니다.
'Software Development > .NET Framework' 카테고리의 다른 글
| [C# 고급] Generic을 이용한 선택적 Extension Method 설정 (0) | 2009/04/10 |
|---|---|
| configSource 어트리뷰트의 실용적인 활용 사례 (0) | 2009/01/15 |
| C#의 Generic을 다루다보면... (0) | 2008/12/26 |
| 개발자가 놓치기 쉬운 닷넷의 기본 원리 #3: 상속과 interface의 문제점 (0) | 2008/08/18 |
| 개발자가 놓치기 쉬운 닷넷의 기본 원리 #2: 닷넷은 Pointer 환경이다? (닷넷에는 Pointer밖에 없다?) (0) | 2008/08/18 |
| 개발자가 놓치기 쉬운 닷넷의 기본 원리 #1: 객체 지향의 구멍 static (0) | 2008/08/18 |