세미나 주제는 IoC Container 입니다.현대적 소프트웨어 설계에 매우 중요한 개념입니다.
IOC입니다.
:-)
자, 이번엔 ‘o’가 소문자인 IoC입니다.
IoC를 굳이 우리말로 번역하자면 ‘제어의 역전’ 정도가 될 것 같습니다.전 그냥 IoC라고 표현하겠습니다.IoC는 동일한 기능을 수행하는 프로그램이 기존의 방법과 반대가 되는 제어 흐름을 사용하는 것을 말합니다.‘Hollywood Principle’이란 별칭을 가지고 있습니다. “Don’t call us, we’ll call you” :-)
이것은 숫자를 입력 받아 제곱 값을 계산하는 콘솔 응용프로그램입니다.(소스코드 리뷰)
이번엔 같은 계산을 수행하는 WPF로 만들어진 그래픽 인터페이스응용프로그램입니다.같은 기능을 가진 프로그램이지만 코드의 흐름은 방금 전 콘솔 응용프로그램과는 전혀 다릅니다.(소스코드 리뷰)
라이브러리와 프레임워크의 관계도 유사합니다.둘 다 재사용 목적의 코드가 배포된 형태이지만 이것을 사용하는 코드와의 관계는 많은 차이가 있습니다.(애니메이션)라이브러리는 주로 사용자 코드에서 필요한 시점에 호출되는 형태를 취합니다.예를 들어 암호화 라이브러리를 사용한다면 사용자 코드 상에서 데이터를 암호화하고 싶은 시점에 라이브러리 코드를 호출해 목적을 달성합니다.
프레임워크와 사용자 코드의 관계는 어떨까요?(애니메이션)라이브러리의 경우와는 정반대의 형태입니다. 사용자 코드가 프레임워크에 의해 호출되는 방식이죠.MVC 응용프로그램을 작성할 때 직접 컨트롤러 인스턴스를 생성하고 액션 메서드를 호출한 적이 있나요?
의존관계에 있는 소프트웨어 구성요소를 표현할 때 기능을 제공하는 구성요소를 서비스라고 부릅니다.항상 그런 것은 아니지만 서비스는 주로 원격에 존재합니다. 데이터베이스도 하나의 서비스라고 볼 수 있습니다.
인터페이스는 컴포넌트의 서비스에 대한 결합도를 낮추는 데에 좋은 도구입니다.물론 요즘은 Ruby, Python, JavaScript 등의 Duck-Typing 언어가 부상하면서 의미가 조금 달라지는 것 같긴 합니다.소프트웨어 구성요소 사이에 결합도가 낮아지면(애니메이션)재사용성이 높아지고 테스트가 용이해집니다.
Dependency Injection은 가장 많이 쓰이는 IoC Container 중 하나입니다.구성요소는 서비스 인터페이스를 사용해 기능을 수행하고 서비스 인터페이스 구현체는 외부에서 주입됩니다.서비스가 주입되는 경로는 생성자, 속성 등이 있고구성요소는 IoC Container에 대해 알지 못합니다.그렇기 때문에 Dependency Injection은 대부분 프레임워크 수준에서 지원되어야 합니다.
Service Locator 역시 많이 쓰이는 IoC Container입니다.구성요소가 서비스 인터페이스를 사용해 기능을 수행하는 것은 Dependency Injection과 같지만중요한 차이점은 구성요소가 IoC Container에 대해 알고 있다는 것입니다.능동적으로 서비스 구현체를 가져오는 것이죠.그렇기 때문에 구성요소는 프레임워크에 크게 영향 받지 않고 Dependency Inversion을 구현할 수 있으며구성요소 생명주기 중 서비스 구현체가 교체되는 시나리오도 수용이 가능합니다.의존 관계가 외부에 드러나지 않는 것도 하나의 특징입니다.
소프트웨어 테스트는 좋은 소프트웨어를 만드는 중요한 수단입니다.(국내외 사례 소개)테스트 주도 개발방법론과 행위 주도 개발방법론,그리고 여기에 IoC Container가 어떻게 사용되는지간략히 설명하겠습니다.
얼마 전 소프트웨어 테스트에 대해 이런 글을 본 적이 있습니다.(애니메이션)“자동화하고,(애니메이션)자동화하고, 자동화하고,그리고 자동화하라!”자동화된 소프트웨어 테스트는 테스트 비용과 실수의 가능성을 줄여줍니다.
TDD는 테스트 작성을 시작으로 한 짧고 반복적인 과정을 기반으로 한 개발 방법론입니다.프로세스는 테스트 작성, 테스트 실패, 코드 구현, 테스트 성공, 리팩토링으로 이뤄집니다.TDD를 사용하면 자연스럽게 코드 커버리지가 높아집니다.
DDD는 소프트웨어를 모델의 투영으로 바라보는 소프트웨어 설계 기법입니다.DDD는 진화하는 모델을 구현하는 소프트웨어에 매우 적합하며유비쿼터스 언어를 사용해 도메인 관계자와 프로그래머 사이의 간극을 줄입니다.
BDD는 TDD가 기원인 개발방법론입니다.BDD에서 테스트는 명세라고 부르는데 그 이유는(애니메이션)도메인 관점에서 테스트가 작성되기 때문입니다.모델과 관련된 행위를 표현하는 스토리를 명세화하고 이 명세를 구현하는 작업이 반복됩니다.그렇기 때문에 테스트 함수의 이름은 주로 ‘should’가 포함된 완전한 문장을 사용합니다.또 이렇게 하면 이후 테스트가 실패했을 때 복구 방법을 빠르게 파악할 수 있습니다.
자, 이제 화끈한 라이브 코딩의 세계로 초대합니다.언제든지 애초에 제가 의도한 것과 다른 결과가 나타날 수 있다는 점을 서로 당황하지 않도록 미리 말씀 드립니다. :-)