라이브러리(Library)란?
단순 활용이 가능한 도구들의 집합
라이브러리는 특정 기능에 대한 도구 또는 함수들의 집합입니다. 프로그래머가 어떠한 기능을 수행하기 위해서 도움을 주는 또는 필요한 것을 제공해주는 역할을 합니다. 프로그램 기능 수행을 위해 활용 가능한 도구의 집합입니다.
프레임워크(Framework)란?
소프트웨어의 특정 문제를 해결하기 위해서 상호 협력하는 클래스와 인터페이스의 집합
원하는 기능 구현에 집중하여 개발할 수 있도록 일정한 형태와 필요한 기능을 갖추고 있는 골격, 뼈대를 의미합니다.
애플리케이션 개발 시 필수적인 코드, 알고리즘, DB 연동과 같은 기능들을 위해 어느 정도 뼈대(구조)를 제공하며 이러한 뼈대 위에서 사용자는 코드를 작성하여 애플리케이션을 개발합니다. 앱/서버 등의 구동, 메모리 관리, 이벤트 루프 등의 공통된 부분은 프레임워크가 관리하며, 사용자는 프레임워크가 정해준 방식대로 클래스, 메서드들을 구현하면 됩니다.
프레임워크와 라이브러리의 차이
제어 흐름에 대한 주도성이 누구에게/어디에 있는가
프레임워크와 라이브러리의는 개발하는데 있어 쉽고 빠른 생산성을 위해 사용한다는 공통점을 가지고 있습니다.
프레임워크와 라이브러리의 차이는 제어 제어 흐름에 대한 주도성이 누구에게/어디에 있는가에 있습니다.
프레임워크는 전체적인 흐름을 스스로가 쥐고 있으며 사용자는 그 안에서 필요한 코드를 짜 넣으며 반면에 라이브러리는 사용자가 전체적인 흐름을 만들며 라이브러리를 가져다 쓰는 것이라고 할 수 있습니다.
다시 말해, 라이브러리는 라이브러리를 가져다가 사용하고 호출하는 측에 전적으로 주도성이 있으며 프레임워크는 그 틀안에 이미 제어 흐름에 대한 주도성이 내재(내포)하고 있습니다.
프레임워크는 가져다가 사용한다기보다는 거기에 들어가서 사용한다는 느낌/관점으로 접근할 수 있습니다.
프레임워크는 제어의 역전 개념이 적용되어 있어 어플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작합니다.
제어의 역전
제어의 역전은 하나의 설계 원칙입니다. 디자인 패턴이라고도 합니다.
프로그래머가 직접 객체의 생성과 소멸 객체간 관계같은 객체의 제어를 수행하는 것이 아니라, 여러 프레임워크, 컨테이너에서 제어를 수행하는 것 입니다. 확장 가능하고 모듈화된 프로그램을 구성하는 느슨한 결합을 달성하기 위해 다양한 종류의 컨트롤을 반전하는 것을 의미합니다. 여기에는 응용 프로그램의 흐름에 대한 제어와 개체 생성 또는 종속 개체 생성 및 바인딩의 흐름에 대한 제어가 포함됩니다. 이러한 제어의 역전은 클래스간의 결합을 느슨하게 설계하여 테스트가 가능하고 유지보수가 용이하게 만드는데 도움이 됩니다.
React 는 프레임워크일까? 라이브러리일까?
왜 React는 라이브리리일까?
React의 라이프사이클
Render 과정의 라이프사이클을 예시로 했을 때, 순서는 다음과 같습니다.
1) componentWillMount()
2) render()
3) componentDidMount()
React는 위와 같이 프로그램 흐름의 기본적인 틀은 정해져 있습니다.
하지만 앱 실행시 render() 함수는 입력이 필수이지만 componentDidMount() 함수는 자동으로 생성되지만 개발자가 명시적으로 입력해 줄 필요는 없습니다.
하지만 개발자가 API를 호출하거나 다른 작업을 수행하기를 원할 때, componentDidMount()를 통해 프로그램을 추가적인 동작을 정의할 수 있습니다.
이처럼 프로그램 흐름에 작업을 추가하거나 그렇게 하지 않음으로서 프로그램의 흐름을 바꾸는 것이 가능하기 때문에 React가 라이브러리입니다.
리액트의 생태계는 프레임워크이지만 리액트만은 라이브러리
프레임워크로 분류되기 위해서는 필수로 충족해야하는 것들이 있습니다.
다른 많은 프레임워크들이 기본적으로 내장하고 있는 기능들 (예를 들어 라우터 기능이라던가)
리액트에서 이러한 기능들을 구현하기 위해서는 여러가지 추가적인 라이브러리를 같이 사용해야합니다.
(react-router, react-redux, react-saga 등....)
그렇기 때문에 React는 프레임워크로 분류되지 않고 라이브러리로 분류됩니다.
'CS' 카테고리의 다른 글
| 메시지 큐(Message Queue) (0) | 2022.12.15 |
|---|---|
| [Kotlin] 코틀린 (0) | 2022.11.03 |
| 뮤텍스(Mutex)와 세마포어(Semaphore) (0) | 2022.10.20 |
댓글