본문 바로가기

개발

[우아한테크세미나] 190620 우아한객체지향 by 조영호님

출처: https://www.youtube.com/watch?v=dJ5C4qRqAgA&t=1764s

이 글은 객체지향 언어를 설계할 때 핵심인 의존 관계의 종류와 그에 대한 개념

그리고 그것을 어떻게 설계할 수 있는지에 대한 영상을 보고, 그 내용을 정리한 포스팅이다.

 

객체지향 언어를 사용하면서 설계는 필수적이고, 설계를 할 때는 의존성을 어떻게 관리하는지가 핵심이다.
의존성에 따라 설계가 바뀌게 되고, 이것에 의거하여 코드를 어떻게 배치할 것인가에 대한 의사 결정이 설계라고 보면 도니다.

 

그럼 의존성의 정의는 무엇일까?

간단하게 말하면, A가 B에 의존한다고 할 때, B가 변경이 있으면 A도 변경이 있다는 의미이다.
하지만 주의할 점은 B가 변경이 있다고 해서 무조건 A도 변경이 있어야 의존성이 있는 것은 아니다.
따라서 의존성은 변경에 의한 영향의 가능성이다.

 

클래스 의존성의 종류

지금 살펴볼 의존성의 종류는 클래스 의존성에 대한 종류이다.

크게 4가지 연관 관계, 의존 관계, 상속 관계, 실체화 관계가 존재한다.

연관관계

연관관계란 A에서 B로 이동할 수 있어요 라는 의미이다.

그냥 코드상으로 저렇게 A라고 하는 클래스에 B라고 하는 클래스의 경로를 가지고 있고, 객체 참조가 있다라고 보면 될 것 같다.

 

의존 관계

의존 관계는 간단하게 코드 상에서 파라미터에 그 타입이 나오거나, return 타입에 그 타입이 나오거나, 메소드 안에서 그 타입의 인스턴스를 생성한다 하면 의존 관계라고 보면 된다.

 

정리하자면, 연관관계는 아예 A에서 B로 영구적으로 갈 수 있는 경로가 있는 걸로 보면 되고

의존관계는 협력을 하는 어떤 시점에 일시적으로 딱 관계를 맺고 헤어지는 관계를 의존 관계라고 한다.

 

상속 관계

상속 관계는 B라고 하는 클래스의 구현을 A가 상속 받는 것이다.

그러니 B가 바뀔 때, A라는 클래스도 변경이 일어나게 된다.

 

실체화 관계

인터페이스를 implement하는 관계라고 보면 된다.

상속관계와 실체화 관계의 차이는, 상속 관계는 구현이 바뀌더라도 영향을 받을 수 있는 것이다.

하지만 실체화 관계를 interface의 operation signature가 바뀌었을 때만 영향을 받는 것이다.

 


이러한 클래스 의존 관계와 더불어, 패키지 의존성 관계도 있다.

그냥 간단하게 어떤 패키지 안에 있는 클래스가 다른 패키지 안의 클래스에 대한 의존성이 있다면 두 패키지 간에 의존성이 있다고 보면 된다.

 


이렇게 의존 관계의 종류에 대해 살펴 보았다.

그럼 이제 이러한 의존 관계를 설계하는 데에 몇 가지 가이드 라인이 존재하는데, 그것에 대해 살펴 보겠다.

 

양방향 의존성을 피해라

A가 B로 가는 의존 관계가 있고, B에서 A로 가는 의존 관계가 있다면

B가 바뀔 때 A도 바뀌고, A가 바뀔 때 B도 바뀌게 된다.

 

이렇게 되면 A와 B가 하나의 클래스인데 어거지로 찢어 놓은 것이라고 봐도 된다.

 

또 이것보다 더 안좋은 것은

A의 Setter메소드 안에서 B의 Setter메소드를 콜하는 것이다.

A와 B 사이의 관계를 동기화 시켜줘야 한다.

+ 여기서 말하는 동기화란 무엇일까?

 

다중성이 적은 방향을 선택해야 한다.

A에서 B타입의 컬렉션을 인스턴스 변수로 잡거나, 아니면 컬렉션에 대해서 dependency를 가지는 것 보다는,

반대 방향의 dependency를 가지도록 코드를 짜는 것이 좋다.

 

List나 Collection이나 Set같은 것들을 인스턴스 변수로 가지면, 굉장히 다양한 이슈가 발생한다.

 

따라서 가급적이면 다중성이 적은

즉, A에서 B의 List를 가지는 것 보단, B가 A의 단방향 참조를 하나 가지는 것이 가장 좋다.

 

의존성이 필요없다면 빼버려라

말 그대로 A와 B 사이에 의존성이 불필요하다면, 과감히 빼버리는게 가장 좋다.

 

패키지 사이의 의존성 사이클을 제거해라.

패키지 사이에는 양방향 의존성이 있으면 안된다.

여기서는 사이클이라고 표현하는데, 예를 들어 3개의 패키지 사이에 dependency를 따라 갔을 때,

사이클이 발생하는 것을 피해야 한다.

 

만약 이렇게 되면 세 개의 패키지 중 하나만 바뀌어도 모두가 변경되어야 하고

하나의 패키지처럼 된다.

 

 

 

정리

 

앞에서 의존성의 종류, 그것의 특징, 그러한 의존성을 어떻게 설계해야 하는지 등에 대해 살펴보았다.
이런 컨퍼런스 열릴 때, 아직 나한테는 어울리지 않은 매우 어려운 개념이라고 생각했었는데
공부해보면 정말 좋은 내용들 같다.

지금 단순히 듣고 공부하고, 정리 한번 했다고 해서 그냥 넘어가지 말자.
영상 뒷 부분에 어떻게 실제로 설계하는지 예시들도 나와있고, 그에 대한 의사 결정 과정 또한 담겨 있다.

차근차근 보고, 공부한 후, 실제로 적용해보는 연습을 해보자.