6-1.클래스 선언
6-1-1.클래스
객체지향 프로그래밍 환경에서 핵심 주인공은 클래스이다. 함수, 변수, 상수 등 모든 것이 클래스에 소속되며 어떤 것도 전역으로 존재할 수 없다. 닷넷의 라이브러리는 클래스의 집합이고 string, int 타입조차 클래스로 표현된다. 따라서 클래스를 제대로 모르고는 프로그래밍을 할 수 없다.
클래스는 관련있는 변수와 함수의 집합이며 실세계의 사물을 표현한다. 변수는 상태를 표현하고 함수는 동작을 기술한다. 상태와 동작을 하나의 타입으로 묶어 선언한 것이 클래스이다. 클래스에 속한 변수를 필드(Field), 함수를 메서드(Method)라고 부른다. 실세계의 사물을 관찰해 보면 고유한 상태와 동작을 가진다.
|
사물 |
상태 |
행동 |
|
사람 |
피부색, 키, 나이, 성별, 이름 |
생각한다, 공부한다, 말한다, 걷는다. |
|
차 |
배기량, 차종, 연료의 종류 |
달린다, 멈춘다, 고장난다, 짐을 싣는다. |
|
노트북 |
CPU, 액정 크기, 하드디스크 용량 |
부팅한다, 충전한다, CD-ROM을 읽는다. |
|
윈도우 |
크기, 위치, 배경색, 아이콘 |
이동한다, 최대화된다, 숨는다. |
사물의 특성을 정리하여 필드와 메서드로 표현하는 과정이 추상화이다. 추상화된 결과를 하나의 클래스에 포함시키고 보호할 것을 숨겨 스스로 방어하는 것이 캡슐화이다. 추상화와 캡슐화에 의해 실세계의 사물은 클래스라는 타입으로 표현된다. 또한 클래스는 상속을 통해 계층을 구성하며 다형성이라는 고차원의 특성을 발휘한다.
C#에서 클래스를 선언하는 기본 형식은 C++과 유사하되 몇 가지 다른 점이 있다. 선언문 뒤에 세미콜론을 붙이지 않으며 선언 순서는 중요하지 않다. 메서드의 본체를 클래스 선언문 내에 작성하며 그래서 클래스 선언문이 길다.
지정자 class 이름 : 기반클래스 {
// 멤버 목록
}
키워드 class 다음에 이름을 쓰고 { } 블록 안에 멤버 목록을 작성한다. 이름은 사물을 상징하는 짧은 이름이 좋다. 지정자는 클래스의 속성을 결정하는데 필요 없으면 생략한다. 콜론 뒤의 기반 클래스는 상속받고 싶은 부모 클래스이되 역시 생략 가능하다.
멤버는 주로 필드와 메서드이지만 이 외에 상수, 이벤트, 프로퍼티, 인덱서, 연산자, 생성자, 내부 타입 등 더 복잡한 것도 포함된다. 클래스에 포함되는 것을 통틀어 멤버라고 부른다. 각 멤버에 대해 다음 절부터 순서대로 개별 면담을 할 것이다.
다음 예제의 Human 클래스는 사람을 표현한다. 사람은 이름과 나이 속성을 가지며 자신을 소개하는 행동을 한다. 물론 사람은 복잡한 존재여서 이보다 훨씬 더 많은 속성과 행동을 가지지만 편의상 간단히 추상화했다.
|
Human |
실행결과 |
|
using System;
class CSTest { static void Main() { Human Kim; Kim = new Human(); Kim.Name = "김상형"; Kim.Age = 25; Kim.Intro(); } }
class Human { public string Name; public int Age; public void Intro() { Console.WriteLine($"{Age}살 {Name}입니다."); } } |
25살 김상형입니다. |
class Human 블록 안에 멤버를 선언한다. 이름을 표현하는 Name은 문자열로, 나이를 표현하는 Age는 정수로 선언했다. Intro 메서드는 콘솔에 이름과 나이를 출력하여 자신을 소개하는 동작을 표현한다. 사람이라는 실세계의 사물을 표현하는 클래스를 정의했다.
클래스는 사물을 표현하는 틀일 뿐이지 그 자체가 사물은 아니다. 클래스 타입의 객체를 생성해야 비로소 실제 사물이 된다. Main에서 Human 타입의 Kim 객체를 선언한 후 new 연산자로 생성한다. 참조 타입인 클래스는 선언 후 new 연산자로 힙에 객체를 생성하며 new는 객체의 참조자를 리턴한다. 예제에서는 Kim 객체로 참조자를 받았다.
클래스에 소속된 필드는 특별히 초기화하지 않으면 기본값을 가진다. 예제에서는 Kim 객체 생성후 Name, Age에 적당한 값을 대입하여 초기화하고 Intro 메서드를 호출하여 상태를 출력했다.
객체를 만드는 형틀인 클래스를 선언해 두면 이후 얼마든지 많은 객체를 만들 수 있다. Human Lee, Human Park 식으로 객체를 선언하고 new 연산자로 생성하면 된다. Kim, Lee, Park 등은 같은 클래스로부터 만들어진 다른 객체이며 고유의 이름과 나이를 가진다.
6-1-2.분할 선언
헤더 파일과 구현 파일이 분리되어 있는 C++에 비해 C#은 하나의 소스에 선언과 정의를 모두 작성할 수 있어 간편하다. 반면 클래스 선언문이 너무 길어지는 단점이 있다. 그래서 클래스를 여러 조각으로 분할하여 선언하는 기능을 제공한다. 분할 선언은 덩치가 큰 타입을 여러 소스 파일에 찢어 놓는 방법이다.
열거형과 델리게이트는 짧아 분할 선언을 지원하지 않으며 주로 클래스에 대해 사용한다. 클래스 선언문 앞에 partial 지정자를 붙이면 같은 이름의 클래스 조각을 하나로 합쳐준다. 주로 두 개의 소스 파일에 나누어 선언하는 것이 일반적이지만 이론상으로는 백조각으로 갈기 갈기 찢어 놓을 수도 있다. 앞에서 만들었던 Human 클래스는 아주 작아 굳이 그럴 필요 없지만 연습 삼아 분할 선언해 보자.
|
Partial |
|
using System;
class CSTest { static void Main() { Human Kim; Kim = new Human(); Kim.Name = "김상형"; Kim.Age = 25; Kim.Intro(); } }
partial class Human { public int Age; public string Name; }
partial class Human { public void Intro() { Console.WriteLine($"{Age}살 {Name}입니다."); } } |
Human 클래스를 두 번 선언하되 한 조각에는 필드만 선언하고 한 조각에는 메서드만 선언했다. 선언문이 둘로 나누어져 있을 뿐이지 합치면 결국 같은 선언문이다. 각 조각의 선언문 앞에는 partial 지정자가 있어 다른 조각이 있음을 표시하며 컴파일러는 이름이 같은 조각을 하나로 합친다.
편의상 한 파일에 두 개의 조각을 나누었는데 다른 파일에 있어도 상관없다. 같은 파일에서 일부러 나누어 선언할 필요는 없으니 분할 선언은 한 클래스를 여러 파일에 나누어 선언하는 기능이라 할 수 있다. 지정자만 붙이면 되니 문법도 간단하다. 분할 선언은 효율적인 자동화를 위해 필요하다. GUI 프로젝트는 컨트롤 배치나 속성 조정을 그래픽 환경에서 마우스로 수행하며 데이터베이스 프로젝트는 마법사를 많이 쓴다. 툴에 의해 자동으로 생성되는 코드가 많으며 코드는 결국 선언문에 포함된다.
자동 생성된 코드와 사용자가 작성한 코드가 섞여 있으면 보기 싫을 뿐만 아니라 상호 간섭으로 엉망이 될 확률이 높다. MFC나 웹 편집기 등이 좋은 예인데 여러 모로 불편하다. 그래서 C#은 언어 차원에서 자동 생성 코드와 사용자의 코드를 물리적으로 분리하는 문법을 도입하였다. 윈폼 프로젝트의 폼 클래스는 Form1.cs와 Form1.Designer.cs로 분할되어 있어 사용자의 코드와 폼 디자이너의 코드가 완벽하게 격리된다. 그래서 폼 디자이너와 개발자가 서로 간섭없이 자신의 코드만 잘 관리하면 된다.
분할 선언은 병합을 전제로 한 것이어서 주의 사항이 많다. 각 조각의 속성이 다르면 무사히 병합할 수 없으니 불일치를 해소하기 위한 규칙이다.
l 각 조각은 같은 네임스페이스 소속이어야 한다.
l 각 조각의 액세스 지정자는 일치해야 한다.
l 한쪽 조각에서 선언한 멤버를 다른 조각에서 중복 선언할 수 없다.
l 템플릿 클래스는 템플릿 인수나 제약이 일치해야 한다.
l 각 조각의 기반 클래스는 같아야 한다. 한쪽에만 기반 클래스를 지정하고 다른 쪽에서는 생략하는 것은 가능하다.
l 각 조각이 상속받는 인터페이스는 모두 병합되어 다중 상속된다. 인터페이스의 메서드는 임의의 조각에서 구현한다.
l abstract나 sealed 지정은 어느 조각에서든 한 번만 하면 된다.
l 어느 조각의 멤버가 먼저 선언될지 알 수 없다.
l 클래스에 속한 내부 타입도 분할 선언할 수 있다.
l 컴파일할 때 병합되므로 모든 조각은 같이 컴파일해 한다. 이미 컴파일된 클래스를 확장할 수는 없다.
l partial을 지정해도 꼭 조각을 나누지 않아도 된다. 분할했다 합쳤을 때 partial을 그냥 둬도 별 부작용은 없다.
l 각 조각에 지정된 어트리뷰트는 병합된다. 그러나 순서는 알 수 없다.
l 각 조각이 참조하는 using문이 다르면 참조하는 명칭이 달라질 수 있다.
수만 많을 뿐 사실 당연한 규칙이다. 고의적으로 엽기적인 선언문만 만들지 않으면 큰 문제없이 잘 병합된다. 사실 이 기능은 개발툴의 효율적인 동작과 소스 관리의 편의을 위한 것이지 사용자가 직접 쓸만한 기능은 아니어서 너무 상세히 알 필요는 없다.
분할 선언 기능은 C# 2.0에서 추가된 것이어서 partial은 키워드가 아니다. class, struct, interface 앞에 있을 때만 키워드이며 그 외의 위치에서는 일반 명칭이다. 기능이 추가되면 키워드가 늘어나는 것은 당연하지만 이전 버전의 프로젝트에서 이미 명칭으로 사용하는 경우를 위해 키워드로 인정하지 않는다. 최신 버전에서 추가된 when, yield, async 등도 마찬가지로 키워드가 아니다.
6-1-3.지정자
멤버 앞에 성질을 결정하는 여러 가지 지정자(Modifier)를 붙인다. 먼저 액세스 지정자에 대해 알아보자. 액세스 지정자는 누가 이 멤버를 읽고 쓸 수 있는지 권한을 지정하며 외부에서 함부로 값을 변경하지 못하도록 한다.
|
액세스 지정자 |
설명 |
|
private |
클래스 내부에서만 액세스할 수 있다. |
|
protected |
클래스 내부 또는 파생된 클래스에서만 액세스할 수 있다. |
|
public |
외부에서 마음대로 액세스할 수 있다. |
|
internal |
같은 어셈블리내에서만 액세스할 수 있다. |
|
protected internal |
같은 어셈블리내에서만 또는 파생 클래스에서 액세스할 수 있다. |
|
private protected |
같은 어셈블리에내의 파생 클래스에서 액세스할 수 있다. |
private, protected, public은 C++이나 자바의 경우와 같다. 나머지 액세스 지정자는 어셈블리의 경계밖에서도 액세스 가능한지를 제한한다. 액세스 지정자는 각 멤버에 개별적으로 붙이며 생략시 디폴트는 private가 적용된다. 클래스도 액세스 지정자를 붙인다. public은 어디서나 참조할 수 있고 internal은 같은 어셈블리 내에서만 참조할 수 있다. 디폴트는 internal이며 디폴트가 무난해 보통 생략한다. 중첩된 내부 클래스는 모든 액세스 지정자를 다 쓸 수 있다.
액세스 지정자를 통해 주요 멤버를 숨겨 안정성을 확보하며 숨겨진 부분을 자유롭게 업그레이드할 수 있다. 객체지향의 이런 특성을 정보 은폐(Information Hiding)라고 하며 객체의 내부 동작과 외부 인터페이스를 분리한다. 사용자는 숨겨진 내부 동작까지 알 필요 없이 공개 인터페이스만 배워 객체를 쉽게 활용할 수 있다. 액세스 지정자 외에도 여러 가지 지정자가 있다. 간략하게 정리해 해 두고 이후 하나씩 상세히 알아보기로 한다. 적용 대상에서 필드는 이벤트 같은 변수 타입의 멤버를 포함하며 메서드는 인덱서, 프로퍼티, 연산자 등의 함수형 멤버를 포함한다.
|
지정자 |
대상 |
설명 |
|
static |
필드, 메서드, 클래스 |
클래스에 소속되는 정적 멤버 |
|
readonly |
필드 |
초기화 가능한 읽기 전용 멤버 |
|
const |
상수 |
읽기 전용 멤버 |
|
virtual |
메서드 |
가상 메서드 |
|
override |
메서드 |
재정의된 메서드 |
|
new |
메서드, 필드 |
부모의 메서드를 숨기는 새 메서드 |
|
abstract |
클래스, 메서드 |
실제 구현을 가지지 않는 추상 클래스 |
|
sealed |
클래스, 메서드 |
기반 클래스로 사용할 수 없는 봉인 클래스 |
|
volatile |
필드 |
최적화를 하지 않는 필드 |
|
extern |
메서드 |
외부에 정의된 메서드 |
여러 개의 지정자를 붙일 때 순서는 아무래도 상관없다. public static은 공개된 정적 멤버라는 뜻이고 static public은 정적인 공개 멤버라는 뜻인데 결국 같은 의미이다. 그러나 다음처럼 지정자를 쓰는 것은 안된다.
int static public Age; // 타입은 변수명 앞에 와야 함
private public int Age; // 같이 쓸 수 없는 지정자
타입은 지정자가 아니어서 명칭 바로 앞에 있어야 한다. 또 private와 public 처럼 상호 배치되는 지정자를 동시에 사용해서는 안된다.
6-1-4.생성자
앞 항의 Human 클래스는 몇 가지 문제가 있다. 우선 Name, Age 같은 주요 필드가 공개되어 있어 안전하지 못하다. 항상 유효한 값을 가지려면 외부에서 함부로 변경하지 못하도록 숨겨야 한다. 또 객체를 만드는 쪽에서 필드를 일일이 초기화해야 하는 불편함이 있다. 어차피 객체가 유효해지려면 초기화가 필요한데 이 작업을 Main이 직접 하는 것은 불합리하다.
필드가 수십개라면 유효한 객체를 만드는데 엄청난 코드가 필요해진다. 이 두 문제를 동시에 해결하는 장치가 생성자이다. 생성자는 객체 생성시에 자동으로 호출되어 객체를 초기화하는 특별한 메서드이다. 중요 필드는 숨겨 놓고 생성자를 통해 객체를 유효한 상태로 초기화하여 곧바로 사용할 수 있게 만든다.
|
Constructor |
|
using System;
class CSTest { static void Main() { Human Kim; Kim = new Human("김상형", 25); Kim.Intro(); } }
class Human { private string Name; private int Age; public Human(string aName, int aAge) { Name = aName; Age = aAge; } public void Intro() { Console.WriteLine($"{Age}살 {Name}입니다."); } } |
Name, Age 필드에 private 액세스 지정자를 붙여 숨겼다. 이제 Main에서 Kim.Age = 256; 처럼 잘못된 값을 함부로 대입할 수 없다. 캡슐화의 원칙상 필드는 가급적이면 숨기는 것이 좋다. 하지만 외부에서 호출하는 Intro 메서드는 여전히 public이다.
Human 메서드가 추가되었는데 이것이 생성자이다. 생성자는 aName, aAge 인수를 전달받아 Name과 Age 필드에 대입하여 초기화한다. 생성자의 인수앞에 붙이는 a 접두는 Argument의 약자로서 필드와 인수를 구분하는 역할을 한다. 또는 필드와 같은 이름의 인수를 받되 필드 앞에 this.을 붙여 구분하기도 한다.
public Human(string Name, int Age) {
this.Name = Name;
this.Age = Age;
}
생성자는 컴파일러가 자동으로 호출하며 명시적으로 호출할 수 없다. 컴파일러가 생성자를 찾을 수 있도록 클래스와 같은 이름을 붙이며 사용자가 호출하는 것이 아니어서 리턴은 할 수 없다. 그래서 Human 클래스의 생성자 이름은 Human이고 리턴 타입은 적지 않는다. new 연산자로 Human 객체를 생성할 때 초기화에 사용할 인수를 전달한다. new Human("김상형", 25); 생성문에 의해 생성자가 호출되며 실인수를 받아 Name과 Age 필드에 대입한다. 생성자가 초기화를 담당하므로 Main은 더 이상 신경쓰지 않아도 된다.
생성자는 필드 초기화 외에 객체 동작에 필요한 모든 처리를 다 할 수 있다. 사운드 카드를 초기화한다거나 DB에 연결한다거나 특정 라이브러리를 로드하는 등 객체 동작에 필요한 환경을 구성하는 일체의 책임을 진다. 생성자를 정의하지 않으면 컴파일러는 디폴트 생성자를 만든다. 디폴트 생성자는 모든 멤버를 0, false, null 등으로 초기화하여 쓰레기값을 치운다. 그래서 생성자가 없어도 객체를 만들 수 있다. 생성자가 하나라도 정의되어 있다면 디폴트 생성자는 만들지 않으며 이 경우 생성자가 요구하는 인수를 전달해야 한다.
객체를 초기화하는 방법이 여러 가지이면 인수 목록이 다른 생성자를 여러 벌 정의한다. new 다음의 인수열로 호출할 생성자를 선택한다. 이때 코드의 중복을 방지하기 위해 생성자끼리 서로 호출할 수 있는데 본체 코드 이전에 : this(인수) 식으로 다른 생성자를 호출한다.
|
CallConstructor |
실행결과 |
|
using System;
class CSTest { static void Main() { Human Kim = new Human("김상형", 25); Kim.Intro(); Human Lee = new Human("이순신"); Lee.Intro(); } }
class Human { private string Name; private int Age; public Human(string aName, int aAge) : this(aName) { Age = aAge; } public Human(string aName) { Name = aName; Age = 1; } public void Intro() { Console.WriteLine($"{Age}살 {Name}입니다."); } } |
25살 김상형입니다. 1살 이순신입니다. |
이 예제의 Human 클래스는 인수 목록이 다른 두 개의 생성자를 제공한다. Human(string, int) 생성자는 이름과 나이를 모두 받으며 Human(string) 생성자는 이름만 인수로 받고 나이는 상수 1로 초기화한다. 이름을 초기화하는 코드는 Human(string)에 이미 작성되어 있으니 Human(string, int)에서 : this(aName)문으로 이 생성자를 호출하여 이름을 초기화했다.
이 예에서는 : this(aName)보다 Name = aName문이 더 간단하다. 하지만 반복되는 코드는 제거하는 것이 원칙이며 양쪽에 똑같은 코드를 두는 것보다 한쪽에만 두고 호출하는 것이 유지, 보수에 유리하다. 생성자를 명시적으로 호출할 수 없지만 생성자끼리는 호출할 수 있다.
필드의 초기값이 상수라면 클래스 선언문 내에서 필드 선언문 다음에 = 과 원하는 초기값을 지정한다. 지역변수의 초기값을 지정하는 방식과 같다. 다음 선언문은 Name과 Age필드에 적당한 디폴트 초기값을 지정한다. 필드 초기식(Field Initializer)은 생성자보다 먼저 실행된다. 일단 이 값으로 초기화하되 생성자가 다른 값으로 바꿀 수 있다. 무난한 값으로 초기화해 놓으면 생성자에서 일일이 신경쓸 필요 없이 꼭 필요한 멤버만 초기화할 수 있어 편리하다.
class Human {
private string Name = "이름모름";
private int Age = 22;
사용하는 입장에서는 별거 아닌 거 같지만 컴파일러 구현상 골치 아픈 기능이다. 왜냐하면 클래스는 틀일 뿐 실체가 아니기 때문이다. C++은 이 기능을 지원하지 않다가 최근에서야 정수형만 명시적 초기화를 허락한다. 그만큼 구현이 까다로운 기능이다.
6-1-5.파괴자
파괴자는 생성자의 반대 메서드이며 객체가 사라질 때 정리 작업을 수행한다. 초기화 과정에서 어떤 자원을 할당했다거나 환경을 바꾸어 놓았다면 다 사용한 후에 원래대로 돌려 놓을 책임도 있다. 파괴자의 이름은 클래스 이름앞에 ~ 기호를 붙이며 내부적으로 Finalize 메서드로 정의된다.
C#은 가비지 커렉터가 자원을 자동으로 회수하도록 되어 있어 파괴자를 쓸 일이 드물다. 파일이나 네트웍처럼 가비지 컬렉터의 관리 대상이 아닌 자원에 대해서만 가끔 사용한다. 다음 예제는 소켓 통신을 하는 클래스의 모형이다.
|
Destructor |
실행결과 |
|
using System;
class Socket { private int SocketPort; public Socket(int port) { SocketPort = port; Console.WriteLine("{0} 포트로 소켓을 연결한다.", port); } ~Socket() { SocketPort = 0; Console.WriteLine("소켓 연결을 해제한다."); } }
class CSTest { static void Main() { Socket S = new Socket(1234); Console.WriteLine("주거니 받거니 통신했다 치고..."); } } |
1234 포트로 소켓을 연결한다. 주거니 받거니 통신했다 치고... 소켓 연결을 해제한다. |
통신을 하려면 네트웍에 연결해야 하는데 연결 초기화는 생성자가 하며 소켓을 만드는 즉시 통신 가능하다. 소켓 파괴시 연결을 끊어야 하는데 네트웍 연결은 메모리가 아니어서 가비지 컬렉터의 권한 밖이다. 비관리 자원은 최초 할당한 클래스가 직접 해야 하는데 그 시점이 객체가 파괴될 때 호출되는 파괴자이다.
객체를 회수하는 가비지 컬렉터의 동작 시점은 예측할 수 없으며 따라서 파괴자가 호출되는 정확한 시점도 알 수 없다. 언젠가는 해제되겠지만 바로 재사용해야 하는 자원이라면 무작정 기다릴 수 없다. 곧바로 해제하고 싶다면 가비지 컬렉터에게 명시적으로 자원 해제를 요구하거나 아니면 IDisposable 인터페이스를 구현해야 한다. 가비지 컬렉터와 함께 다음에 자세히 알아보기로 하자.