5장 객체 지향 프로그래밍

5장 객체 지향 프로그래밍

태그

비어 있음

날짜

2024년 4월 23일

객체지향 프로그래밍이란 무엇일까? 어떤 이들은 캡슐화, 상속, 다형성으로 oo의 본질을 설명한다. 이 세 가지 개념을 차례대로 살펴보자

캡슐화

c에서는 point.h(데이터 구조, 함수)를 사용할 때 struct Point(구현 파일에 있음) 멤버에 접근할 방법이 전혀 없다.

즉 완벽한 캡슐화가 가능했다.

c++에서는 완벽한 캡슐화가 깨졌다. 멤버 변수를 헤더 파일에(.h) 선언하게 되었다.

자바와 c#은 헤더와 구현체를 분리하는 방식을 모두 버렸고 캡슐화는 더 훼손되었다.

많은 oo언어가 캡슐화를 강제하지 않는다.

⇒ 즉 oo를 제공한다고 주창한 언어들이 완벽한 캡슐화를 약화시켜왔다.

상속

oo언어가 고안되기 이전에도 비슷한 기법이 사용되고 있었다.

상속만큼 편리한 방식은 아니고 다중 상속을 구현하기란 훨씬 어렵다.

NamedPoint를 Point 타입으로 강제로 변환 → 업캐스팅

진짜 oo언어에서는 업캐스팅이 암묵적으로 이뤄진다.

C

복사

struct NamedPoint* origin = makeNamedPoint(0.0, 0.0, "origin"); (struct Point*) origin, (struct Point*) upperRight

​

oo언어가 완전히 새로운 개념을 만든 것은 아니지만 상당히 편리한 방식을 제공했다고 볼 수 있다.

캡슐화에 대해서는 oo에게 점수를 줄 수 없고, 상속에 대해서만 0.5점 부여할 수 있다.

다형성

oo의 근간이 되는 단순한 기법

C

복사

getChar()는 STDIN에서 문자를 읽는다. int getChar(){ return STDIN->read(); //함수호출 } struct FILE{//파일 데이터 구조 ... int (*read)(); ... } #include "file.h" int read(){int c; return c;} //FILE 데이터 구조의 read 포인터를 가리킴 //열기, 닫기, 읽기 쓰기, 탐색 함수가 있음

​

함수를 가리키는 포인터를 응용한 것이 다형성( oo가 새롭게 만든 것은 전혀없다.)

프로그래머가 포인터를 통해 함수를 호출시키는 관례를 기억하고수동으로 따라야 함

⇒ oo언어는 이러한 관례를 없애주며 다형성을 더 안전하고 편리하게 사용하게 한다.

⇒ oo는 제어흐름을 간접적으로 전환하는 규칙을 부과한다고 결론지을 수 있다.

다형성이 가진 힘

복사 프로그램에 새로운 입출력 장치가 생길 때 복사 프로그램을 수정할 필요가 없다.

입출력 드라이버가 FILE에 정의된 표준함수를 구현하면 복사프로그램에서 이 입출력 드라이버를 사용한다.

즉 입출력 프로그램이 복사 프로그램에 플러그인 된 것.

이러한 플러그인 아키텍처는 모든 운영체제에서 구현되었다. oo의 등장으로 플러그인 아키텍처를 적용할 수 있게 되었다.

의존성 역전

이전에는 고수준이 저수준을 호출하는 제어흐름을 가졌고, 소스 코드의 의존성의 방향도 이를 따르게 되었다.

다형성의 등장으로

인터페이스의 사용으로 소스 코드 의존성이 제어흐름과 반대가 되었다. (그림5.2)

→ 의존성 역전

oo언어로 개발된 시스템을 다루는 소프트웨어 아키텍트는 의존성을 제어할 수 있게 되었다.

의존성을 역전 시킴으로써, 각 컴포넌트를 개별적이며 독립적으로 배포 가능 하도록 만들며 각 모듈은 서로 다른 팀에서 독립적으로 개발할 수 있게 만든다.

결론

oo란 다형성을 이용해 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득하는 능력

고수준의 정책을 포함하는 모듈은 저수준의 세부사항을 포함하는 모듈에 대해 독립성을 보장

저수준의 세부사항은 중요도가 낮은 플러그인 모듈로 만들 수 있고, 고수준의 모듈과는 독립적으로 개발 및 배포할 수 있다

표