의존성의 종류 - Dependency, Association, Aggregation, Composition
1) Dependency (의존 관계): 한 클래스가 다른 클래스의 기능이나 메소드를 사용하는 관계를 의미한다. 이 관계는 런타임에 결정되며, 일시적인 관계. 예를 들어, 한 클래스의 메소드가 다른 클래스의 객체를 인자로 받아 그 메소드를 사용하는 경우, 의존 관계로 표현된다.
2) Association (연관 관계): 한 객체가 다른 객체와 연결되어 있음을 나타낼 때 그들을 연관관계로 지칭한다. 이러한 연관관계에서 중요하게 볼 점은 '연관 관계의 방향 (navigability) 과 멀티플리시티 (multiplicity)'이다.
3) Aggregation (집합 관계): Aggregation은 Association의 하위 분류로, 집합적인 관계를 표시한다. 연관관계를 가지는 클래스 객체와 라이프 사이클이 동일하지 않을 경우, Aggregation 관계이다.
4) Composition (구성 관계): Composition은 “belongs-to” 혹은 “has-a” 관계를 나타낸다. 이는 한 객체가 논리적으로 더 큰 구조를 가지며, 다른 객체를 포함하고 있다는 것을 의미한다. 예를 들어, 방은 건물에 속하거나, 다시 말해 건물은 방을 가지고 있다. 이 관계는 강한 “has-a” 관계로, 소유한 객체의 수명 주기가 소유자 객체와 연결되어 있다.
의존성 주입(Dependency Injection)
DI :
- IoC 패턴중 하나
- Object간의 의존성을 낮춰줌
- 외부에서 객체를 생성하고 전달함
- 상위 모듈이 하위 모듈에 의존관계를 가지지 않도록 구현해야 합니다.
- 추상클래스는 그 구현체의 내용에 의존관계를 가지지 않는다.
- 구현체가 추상클래스에 의존관계를 가질 수 있다.
DI의 예시) Factory Method 패턴 (Template Method 패턴이 아님)
문제(Problem)
사용자에게 다양한 문서를 읽어서 객체로 결과를 반환하는 프레임워크 개발을 해야 한다.
Application 클래스와 Document 클래스로 추상화 할수 있는데, 이 두 클래스는 모두 추상 클래스이고 이 클래스들을 상속해서 문서의 종류에 따른 대응을 할 수 있다.
Application 클래스는 언제 Document 클래스를 생성하고 사용해야 하는지는 알 수 있지만 프레임워크에서 구체적으로 어떤 문서를 처리할 Document 를 생성해야 하는지는 결정 할 수 없다.
해법(Solution)
Document 의 서브클래스 중 어느 클래스를 생성하는 지는 Application 클래스의 서브클래스가 결정하도록 설계한다.
Application 클래스의 서브클래스는 추상화된 createDocument()메소드를 정의하여 적당한 Document 클래스의 서브클래스를 반환하도록 한다.
createDocument() 메소드를 factory method 라고 부른다.
