프레임워크는 소프트웨어의 구체적인 부분에 해당하는 '설계'와 '구현'을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것이라 볼 수 있다. 이 프레임워크는 반제품(Half done application)적인 특징을 띄는데 그 이유는 미리 정의된 소프트웨어이기 때문이다.
이 프레임워크의 핵심 기술 요소에는 IoC(Inversion of Control, 제어의 역전)가 있다. 프레임워크에 (의존성) 제어의 권한을 넘김으로써 클라이언트 코드가 신경써야 할 것을 줄이는 전략이다.
예를 들어 스프링 프레임워크와 같은 경우 스프링 컨테이너에 싱글톤으로 유일한 객체가 등록되는데(스프링 빈이라 함), 이 빈을 필요로 하는 객체에 자동으로 주입해줌으로써(DI, 의존성 주입) 개발자가 객체 생성에 대한 신경을 덜 쓰게 할 수 있다. DI는 IoC 프로그래밍 모델을 구현하는 방식중에 하나이고, Spring 에서는 IoC를 구체적으로 DI라는 방식을 통해서 "의존성 역전 제어"를 하고 있는 것이다.
source: https://daheenallwhite.github.io/programming/2019/07/15/library-framework-api/
개발자는 프레임워크로부터 추상적인 클래스를 Sub-classing(Sub-typing)하여 애플리케이션에 특정한 클래스를 생성하며 사용하거나, 프레임워크가 제공하는 클래스를 참조하며 코드를 작성한다.
제어의 권한을 넘겨받은 프레임워크는 사용자 코드를 제어한다. 즉 애플리케이션의 흐름은 프레임워크에 미리 정해져 있다(수동적).
반면 라이브러리는 사용자가 자신의 코드에 사용할 뿐 애플리케이션의 흐름은 사용자 코드가 직접 제어한다(능동적).
따라서 프레임워크를 사용하는 데 있어선 필연적으로 여러 제약 사항이 존재한다. 하지만 이 프레임워크는 이미 수많은 검증을 통과한 안정적인 설계 구조이기에 이를 바탕으로 빠른 개발이 가능해진다. 개발자는 오로지 비즈니스 모델에만 집중하면 되기 때문이다(예를 들어 DI도 (spring)프레임워크의 컨테이너에 등록하면 자동으로 이루어짐).
또한 개발자가 많이 투입되어야 하는 프로젝트라면, 프레임워크는 그 자체로 가이드라인이 되어 전체 시스템의 통합성, 일관성을 증가시켜준다.
=> 이미 많은 검증을 거친 안정적인 설계를 바탕으로 빠른 개발이 가능해진다.
나아가 한번 만들어진 프레임워크를 통해 SW 재사용성을 높일 수 있다. 프레임워크가 제공하는 인터페이스를 구현함으로써 동일 도메인에 존재하는 애플리케이션에 반복적으로 재사용할 수 있다. 그리고 이 프레임워크는 확장성도 좋아서 다형성을 통해 개발자가 직접 프레임워크의 인터페이스를 확장할 수 있도록 한다.
=> SW 재사용성이 높아진다.
일반적으로 프레임워크는 라이브버리 개념을 포함한다.
프레임워크란 이미 많은 검증이 거쳐진 디자인 패턴과 라이브러리의 집합이고, 제어의 흐름을 가지는 SW라 할 수 있다.
프레임워크와 클라이언트 코드가 낮은 결합도를 가진다. 대게 프레임워크에서 클라이언트 코드에 제공하는 인터페이스는 추상 클래이거나 인터페이스 그 자체이다. 즉, 자연스럽게 DIP 원칙이 잘 적용되도록 한다.
(DIP 원칙이 잘 지켜지면, 결합도(의존도)를 낮출 수 있다.)
프레임워크가 제공하는 기능을 사용하여 응용 SW를 빠르게 개발
프레임워크 기반 구조를 바탕으로 기능 확장이 용이하다.
프레임워크의 제어 범위 안에서만 코드를 작성하기에 개발 자유도가 제한적이고, 많은 제약사항을 따르지만 그 만큼 안정적인 시스템을 구축할 수 있다.