우아한객체지향을 보고

우아한객체지향 동영상을 보고 나서 정리해본다.

​

![]()

의존성 (dependency)

​

의존성이란 각 개체간 의존성이 존재할 때 변경에 의한 영향이다.

​

클래스 의존성 관계는 아래와 같다.

![]()

​

패키지에 포함된 클래스 사이의 의존성

​

![]()

​

클래스 간 의존성이나 패키지 간 의존성 역시 변경에 의한 영향이 있는가 없는가를 확인해보고 설계를 해야한다.

​

또한 양방향 의존성을 되로록 피하는 형태로 구성해야 한다.

​

양방향으로 의존성이 존재한다면 이것 역시 변경에 의한 영향도가 클 수 있기 때문에 이럴 경우 단반향으로 설계하도록 변경한다. 이러한 법칙등을 다음과 같이 기본적인 가이드 라인으로 만들었다고 한다.

​

• 양방향 의존성을 피하라.

• 다중성이 적은 방향을 선택하라.

• 의존성이 없다면 제거하라.

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

​

**<여담>**

기본적으로 코딩이 완료되고나, 코딩하기 전에 위와 같이 의존 관계를 알아보도록 설계를 그려본다고 한다.

앞서 복잡한 비즈니스 로직에서 이러한 개념을 떼어내는 것이 먼저 되어야 설계를 그려볼 수 있을 텐데, 우아한 형제들에서는 이러한 일들을 자발적으로 많이 진행하는거 같다.

​

관계의 방향 = 협력의 방향

= 의존성의 방향

​

연관 관계 = 협력을 위해 필요한 영구적인 탐색구조.

(탐색 가능성)

​

의존 관계 = 협력을 위해 일시적으로 필요한 의존성.

(파라미터, 리턴타입, 지역변수)

​

설계 개선하기

코드 작성 후 의존성 관점에서 설계 검토.

​

의존성을 끊는 방법에 대해서는 다음과 같은 이야기가 나옴.

​

• 양방향 의존성 관계일 때 중간 객체를 이용하여 의존성 사이클 끊기.

• 어디까지 조회할 것인가?

• 객체 그룹의 조회 경계가 모호.

• 수정시 도메인 규칙을 함께 적용할 경계는? (트랜젝션 경계는 어디까지 인가?)

​

객체 참조의 문제점

= 모든 것이 연결된다.

​

이러한 문제에 대하여, 어떤 객체들을 묶고 어떤 객체들을 분리할 것인가?

​

• 함께 생성되고 함께 삭제되는 객체들을 함께 묶어라.

• 도메인 제약사항을 공유하는 객체들을 함께 묶어라.

• 가능하면 분리하라.

​

​

마지막에 패키지 의존성 관련해서 나누는 장면이 나온다.

Order와 Delivery를 합쳐서 OrderDeliveryService가 만들어진다.

​

이 의존관계를 그대로 가져가게 되면 도메인 단위 패키지 나눌 때, 각 패키지 안으로 서로 의존관계가 있기 때문에 넣을 수 없다. 이때 domain event를 사용하였는데 이미 나도 사용중이였고, 전에 deview에서도 리팩토링 이야기 할 때 도메인 단위 패키지로 나눈 뒤 이후에 서버가 분리되면 패키지 단위로 나뉠 수 있도록 변경했다는 이야기가 생각났다.

​

나는 도메인 단위로 패키지를 나누는 것을 동일하게 생각하였으나, 이런 의존 관계 문제에 대해서는 뭔가 부패하도록 냅두는 장치를 두는게 맞다고 생각되어 작은 단위별로 그러한 부분들을 나눴었는데, 이번 강의에서 보여준 형태로 구성해보는 걸 생각하는 것이 더 합리적인 것 같았다.

​

꽤 간지러운 곳을 긁어주는 이런 내용이 아니였나 싶다.

​

​

발표자료

https://www.slideshare.net/baejjae93/ss-150432699

** 우아한 객체지향 ** from Young-Ho Cho

발표강좌

https://www.youtube.com/watch?v=dJ5C4qRqAgA

​