나무's 블로그

Framework

• 코드(클래스, 프로토콜, 컴포넌트)/리소스들을 모듈화한 모음
• 사용하는 주체와 IoC(제어의 역전) 관계
• 특정 개념들의 추상화를 제공하는 여러 클래스나 컴포넌트로 구성되어 있다.
• 컴포넌트들은 재사용 가능
• 고수준에서 조작 가능
• iOS에서 제공하는 Cocoa Touch 프레임워크가 존재한다.

Library

• Application이 연결할 수 있는, 패키징된 객체 파일들의 모음
• 사용하는 주체가 기능을 요청하며 사용한다.
• 즉, 개발자가 만든 클래스에서 직접 호출해서 사용

차이점

제어의 흐름에 대한 주도성이 누구에게 있는가에 달렸다.

즉, Application의 Flow를 누가 쥐고 있는가?

• 프레임워크는 전체적인 흐름을 스스로가 쥐고 있고, 사용자는 그 안에서 코드를 넣는다.
• 라이브러리는 사용자가 전체적인 흐름을 만들고, 라이브러리를 필요한 곳에서 가져다 쓴다.

다시 말해, "라이브러리는 라이브러리를 사용하는 측에 주도성이 있고, 프레임워크는 그 틀안에 주도성을 갖고 있다" 고 볼 수 있다.

제어의 역전(IoC)

어떠한 일을 하도록 만들어진 프레임워크에 제어의 권한을 넘김으로써, 클라이언트 코드가 신경쓰는 것을 줄이는 전략

내가 라이브러리의 메소드를 사용하는 것은 쉽게 이해할 수 있다.

결국, 프레임워크의 메소드가 사용자의 코드를 호출한다... 인데

어떻게 프레임워크가 내 메소드를 호출하는가?

1. 쉬운 방법 : 프레임워크의 event, delegate에 나의 메소드를 등록시키는 것
2. DI : 프레임워크에 정의된 protocol 을 나의 코드에서 구현, 상속한 후에 프레임워크에 넘겨준다.
   1. 이는 객체를 프레임워크에 주입하는 것이다.

모듈화

하나의 프로젝트에 모든 기능들을 넣어서 개발하다보면 어느 순간 단점들이 생긴다.

1. 컴파일 속도
2. 하나의 코드를 고쳤을 때, 발생하는 사이드 이펙트

따라서 모듈화를 통해 결합도를 낮추고, 응집도를 높히는 작업

• Module : 라이브러리를 가진 프로젝트로, 특정 역할(네트워크, Custom UI 등)을 수행, 외부에는 정의한 protocol을 통해 호출가능하게 한다. 
• Module Package : 모듈들을 관리, 모듈들의 결합으로 기능을 확장
• Service : 특정 도메인, 서비스를 관리하는 프로젝트
• Common Service : 인증, 보안 등 다른 서비스에서 공통으로 사용되는 서비스
• Main Service : 각 서비스들을 호출 및 연결
• Application : UIApplication에서 제공하는 기능을 받아서 처리

장점

1. 메인 프로젝트에서의 라이브러리 의존성이 사라짐
2. Widget, Watch 등을 개발할 때, 모듈을 쉽게 사용할 수 있음
3. Clean Build시에는 빌드가 느리지만, Rebuild시에는 해당 수정 부분만 컴파일되므로 훨씬 빨라짐