C#의 컴파일 타임 다형성

C#의 컴파일 타임 다형성

 

객체 지향 프로그래밍은 다형성이 구멍의 또 다른 스레드인 토끼 구멍입니다. 얼마나 깊이 들어갈 수 있는지 봅시다.

Unsplash에 있는 Thalia Tran의 사진

이 기사는 컴파일 시간 다형성의 미스터리를 풀기 위한 여정으로 당신을 데려갈 것입니다. 플러스 인 C# 메서드 오버로딩 및 재정의와 함께 상황을 악화시킬 수 있는 적절한 재료가 있으며 메서드 은닉 개념도 있습니다. 이는 다형성의 전체 아이디어를 약간 당혹스럽게 만듭니다. 그래서 저는 아이디어를 3부분으로 나누어 혼동을 없애려고 합니다.

이것은 다형성에 대해 자세히 알아볼 3개의 기사 시리즈입니다. 다음은 퍼즐의 3개 조각입니다.

1. 컴파일 타임 다형성
2. 런타임 다형성
3. 메소드 은폐/섀도잉

컴파일러는 메서드의 서명을 기반으로 컴파일 타임에 호출할 메서드를 알고 있기 때문입니다. 이 종속성은 컴파일 시간에 해결됩니다. 확인! 이것은 이론상으로는 좋아 보이지만 실제로 어떻게 작동하는지 봅시다.

HOLD ON SEC!!, 그런데 메서드 서명이란 무엇을 의미합니까?

글쎄, 어떤 방법이든 4조각이 있다.

1. 메서드 이름,
2. 반환 유형,
3. 매개변수,
4. 반환 유형

목록 1: 메서드 서명

반환 유형이 메서드 서명의 일부여야 하는지 여부에 대해 개발자 커뮤니티 사이에 엄청난 논쟁이 있습니다!!

Microsoft에서 그 혼란을 해소하는 것은 어떻습니까?

처럼 Microsoft에 따르면 "메소드의 반환 유형은 메서드 오버로딩을 위한 메서드 서명의 일부가 아닙니다. 그러나 대리자와 대리자가 가리키는 메서드 간의 호환성을 결정할 때 메서드 서명의 일부입니다."

간단히 말해서 "메소드 재정의"하는 동안 반환 형식은 메서드 서명의 일부로 고려됩니다.

"메서드 오버로딩" 동안에는 단순히 무시됩니다.

실제 코딩을 통해 다형성을 단계별로 이해하고 코딩 예제를 통해 위의 주장을 뒷받침하는 동작을 학습합니다.

메서드를 오버로드하는 동안 알아야 할 몇 가지 규칙이 있습니다.

1. Type 매개변수의 개수는 달라야 하며 매개변수의 이름은 중요하지 않습니다.
2. 매개변수의 수는 달라야 합니다.
3. 매개변수의 순서는 달라야 합니다.
4. 마지막으로 가장 중요한 것은, return-type, access specifiers 또는 static, abstract, sealed, virtual 고려되지 않습니다.

이러한 규칙을 설명하기 위해 이 기사 전체에서 UML에 따라 코드를 작성할 것입니다. 여기서는 메소드 오버로딩의 거의 모든 측면을 다룹니다.

우리가 디자인하고 있다고 상상해보십시오. class superhero 우리의 임무는 수트를 맞춤화하는 것입니다. 다양한 주장이 제기될 수 있습니다. 슈트의 색상, 슈트의 유형, 영웅이 속옷을 벗는 것을 좋아하는지 여부 등이 있습니다. 이 점을 충족하는 클래스를 디자인해 보겠습니다.

다음 코드 스니펫에서 우리는 "Superman"을 위한 슈트를 디자인하고 있습니다.

목록 2: SuperHero 클래스

이 코드는 기본 슈퍼히어로가 슈퍼맨이 되기를 원하는 한 작동합니다. 하지만 사실을 직시하자. 그는 그렇게 대단한 사람이 아니다. 따라서 다른 슈퍼히어로의 슈트를 맞춤화하기 위해 별도의 method CustomizeSuit().

