접근제어는 실행타임과 디자인타임 두 분류로 나뉩니다. 2장의 접근제어 부분에서 객체의 메모리를 생성한 후의 접근제어하는 실행타임 접근제어만 배웠습니다. 지금이 바로 클래스를 디자인하는 타임의 접근제어를 논할 때인 것 같습니다. 즉, 상속관계에서는 디자인타임의 접근제어가 이용된다는 것입니다. 자! 그렇다면 정확하게 상속에서의 접근제어 문제는 어떤 것인지 알아보도록 하겠습니다.
|
☞ 디자인타임의 접근문제 |
상속 받아서 코딩하고 있는 순간, 상속을 받아서 하나의 새로운 클래스를 제작하고 있는 순간, 하위클래스 입장에서 상위클래스의 접근 문제를 다룬다. |
상위클래스를 아버지라 부르고 하위클래스를 아들이라 부르겠습니다. 아들은 당연히 아버지를 상속하고 있는 상태입니다. 상속을 한다면 아버지의 private 멤버필드와 멤버메서드를 아들이 물려 받습니다. 이 때 아들은 아버지의 private 멤버를 자신의 멤버처럼 마음대로 접근할 수 있을까요? (힌트는 public이라면 완전히 자신의 것과 똑같이 다룰 수 있습니다.)
|
▣ 상속 관계에서 private |
|
q 상위클래스를 상속 받은 하위클래스 내에서 상위클래스의 private 멤버필드에 직접 접근할 수 없다. q 어떠한 경우라도 private이면 public 메서드를 통해서만 접근 가능하다. |
이 질문에 대한 해답은 한번 private은 영원한 private이라는 것입니다. 즉 No라는 뜻입니다. 아들이 아버지로부터 상속을 받았다면 아버지 것도 내 것, 내 것도 내 것이라는 명제가 통용됩니다. 하지만 아버지의 마지막 남은 자존심(自尊心)인 private 멤버만큼은 직접접근을 불허(不許)합니다.
|
& |
Son.cs |
Ü 상속의 접근제어를 테스트하기 위한 예제 |
|
using System; public class MyFather { public String name; private String nickname; public MyFather(){ name ="위대한 아버지"; nickname="뺑코"; } public String GetNickName(){ return nickname; } } public class Son: MyFather { public void SayFatherNames() { Console.WriteLine(name); Console.WriteLine(nickname);//상위클래스의 private에 직접접근 불허 } public static void Main() { Son s = new Son(); s.SayFatherNames(); } } | ||
|
C:\C#Example\04>csc Son.cs Son.cs(16,21): error CS0122: 보호 수준 때문에 'MyFather.nickname'에 액세스할 수 없습니다. | ||
이 예제는 에러가 발생합니다. 아버지의 private 멤버필드를 마음대로 사용하려다 컴파일도 하지 못하고 있습니다. 아버지의 nickname 멤버필드는 private인데 이를 아들이 마음대로 접근하는 것은 오류입니다. 컴파일 에러입니다. 하지만 name이라는 pubic 멤버필드는 마음대로 접근하고 있습니다. 아들의 클래스를 디자인할 때, 마치 자신의 멤버필드처럼 이용하고 있습니다. 현재 설명하고 있는 것은 상속의 관계에서 나타나는 디자인타임의 접근제어입니다. 한번 private은 영원한 private입니다. private의 접근제어는 static접근, 상속관계, 실행타임의 접근제어 모든 곳에 그 규칙을 지킵니다. 즉, private은 예외가 존재하지 않습니다.
그렇다면 아버지의 private에 어떻게 접근할 수 있을까요? 너무나도 맹한 질문입니다. private 멤버필드는 public 메서드를 통해서 접근할 수 있습니다. 더 이상 이것은 논하지 않아도 뻔한 이야기입니다. 자! 그렇다면 이런 질문을 다시 던져보죠. 상속관계에서 public 메서드를 사용하지 않고 아버지의 멤버필드는 실행 타임에는 private이면서 아들에게는 완전한 public이고자 합니다. 이것이 부모의 마음 아니겠습니까? 이러한 방법이 C#에 존재할까요?
|
▣ 상속 관계에서 protected |
|
q 아버지의 protected 멤버필드는 실행 타임에는 private이면서 아들에게는 완전한 public된다. |
답은 Yes입니다. 위의 질문은 객체의 메모리를 생성한 후 점(.)찍고 접근할 때는 완벽한 private이면서 상속관계의 클래스 디자인타임에는 완벽한 public이고자 한다는 것입니다. 이런 방법론을 제공하기 위해서 아직 설명하지 않은 protected 접근지정자가 존재합니다.
위의 예제에서 private을 protected로 고친다면 이 예제는 아주 멋지게 동작 할 것입니다. 여기서 기억해야 하는 것은 protected 접근지정자는 상속의 관계에서 나옵니다. protected는 private과 똑같이, 외부에서는 접근 불가능합니다. 그리고 private은 상속을 했을 때 하위클래스에서도 직접접근 불가능해집니다. 혹자는 다음과 같은 의문을 가질 수도 있을 것입니다. 상속을 받았다면 상위클래스의 모든 멤버는 하위클래스의 멤버가 되는 것이 아닌가? 라는 의문을 제기할 것입니다.
그림 4-5 상속관계에서의 접근 제한자 protected
상속을 받았다면 당연히 상위클래스의 멤버는 하위클래스의 멤버처럼 사용할 수 있습니다. 하지만 private 속성은 직접접근이 불가능합니다. 즉, 한번 private은 영원한 private이라는 말까지 할 수 있습니다. 그래서 상속을 했을 때 하위클래스에서 자신의 멤버처럼 사용하기 위해서, 또 다른 방법을 제시하고 있습니다. 모든 면에서 private을 수행하면서 상속의 관계에서만 public의 행위를 하는 것이 바로 protected입니다. 이것을 다르게 표현한다면 아버지의 모든 것은 상속을 받아 직접 사용할 수 있지만, 아버지의 private만은 직접 접근할 수 없습니다. 하지만 아버지의 protected는 아들의 멤버처럼 사용할 수 있습니다. 이렇게 하면 아버지의 모든 것이 아들의 것이 된다고 해도 과언이 아닙니다. 즉 아버지 것도 내 것, 내 것도 내 것이라는 말을 사용할 수 있게 되는 것입니다.
멤버필드만을 이야기했는데 멤버메서드는 어떻게 되느냐고 묻는다면 똑같다고 이야기 할 수 밖에 없습니다. 메서드나 변수나 똑같은 놈들이니까요. 객체지향에서도 부모 자식관계의 인륜이 완전하게 지켜지고 있는 것이 신기하지 않습니까?
| jabook저자명함 |
|
제목:소설같은C# 제4강의 저자:최영관 |
