04 컴포넌트 원칙 -1

SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법이라면,

컴포넌트 원칙은 빌딩에 방을 배치하는 방법이다.

 

12장 컴포넌트

모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자다.

자바의 경우 jar 파일, 루비는 gem 파일, 닷넷은 DLL, 컴파일형 언어는 바이너리 파일의 결합체, 인터프리터형은 소스파일의 결합체,

여러 컴포넌트를 서로 링크해 실행가능한 단일파일로 생성 가능하고,

여러 컴포넌트를 서로 묶어 .war 파일처럼 단일 아카이브로 생성도 가능.

컴포너트 각각을 독립적으로도 배포 가능.

컴포넌트의 역사

프로그래밍 초창기에는 프로그램을 메모리의 어느 위치에 로드할지 프로그래머가 직접 결정해야 했다.

라이브러리 함수 소스코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일 했다.

프로그램 위치가 결정되면 재배치가 불가능했고, 대규모 프로그램을 컴파일 하는데 너무 오랜시간이 걸렸다.

결국 애플리케이션과 함수 라이브러리를 분리해서 개별 컴파일 했는데 

함수 라이브러리가 커져서 할당 메모리 주소를 넘게되면 다시 추가 공간을 할당해야 했다.

 

재배치성

해결책은 재배치가 가능한 바이너리 relocatable binary

로더를 사용해 메모리 재배치 가능한 바이너리 생성하도록 컴파일러 수정.

로더는 재배치 코드가 자리할 위치정보를 전달받는다.

로더는 바이너리를 입력받고 순차로 메모리로 로드하면서 재배치 작업을 처리.

이를 통해 필요한 함수만 로드함.

 

애플리케이션을 두개의 주소 세그먼트로 분리

 

컴파일러는 재배치 가능한 바이너리안에 함수이름을 메타데이터 형태로 생성하도록 수정.

프로그램이 라이브러리 함수를 호출하면 컴파일러는 이름을 외부 참조로 생성.

라이브러리 함수 정의 프로그램이면 컴파일러는 해당 이름을 외부 정의로 생성.

외부 정의를 로드할 위치가 정해지면 로더가 외부참조를 외부정의에 링크.(링킹 로더 linking loader)

링커

링킹로더로 인해 프로그램을 개별적으로 컴파일하고 로드할 수 있는 단위로 분할 가능.

1960년대부터 프로그램이 커지며 링킹로더가 느려지면서 로드와 링크가 분리되었다.

80년대에 고수준 언어 사용으로 프로그램이 더 커지며, 로드시간은 빨랐지만 컴파일-링크 구간에서 다시 느려졌다.

80년대 후반에 디스크와 메모리의 성능이 좋아지며, 속도가 빨라졌다.

다수의 .jar 파일, 공유 라이브러리를 빠르게 링크한후 실행가능하게 되었다.

--> 컴포넌트 플러그인 아키텍처 탄생

 

결론

소프트웨어 컴포넌트

- 런타임에 플러그인 형태로 결합할 수 있는 동적 링크파일