내가 말했다 typeOfSuit 가죽이나 금속 수트를 맞춤화하고 싶습니다. 이것을 코딩하기 위해 간단히 하나를 수락하는 메서드를 만들 수 있습니다. string type 매개변수 typeOfSuit.

목록 3: 하나의 매개변수가 있는 CustomizeSuit 메서드

규칙 #1: 매개변수 유형은 달라야 하며 매개변수 이름은 중요하지 않습니다.

내 슈퍼히어로는 금속 수트에 관심을 표명하는데, 이제 그는 분명히 그 위에 속옷을 입을 수 없습니다. 그래서 나는 단순히 오버로드 할 수 있습니다 CustomizeSuit() method 다른 유형의 매개변수를 허용합니다. 여기에서 우리는 boolean type이 매개변수의 값이 true 그러면 우리의 영웅은 속옷을 밖에서 입을 것입니다.

목록 3: 부울 매개변수가 있는 오버로드된 메서드 CustomizeSuit

규칙 #2: 매개변수의 수는 달라야 합니다.

어떤 사용자는 양복의 유형을 사용자 정의하거나 속옷의 배치를 결정하기를 원하지만 다른 사용자는 두 가지를 함께 변경하는 데 관심이 있을 수 있습니다. 다른 수의 매개변수를 사용하여 메서드를 오버로드하여 간단히 이 작업을 수행할 수 있습니다.

목록 4: 문자열 및 부울 매개변수 2개가 있는 오버로드된 메서드 CustomizeSuit

규칙 #3: 매개변수의 순서는 달라야 합니다.

동일한 수의 매개변수를 가질 수 있지만 순서는 달라야 합니다. 예를 들어 다음에서 코드를 가져올 수 있습니다. listing 4 그리고 이것을하십시오.

목록 5: 부울 및 문자열 매개변수 2개가 있는 오버로드된 메서드 CustomizeSuit

목록 5 설명: 나는 단지 목록 5에서 매개변수의 순서를 교환할 뿐입니다. 컴파일러는 매개변수의 인덱스와 해당 유형을 찾습니다. 만약에 Type 동일한 인덱스에서 다르면 유효한 오버로드된 방법입니다.

또 다른 변형은 목록 6과 같을 수 있습니다.

목록 6: 2개의 매개변수 문자열 및 문자열이 있는 오버로드된 메서드 CustomizeSuit

규칙 #4: 마지막으로 반환 유형, 액세스 지정자 또는 static, abstract, sealing, virtual과 같은 기타 멋진 키워드는 의미가 없습니다.

우리는 그것에 대해 완전히 야생으로 가자, 그렇지?

규칙 #4.1: 리턴 타입은 고려하지 않습니다.

다음 예에서는 두 가지 방법 사이에서 모든 것이 동일합니다. return-type. 서명은 같지만 서명이 다른 2가지 방법이 있는 경우 return-type, 메서드 오버로딩으로 간주되지 않습니다. 컴파일러는 컴파일 타임 예외를 발생시킵니다.

목록 7: 서명은 같지만 반환 유형이 다른 오버로드된 메서드 CustomizeSuit

예외: 유형 ‘SuperHero’ 라는 멤버를 이미 정의하고 있습니다. ‘CustomizeSuit’ 동일한 매개변수 유형을 사용합니다.

이미지 1: 반환 유형이 무시되는 예외의 스냅샷

규칙 #4.2: 액세스 지정자는 무시됩니다.

규칙 4.1은 꽤 멋졌습니다. 이제 규칙 번호 4.2에 대해 액세스 지정자를 변경해야 합니다.

목록 8: 서명은 같지만 액세스 지정자가 다른 오버로드된 메서드 CustomizeSuit

같은 좋은 예외!!

이미지 2: 액세스 지정자가 무시되는 예외의 스냅샷

규칙 #4.3: 특수 키워드는 무시됩니다.

다음 스냅에서 볼 수 있는 키워드는 오버로드된 메서드와 함께 작동하지 않습니다. 따라서 이러한 키워드로 메서드를 장식하는 것은 오버로딩 개념에 아무런 의미가 없습니다.

참고: 추상 메서드의 경우 클래스를 추상으로 표시했습니다.

