DI / IoC 컨테이너를 기존 애플리케이션에 통합하기위한 권장 사항

이제 IoC (Inversion of Control) 컨테이너를 기존 응용 프로그램에 통합하는 문제에 직면하고 있으며 커플 링을 줄임으로써 테스트 가능성을 높이는 궁극적 인 목표로 가장 쉽게 달성 할 수있는 방법에 대한 몇 가지 권장 사항을 찾고 있습니다. 일반적으로 대부분의 클래스를 신 객체 로 분류하지는 않지만 정적, 단일 톤 및 인터페이스 부족을 통해 너무 많은 책임과 숨겨진 종속성이 있습니다.

다음은 직면해야 할 몇 가지 과제입니다.

• 의존성 주입은 자주 사용되지 않습니다
• 정적 메소드가 풍부합니다-팩토리 및 헬퍼 메소드 모두
• 싱글 톤은 상당히 널리 퍼져 있습니다
• 사용되는 인터페이스가 너무 세분화되지 않음
• 객체는 종종 기본 클래스를 통해 불필요한 종속성을 가져옵니다.

우리는 다음 번에 특정 영역을 변경해야 할 때 실제로 존재하지만 싱글 톤 및 정적과 같은 전역에 숨겨져있는 종속성을 제거하려고 시도합니다.

나는 IoC 컨테이너를 의존성 주입의 도입에 부수적 인 것으로 생각하지만, 이러한 의존성을 없애는 데 도움이 될 수있는 관행과 권장 사항이있을 것으로 기대합니다.

이와 같은 것을 꺼내려면 단계적으로 작업해야하며, 각각은 사소한 것이 아니지만 달성 할 수 있습니다. 시작하기 전에이 프로세스를 서두를 수 없다는 것을 이해해야합니다.

1. 응용 프로그램의 주요 하위 시스템과 interface각 하위 시스템을 정의하십시오 . 이 인터페이스는 시스템의 다른 부분이 사용하는 방법 만 정의 해야 합니다. 참고 :이 과정에서 패스를 두 번 이상 받아야 할 수도 있습니다.
2. 기존 코드에 위임하는 해당 인터페이스의 랩퍼 구현을 제공하십시오. 이 연습의 목적은 대량으로 다시 작성하는 것을 피하고 새로운 인터페이스를 사용하도록 코드를 리팩터링하는 것입니다 (예 : 시스템의 커플 링 감소).
3. 작성한 인터페이스 및 구현을 사용하여 시스템을 빌드하도록 IoC 컨테이너를 설정하십시오. 이 단계에서는 IoC 컨테이너를 인스턴스화하여 응용 프로그램을 불러올 수 있도록합니다. 즉, 서블릿 환경에 있다면 서블릿 init()메소드 에서 컨테이너를 가져 오거나 만들 수 있는지 확인하십시오 .
4. 각 서브 시스템 내에서 동일한 작업을 다시 수행하십시오. 이번에는 리팩토링 할 때 스텁 구현을 실제 인터페이스로 사용하여 인터페이스를 사용하여 컴포넌트와 통신합니다.
5. 구성 요소 크기와 기능의 균형이 맞을 때까지 필요한만큼 반복하십시오.

완료되면 시스템에 있어야하는 정적 메소드는 Collections클래스 또는 클래스 를 보는 것과 같이 실제로 기능 하는 Math메소드입니다. 정적 메소드는 다른 구성 요소에 직접 액세스하지 않아야합니다.

이것은 많은 시간이 걸리는 계획입니다. 리팩토링을 수행 할 때 설계 방식에서 더욱 SOLID가되고 있는지 확인하십시오. 처음에는 고통 스러울 것입니다. 응용 프로그램 디자인을 반복적으로 크게 변경하고 있습니다.

레거시 코드로 효과적으로 작업하기를 선택하고 그의 조언을 따르십시오. 엄선 된 코드의 아일랜드를 구축하는 것으로 시작하여 점차 더 체계적인 애플리케이션으로 나아가십시오. 대량으로 변경을 시도하는 것은 재난의 요리법입니다.

IoC를 도입 한 주된 이유 는 모듈의 분리 입니다. 특히 Java의 문제점은 new오퍼레이터가 제공 하는 특별한 바인딩 과 함께 호출 코드가 사용할 모듈을 정확하게 알고 있다는 의미입니다.

이 지식을 중앙 위치로 옮기기 위해 공장이 도입되었지만 결국 new하드 바인딩을 유지하는 / singleton을 사용하여 모듈을 고정 배선 하거나 구성 파일을 읽고 리팩토링 할 때 부서지기 쉬운 reflection / Class.forName을 사용합니다 .

타겟을 모듈화하지 않으면 IoC가 아무 것도주지 않을 것입니다.

단위 테스트를 도입하면 테스트되지 않은 모듈을 모방해야하므로 동일한 코드로 실제 프로덕션 모듈을 처리하는 가장 쉬운 방법은 IoC 프레임 워크를 사용하여 적절한 주입하는 것입니다. 모듈.