이 포스트를 만든 목적
- 심심해서
이 포스트의 준비 상황
- gVim 7.2
- Microsoft Visual C# 2010 Express
참조 링크
- http://msdn.microsoft.com/en-us/library/85w54y0a.aspx
- http://msdn.microsoft.com/en-us/library/09479473(VS.80).aspx
내용
우선 여기서 말하는 "형변환 연산자(Conversion Operator)"는 C#에서 이며, 연산자 정의를 말하는 것이다. 혼동이 없어야 한다. C# 에선 형변환 연산자가 다음의 규칙을 따르게 된다.
- implicit 으로 형변환 연산자를 구현하면, 해당 타입이 필요 할 때, 자동으로 변환 된다.
- explicit 으로 형변환 연산자를 구현하면, 명시적 캐스팅으로 변환된다.
- 모든 형변환 연산자는 static으로 구현해야 한다.
왜 형변환 연산자의 구현을 피해야 하는가?
대표적으로 두개의 문제 때문인데, 다음:
- 형변환 되어 나온 객체는 임시 객체이다. 그러므로 작업 결과를 돌려 받기 힘들다.샘플 코드를 보라
- 위 문제를 해결하기 위해서, 내부값을 반환하게 된다.
- 이게 문제인 이유는 바로 캡슐화를 무너뜨리기 때문이다.(코드 생략)
그러면 어떻게 피해야 하는가?
- 임시 객체를 이용하지 않고, 새로운 객체를 만들어서 사용하고, 그 결과를 사용한다.
결론
- 형변환 연산자는 다른 형으로 변환 되어, 작업 되길 바래서 존재한다. 하지만 임시객체이므로, 작업 변화에 대해서는 영향을 받을 수 없다. 그러므로 되도록 형변환 연산자를 구현하기 보다, 다른 방법을 사용하게 좋다.
여담
- 대안으로 나온 새로운 객체를 만드는 것, 이것 자체가 나는 부담스럽다. 어떻게 해서든 이러한 경우를 다 피해 가야겠다.
- 졸려서 뇌가 안돌아 간다. 잠 자야겠다.
'책 정리 > Effective C#' 카테고리의 다른 글
item 33, 타입의 가시성을 제한하라. (0) | 2010.08.01 |
---|---|
item 32, 작고 응집도가 높은 어셈블리가 더 좋다. (0) | 2010.07.31 |
item 31, 작고 단순한 메서드가 더 좋다. (0) | 2010.07.25 |
item 30, CLS를 준수하는 어셈블리가 더 좋다. (0) | 2010.07.25 |
item 29. 기반 클래스의 변경이 영향을 줄 경우에만 new 한정자를 사용하라. (0) | 2010.07.22 |
item 27, ICloneable의 구현을 피하라 (4) | 2010.07.20 |
item 26, IComparable과 IComparer를 이용하여 순차관계를 구현하라 (6) | 2010.07.19 |
item 25, serializable 타입이 더 좋다. (0) | 2010.07.18 |
item 24, 명령적 프로그래밍보다 선언적 프로그래밍이 더 좋다. (0) | 2010.07.14 |
item 23, 클래스 내부 객체에 대한 reference 반환을 피하라. (0) | 2010.07.11 |
최근댓글