이미지 3: CustomizeSuit 메서드에 다른 데코레이터가 있는 몇 가지 예

무엇보다도 메소드는 동일한 예외에 해당합니다.

유형 ‘SuperHero’ 라는 멤버를 이미 정의하고 있습니다. ‘CustomizeSuit’ 동일한 매개변수 유형으로

이미지 4: 컴파일 시간 예외

우리는 메소드 오버로딩과 함께 먼 길을 왔습니다. 거기에 보너스 포인트로 던지고 싶은 중요한 개념이 하나 더 있습니다.

다음 코드 조각은 부모입니다. class SuperHero. 여기에는 지금까지 논의한 모든 오버로드된 메서드가 포함되어 있습니다.

목록 9: 4개의 오버로드된 메서드가 있는 SuperHero 클래스

부모를 상속받을 자식 클래스를 만들어 봅시다. class SuperHero

수행원 class IronMan 의 아이입니다 class SuperHero. 이것은 매우 우아하게 오버로딩하고 있습니다. CustomizeSuit() method 3개의 매개변수로.

목록 10: 1개의 오버로드된 메서드가 있는 IronMan 클래스

응!! 당신은 올바르게 들었습니다. 메소드 오버로딩은 동일한 클래스 내에서 제한되지 않습니다.

부모와 자식 클래스의 인스턴스를 만들었습니다. 다음 이미지 5를 살펴보십시오. 부모 객체로 4개의 오버로드된 메서드가 있습니다.

이미지 5: 오버로드된 메서드 CustomizeSuit의 수를 보여주는 부모 개체

전화를 걸 때 어떤 번호가 나오는지 봅시다. CustomizeSuit() 아이의 물건으로. 이미지 6에서 볼 수 있듯이 하위 클래스 AKA IronMan 목록 10에서 방금 생성한 메서드를 참조하는 추가 개수가 하나 더 있습니다. 따라서 다른 클래스의 메서드를 실제로 오버로드할 수 있음이 입증되었습니다.

이미지 6: 숫자 오버로드된 메서드 CustomizeSuit를 보여주는 자식 개체

자식 클래스에서 부모의 메서드를 오버로드할 수 있지만 여전히 우리가 알아야 할 한 가지가 있습니다.

메모: 위에서 언급한 네 가지 규칙은 동일한 클래스 내에서만 적용됩니다.

여기서 헷갈리지 말자! 예를 들어 설명하겠습니다. 다음 두 이미지 7과 8을 보십시오.

아래 이미지에서, CustomizeSuit() method 에 정의되어 있습니다. class SuperHero 동일한 방법이 다시 정의됩니다. class IronMan 컴파일러에 문제가 없는 것 같습니다.

대상 class SuperHero 의 자체 버전이라고 부를 것입니다. CustomizeSuit() method그리고 대상 class IronMan 추가 카운트 오버로드된 메서드가 있지만 여전히 자체 구현을 호출합니다. CustomizeSuit() method.

즉, 다른 유형에 있는 경우에만 오버로드된 메서드의 동일한 서명을 가질 수 있습니다.

이미지 7: 두 클래스에 동일한 서명을 가진 메서드가 있습니다.

그러나 동일한 유형 내에서 동일한 서명을 가질 수 없습니다.

이미지 8에서 컴파일러가 어떻게 반응하는지 보세요. 동일한 내에서 동일한 서명으로 메서드를 오버로드하면 오류가 발생합니다. class. 따라서 이 네 가지 규칙이 동일한 내에서 적용된다는 것을 기억하십시오. class.

이미지 8: 동일한 서명을 가진 메소드가 동일한 유형에 정의됨

예, 메서드 오버로딩은 모든 가능성을 다루려고 할 때 상당히 압도적일 수 있지만 일단 기본 기본 사항이 명확해지면 객체 지향 프로그래밍에서 메서드 오버로딩의 목적을 이해할 수 있을 것입니다. 이 기사에서 우리는 컴파일 시간 다형성과 관련하여 허용되는 것과 허용되지 않는 것을 이해하기 위해 다양한 예를 사용하여 모든 측면을 심층적으로 다룹니다.

Want to Connect?Hit me up on LinkedIn.