#dip

의존성 주입 Dependency Injection : 사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법 의존성 주입 기법 생성자 주입 Setter 주입 메서드 주입 SERVICE LOCATOR 패턴 서비스를 사용하는 코드로부터 서비스가 누구인지 (서비스를 구현한 구체 클래스의 타입이 무엇인지), 어디에 있는지(클래스 인스턴스를 어떻게 얻을지)를 몰라도 되게 해준다. 사용처에서 특정 인스터스에 의존하기 원한다면 아래와 같이 사용해야 한다. Movie 생성자 만으로 의존성이 해결되지

본격적으로 스프링에서 사용되는 코드 패턴과 개념에 대해서 파고 들어간다. 제어의 역전 객체를 직접 생성하지 않고 외부에서 구현체를 넣어줌으로써 제어권을 거꾸로 가지고 가는 현상 IoC는 즉, 설계의 패턴이다. 실체에 의존할 것인가 추상화에 의존할 것인가 의존성 주입 외부에서 의존성을 받는 행동. 즉, 외부에서 new로 생성된 객체를 받는다. DI는 즉, 동작 그 자체다. 의존성을 어떻게 가질 것인가? 관계를 짧고 쉽게 정리하자면 → DI를 하면 IoC가 일어난다. 객체의 생성, 소멸, 작동의 주도권(즉, 제어권)이 객체 자신에게 있

이 부분은 1회차 지만 신경써서 머릿속에 넣어본다. 실제로 설계하거나 구현 할 때 적절한 모델링(추상화)와 인터페이스의 분리에 신경쓸 필요가 있겠다. 그러나 SRP-ISP와 OCP-DIP 관계의 뉘앙스 차이는 아직 잘 모르겠다. SRP; 단일 책임 원칙 OCP; 개방 폐쇄 원칙 LSP; 리스코프 치환 원칙 ISP; 인터페이스 분리 원칙 DIP; 의존 역전 원칙 모델링, 즉 적절한 추상화와 상속을 통해 구현이 바뀌어도 인터페이스를 통해 사용에 영향을 주지 않는다. 상속의 원칙에 만족하는가? → LSP를 만족한다. is a kind o