chap.8 인터페이스

2011. 2. 11. 00:38 from PROGRAMMING/C#.NET

chap.8 인터페이스

1. 인터페이스

 1.1 인터페이스

 1.2 인터페이스 선언

 1.3 인터페이스의 상속

2. 인터페이스 활용

 2.1 열거하기

 2.2 반복기

 2.3 깊은 복사

3. 메모리 관리

 3.1 가비지 컬렉터의 동작

 3.2 IDisposable

 

1. 개념

: 메서드의 목록만을 가지는 특별한 타입(추상클래스와 유사)

 

추상클래스 내에 추상클래스만 넣어놓은것 → 인터페이스

 

2. 특징(인터페이스와 추상클래스의 차이점)

-인터페이스에 선언된 메서드의 구현 강제. 인터페이스로부터 상속을 받는 클래스들은 인터페이스에 포함된 모든 메서드를 구현해야 함.

-모든 메서드를 구현해야 하므로 인터페이스에 소속된 데이터 원형들은 갯수가 많지 않다.

-반복되는 공정(제조업체)에서 주로 사용.(ex.처리의 방법은 다를 수 있으나 공정의 순서는 같을 때. 동일한 공정 순서 → 인터페이스 선언으로 통일, 달라지는 처리방법 → '구현부'만 다르게)

 

인터페이스에서 프로토타입만 존재하는 함수를 만드는 이유

: 프로그래밍에 일관성, 규칙성, 안정성 부여

 

3. 인터페이스 선언

키워드 interface로 선언. 대문자I로 시작하는 것이 관례(클래스와 구분 위해. 따라서 되도록 I로 시작하는 클래스 이름은 사용하지 않는다)

함수의 원형만 선언. 실제 구현은 파생클래스에서 상속받아 구현.

 

4. 인터페이스의 상속

■ 상속 : 구현 상속, 인터페이스 상속

구현 상속: 클래스들끼리 상속. 자식은 부모의 코드를 물려받아 그대로 사용하거나 재정의라는 방법을 통해 어느정도 수정 가능.

단점: 자식이 부모에게 종속됨(부모의 동작이 바뀌면 이 동작을 자식들도 영향을 받는다. 즉, 부모 클래스에 버그가 있으면 모든 자식들에게 파생된다.

 

인터페이스 상속

-구현 코드는 물려받지 않고 구현해야 할 메서드의 목록만 상속 받음. 메서드를 어떻게 구현하는가는 자식 클래스에서 결정.

-인터페이스 간 상속 가능: 메서드의 목록을 좀 더 세분화하여 재사용성을 높임.

-다중 상속 지원

: C#은 다중 상속을 지원하지 않는다. 즉, 한개의 클래스가 여러개의 클래스를 동시에 상속 받을 수 없다. 하지만 꼭 필요한 경우를 위해 인터페이스 다중 상속을 지원한다.(but, 지나치게 복잡하므로 잘 사용하지 않는게 좋음)

 

5. 메모리 관리(p.308)

개발자들에게 있어 좋은 프로그램이란? 메모리를 효율적으로 사용하는, cpu를 덜 바쁘게 하는 프로그램

-메모리(주소값을 갖는 공간)를 효율적으로 사용하는 프로그램? 1. 메모리를 적게 사용, 순차적으로 사용(cf.배열-순차적으로 데이터가 들어감) 2.지역변수 선언을 자제

-cpu를 덜 바쁘게 하는 프로그램? 1. 함수의 실행시간을 줄여주어야 함 2. 실행 단계(절차)를 줄여주어야 함

메모리의 경우,

함수가 리턴할때, 지역변수가 사라지면서 메모리에 빈 공간이 생김

공간이 부족해지면 가상디스크(하드디스크)를 쓰기 시작함(빈 공간을 채우지 않고)

이러한 메모리의 특성을 고려하여 메모리를 관리하기 위한 것이 가비지 컬렉터.

 

1) 가비지 컬렉터의 동작

-쓰레기 수집: 백그라운드에서 항상 실행 중이며 더이상 사용하지 않는 메모리(쓰레기)를 찾아 회수.

-힙 관리: 단편화 현상이 일어날 때 컴팩션(Compaction) 수행(메모리 압축, 하드 디스크의 조각 모음과 같은 개념)

*단편화: 할당이 요청되었을 때 힙에 객체가 만들어지고 회수 되기를 몇 번 반복하여 힙의 중간이 비게 되는 현상

*컴팩션(Compaction): 남아있는 메모리를 이동시켜 큰 덩어리를 만드는 것

 

2) IDisposable

파괴자: 객체가 사라질 때 비관리 자원을 직접 해제하는 것

자원을 직접해제해야 할 필요성: 가비지 컬렉터가 관리할 수 없는 비관리 자원, 가급적 빨리 해제할 필요가 있는 비싼 관리 자원

방법: IDisposable 인터페이스를 상속받아 Dispose라는 이름으로 만든다.

가비지 컬렉터가 동작할 때를 기다리는 것이 아니라 수동으로 직접 해제하므로 불확실성이 사라짐

'PROGRAMMING > C#.NET' 카테고리의 다른 글

chap.10 닷넷 클래스  (0) 2011.02.22
chap.9 델리게이트  (0) 2011.02.21
chap.7 클래스 상속 3. 추상 클래스  (0) 2011.02.11
chap.7 클래스 상속 2. 재정의  (0) 2011.02.11
chap.7 클래스 상속 1. 상속  (0) 2011.02.11
Posted by 마마필로 :