관심사의 분리

각각의 인터페이스를 공연하는 배역이라 가정할 때,

실제 배역에 맞는 배우를 선택하는 것은 누가 하는가?

 

각 역할을 누가 할지는 배우들 본인이 정하는게 아니다.

역할이 아닌 구현까지 봐라보는 것은 배우가 자신의 역할 뿐만 아니라 상대 배우도 직접 선택하는 것이나 다름 없는 것이다.

이는 결코 유연한 공연을 진행할 수 없다.

유연한 공연을 진행하기 위해선 그 누가 오더라도 해당 배역은 대체될 수 있어야 한다.

 

관심사를 분리하는 것의 진정한 의미는

배우는 본인의 역할인 배역을 수행하는 것에만 집중할 수 있도록 하는 것이다.

다양한 역할,  책임을 주어지는 것이 아니라 본연의 역할과 책임 한가지만 가질 수 있도록 하는 것을 의미한다.

 

이를 구현하기 위해선 역할을 지정해주는 책임을 가진 별도의 기획자가 필요하다.

 

AppConfig 의 등장

애플리케이션의 전체 동작 방식을 구성(Config) 하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들자

• 애플리케이션의 실제 동작에 필요한 구현 객체를 생성한다.
• 생성한 캑체 인스턴스의 참조를 생성자를 통해서 주입(연결) 해준다.
• 이를 통해, 서비스는 오로지 역할(추상화)만 봐라볼 수 있고 그것을 구현하는 구체적인 것에 의존하지 않는다.
• 이제부터 의존 관계에 대한 고민은 외부에 맡기고 실행(역할 및 서비스)에만 집중하면 된다.
• 관심사의 분리 - 객체를 생성하고 연결하는 역할과 실행하는 역할이 명확히 분리된다.
• 클라이언트(해당 서비스를 이용하는 클래스) 입장에서 보면 의존 관계를 마치 외부에서 주입해주는 것 같다고 해서 DI (Dependency Injection) 의존 관계 주입이라 일컫는다.

자세한 예제 코드를 넣을 수 있도록 추후 업데이트 하겠습니다.