컴포넌트란?
- 배포단위이며 컴포넌트는 시스템의 구성요소로 배포할 수 있는 가장 작은 단위이다.
- Java에서는 jar파일이 컴포넌트이며 루비에서는 gem파일이다.
- 여러 컴포넌트를 서루 링크하여 실행 가능한 단일 파일로 생성할 수 있으며 여러 컴포넌트를 모아 war파일과 같은 모을 수 있으며 jar 단독으로 사용도 가능하다.
- 잘 설계된 컴포넌트라면 독립적으로 개발 가능한 능력을 갖춰야 한다.
소프트웨어 개발의 초창기에는 메모리에서 프로그램 위치와 레이아웃을 프로그래머가 직접 제어 했다. 따라서 주소의 위치가 나왔어야 한다.
이때에는 메모리가 비쌌기 때문에 함수 라이브러리의 소스 코드를 어플리케이션 코드로부터 분리했으며 함수 라이브러리를 개별적으로 컴파일 했다.
그 컴파일된 바이너리를 메모리의 특정 위치에 로드 하였다.
하지만 점차적으로 라이브라리가 커지면서 메모리를 넘어서는 상황이 발생하여 메모리 단편화 현상이 계속 발생하였으며 이를 해결하기 위한 방법이 필요하였다.
해결 책은 재배치가 가능한 바이너리로 지능적인 로더를 이용하여 메모리에 재배치할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정하는 것이었다.
이 로더는 재배치 코드가 자리할 위치 정보를 전달받고 재배치 코드에는 로드한 데이터에서 수정이 필요한 주소를 로드할 수 있는지를 알려주는 플래그를 삽입하였다.
따라서 이를 통해서 프로그래머는 오직 필요한 함수만 로드할 수 있게 되었고 컴파일러는 라이브러리 함수 이름을 __외부 참조__로 생성했으며 외부 참조를 외부 정의에 링크시키기 위해 링킹 로더가 등장하였다.
링커 로더의 등장으로 컴파일하로 로드할 수 있는 단위로 분할이 가능하게 되었지만 프로그램이 점점 커저감에 따라서 그때 당시 느린 저장장치의 한계로 링킹 로더가 너무 느렸다.
이에 로드와 링크가 두 단계로 분리되었고 링커라는 별도의 어플리케이션으로 이 작업들을 처리하도록 하였다.
링커는 링크가 완료된 재배치 코드를 만들어 주었고 그 덕분에 로더의 로딩 과정이 빨라졌으며 한번 만들어둔 실행 파일은 빠르게 로드가 가능해졌다.
하지만 C와 다른 고수준 언어를 사용하기 사작했고 프로그램은 역시 또 더 커졌다.
소스는 .c파일에서 .o파일로 컴파일 되며 링커로 전달되어 빠르게 로드될 수 있는 형태의 실행파일로 만들어 졌다.
각 모듈별로 컴파일 하는 시간은 빨라졌을지 몰라더 전체 모듈을 컴파일하는 과정은 꽤 오래 걸렸다.
하지만 하드웨어의 발전이 눈부시게 발전하였고 링크 시간 자체가 많이 줄어들게 되었다.
이렇게 액티브 X와 공유 라이브러리의 시대가 열렸고 .jar 파일도 등장히기 시작했다. 컴퓨터는 이제 충분히 빨라져 로드과 링킹을 동시에 할 수 있게 되었다.
이렇게 컴포넌트 플러그인 아키텍처 가 등장하게 되었다.
그래서 오늘날 우리가 게임할때 무언가 모드를 변경하고자 할 때 DLL이나 .jar만 변경하는 등의 일이 가능하다.
런타임에 플러그인 형태로 결합할 수 있는 동적 링크 파일이 이 책에서 만하는 컴포넌트에 해당되며 오늘날에는 컴포넌트 플러그인 아키텍쳐를 쉽게 사용할 수 있다.