[우아한테크세미나] 190620 우아한객체지향 by 우아한형제들 개발실장 조영호님

의존성 : B가 바뀌었을때 A가 바뀔 가능성이 있다

의존성이 있다해서 무조건 바뀌진 않음.

B라는 클래스의 내부 구현이 변경 되더라도 A 클래스에 영향 안 줄 수 있다.

(설계를 잘하면)

의존성 : 변경에 의해서 영향을 받을 수 있는 가능성

1. 클래스 사이에 의존성

2. 패키지 사이의 의존성

3. 클래스 의존성

   1. 연관관계 (A에서 B로 이동할 수 있다) → 영구적으로 갈 수 있는 관계
   2. 의존관계 (파라미터, 리턴타입에서 해당 타입이 나오거나 메서드 안에서 그 객체 생성 시 dependency라 보면 된다.) → 협력하는 시점에 관계 맺고 헤어지는 관계
   3. 상속 관계 : 부모가 바뀌면 A가 바뀐다. → 구현이 바뀌더라도 영향 받음
   4. 실체화 관계 : 인터페이스를 implement하는 관계 → 인터페이스 operation 시그니처 바뀌었을때만 영향 받음

4. 패키지 의존성

• 패키지 A가 패키지 B에 의존한다 : B의 클래스가 바뀌면 A의 클래스가 바뀐다.
• import에 다른 패키지 이름이 나온다 → dependency가 있다.

좋은 의존성을 관리하기 위한 규칙

1. 양방향 의존성을 피하라.
   • B가 바뀌면 A도 바뀌고, A가 바뀌면 B도 바뀐다.
   • 원래 하나의 클래스로 봐도 되는 것을 어거지로 찢어 놓은것.
   • A와 B 사이의 관계를 항상 동기화 시켜줘야한다. 성능이슈 많이 발생하고, 버그 많이 발생한다.
   • 따라서 양방향 연관관계 피할 수 있으면 단방향 연관관계로 바꾸기