비고
이 콘텐츠는 프레임워크 디자인 지침: 재사용 가능한 .NET 라이브러리에 대한 규칙, 관용구 및 패턴, 2판에서 Pearson Education, Inc.의 권한으로 다시 인쇄됩니다. 이 버전은 2008년에 출판되었으며, 이후 세 번째 에디션에서 완전히 수정되었습니다. 이 페이지의 일부 정보는 오래된 것일 수 있습니다.
연산자 오버로드를 사용하면 프레임워크 형식이 기본 제공 언어 기본 형식인 것처럼 표시할 수 있습니다.
일부 상황에서는 허용되고 유용하지만 연산자 오버로드는 신중하게 사용해야 합니다. 프레임워크 디자이너가 간단한 메서드여야 하는 작업에 연산자를 사용하기 시작한 경우와 같이 연산자 오버로드가 악용된 경우가 많습니다. 다음 지침은 연산자 오버로드를 사용하는 시기와 방법을 결정하는 데 도움이 됩니다.
❌ 기본 제공 형식처럼 느껴지는 형식을 제외하고는 연산자 오버로드를 정의하지 마세요.
✔️ 기본 형식처럼 느껴지는 형식에서 연산자 오버로드를 정의하는 것이 좋습니다.
예를 들어, System.String에는 operator==과 operator!=가 정의되어 있습니다.
✔️ DO는 숫자를 나타내는 구조체에서 연산자 오버로드를 정의합니다(예: System.Decimal).
❌ 연산자 오버로드를 정의할 때는 귀엽지 마세요.
연산자 오버로딩은 작업의 결과가 무엇인지 즉시 알 수 있는 경우에 유용합니다. 예를 들어, DateTime를 DateTime에서 빼서 TimeSpan를 얻는 것이 의미가 있습니다. 그러나 논리 공용 구조체 연산자를 사용하여 두 개의 데이터베이스 쿼리를 통합하거나 Shift 연산자를 사용하여 스트림에 쓰는 것은 적절하지 않습니다.
❌ 하나 이상의 피연산자가 오버로드를 정의하는 형식이 아니면 연산자 오버로드를 제공하지 마세요.
✔️ 대칭 방식으로 연산자를 오버로드합니다.
예를 들어 operator==를 오버로드하는 경우에는 operator!=도 오버로드해야 합니다. 마찬가지로, operator<를 오버로드하는 경우, operator>도 오버로드해야 하며, 계속해서 오버로드해야 합니다.
✔️ 오버로드된 각각의 연산자에 맞는 친숙한 이름의 메서드를 제공하는 것이 좋습니다.
대부분의 언어는 연산자 오버로드를 지원하지 않습니다. 이러한 이유로 오버로드 연산자 형식에는 동등한 기능을 제공하는 적절한 도메인별 이름을 가진 보조 메서드가 포함되는 것이 좋습니다.
다음 표에는 연산자 목록과 해당 메서드 이름이 포함되어 있습니다.
| C# 연산자 기호 | 메타데이터 이름 | 친숙한 이름 |
|---|---|---|
N/A |
op_Implicit |
To<TypeName>/From<TypeName> |
N/A |
op_Explicit |
To<TypeName>/From<TypeName> |
+ (binary) |
op_Addition |
Add |
- (binary) |
op_Subtraction |
Subtract |
* (binary) |
op_Multiply |
Multiply |
/ |
op_Division |
Divide |
% |
op_Modulus |
Mod or Remainder |
^ |
op_ExclusiveOr |
Xor |
& (binary) |
op_BitwiseAnd |
BitwiseAnd |
| |
op_BitwiseOr |
BitwiseOr |
&& |
op_LogicalAnd |
And |
|| |
op_LogicalOr |
Or |
= |
op_Assign |
Assign |
<< |
op_LeftShift |
LeftShift |
>> |
op_RightShift |
RightShift |
N/A |
op_SignedRightShift |
SignedRightShift |
N/A |
op_UnsignedRightShift |
UnsignedRightShift |
== |
op_Equality |
Equals |
!= |
op_Inequality |
Equals |
> |
op_GreaterThan |
CompareTo |
< |
op_LessThan |
CompareTo |
>= |
op_GreaterThanOrEqual |
CompareTo |
<= |
op_LessThanOrEqual |
CompareTo |
*= |
op_MultiplicationAssignment |
Multiply |
-= |
op_SubtractionAssignment |
Subtract |
^= |
op_ExclusiveOrAssignment |
Xor |
<<= |
op_LeftShiftAssignment |
LeftShift |
%= |
op_ModulusAssignment |
Mod |
+= |
op_AdditionAssignment |
Add |
&= |
op_BitwiseAndAssignment |
BitwiseAnd |
|= |
op_BitwiseOrAssignment |
BitwiseOr |
, |
op_Comma |
Comma |
/= |
op_DivisionAssignment |
Divide |
-- |
op_Decrement |
Decrement |
++ |
op_Increment |
Increment |
- (unary) |
op_UnaryNegation |
Negate |
+ (unary) |
op_UnaryPlus |
Plus |
~ |
op_OnesComplement |
OnesComplement |
오버로드 연산자 ==
operator == 오버로딩은 매우 복잡합니다. 연산자의 의미 체계는 다음과 같은 Object.Equals여러 다른 멤버와 호환되어야 합니다.
변환 연산자
변환 연산자는 한 형식에서 다른 형식으로 변환할 수 있는 단항 연산자입니다. 연산자는 피연산자 또는 반환 형식에서 정적 멤버로 정의되어야 합니다. 변환 연산자의 유형에는 암시적 연산자와 명시적 두 가지 유형이 있습니다.
❌ 최종 사용자가 이러한 변환을 명확하게 예상하지 못하는 경우 변환 연산자를 제공하지 마세요.
❌ 형식의 도메인 외부에서 변환 연산자를 정의하지 마세요.
예를 들어, Int32, Double, Decimal는 모두 숫자 유형이지만, DateTime는 그렇지 않습니다. 따라서 Double(long)를 DateTime로 변환하는 변환 연산자가 없어야 합니다. 이러한 경우 생성자를 사용하는 것이 좋습니다.
❌ 변환이 잠재적으로 손실될 수 있는 경우 암시적 변환 연산자를 제공하지 마세요.
예를 들어, Double에서 Int32으로의 암시적 변환이 없을 것입니다. 이는 Double가 Int32보다 범위가 더 넓기 때문입니다. 변환이 손실될 수 있는 경우에도 명시적 변환 연산자를 제공할 수 있습니다.
❌ 암시적 캐스트에서 예외를 throw하지 마세요.
변환이 진행되고 있다는 것을 인식하지 못할 수 있으므로 최종 사용자가 무슨 일이 일어나고 있는지 이해하기가 매우 어렵습니다.
✔️ System.InvalidCastException 캐스트 연산자를 호출하면 손실 변환이 발생하며 연산자의 계약이 손실 변환을 허용하지 않는 경우 THROW합니다.
Microsoft Corporation의 일부 저작권 2005, 2009. 모든 권리 보유.
프레임워크 디자인 지침에서 Pearson Education, Inc.의 권한으로 재인쇄 : 재사용 가능한 .NET 라이브러리에 대한 규칙, 관용구 및 패턴, Krzysztof Cwalina 및 Brad Abrams의 제2판, Microsoft Windows 개발 시리즈의 일환으로 Addison-Wesley Professional이 2008년 10월 22일 출판했습니다.