개요
저번주에 팀장님께 Youtube URL을 받았다. 현재 운영중인 상품 수집/색인기의 리팩토링이야기가 나왔었는데, 새로이 설계를 어떻게 해야하는지, 단순히 코드가 가독성이 좋아보이고 몇몇 디자인패턴을 사용하는것이 아니라, 쉽게 부분별로 적용을 해야하는 부분이 아닌것을 알려주길 위함인듯 하다. 해당 URL은 2019. 07. 02에 올라온 우아한테크세미나이다.
주제 키워드
해당 영상에서의 주요 키워드는 의존성이다.
의존된 객체들은 함께 변경될 가능성이 있다. 즉, 엮여있다.
영상에 의존성의 종류별로 설명이 되어있는데 간략하게 종류는 다음과 같다.
연관관계
A -> B로 영구이동
의존관계
일시적으로 관계를 맺고 헤어짐
상속관계
B가 변경되면 A도 변경
실체화관계
인터페이스의 시그니처가 변경되었을 때만 변경
의존의 경우 가장 좋은 방법은 의존성으로 엮여있지 않는 것이지만 실제로 관계가 없는 코드가 있을 수는 없을듯 하다. 해서 관계를 사용하되 꼭 피해야하는 것이 있다고 하였다.
객체지향설계시 피해야하는 경우
양방향 의존성은 피해야한다.
class A {
private B b;
public void setA(B b){
this.b = b;
this.b.setA(this);
}
}
class B {
private A a;
public void setA(A a) {
this.a = a;
}
}코드를 보면 A클래스에서 B를 set하여 의존성이 생겼는데, B클래스에서도 A를 set해서 의존성이 생겨버렸다. 즉, 의존성 사이클이 생겨버렸는데 이런 사이클이 생기면 안된다고 한다. 왜 생기면 안되느냐라고 한다면, 큰 프로젝트에서 무분별하게 이러한 사이클이 생기면 그 프로젝트에 변경이 필요할때, 연쇄작용처럼 하나의 클래스가 아닌 모든클래스를 변경해야 할 수도있다.
다중성이 높은 방향은 피해야한다.
One-To-Many 1 -> N 보다는 Many-To-One N -> 1// One-To-Many class A{ private Collection<B> b; } // Many-To-One class B{ private A a; }
이부분은 정확히 이해할수는 없었는데 Collection의 형태는 그상태로 받고, 객체 클래스 안에 또다시 객체를 받는 것의 방식을 피하라는것으로 해석이 되었다.
패키지 사이의 의존성 사이클을 제거하라
각 성격을 띄고 있는 패키지들에서(영상에서는 주문, 결제, 배달) 다른 패키지로의 객체를 의존해야할 때 (주문된 정보가 결제로 넘어가고, 결제된 정보가 배달로 넘어가고) 서로 의존하지 않고 한쪽방향으로만 가야한다. 서로간에 어쩔수 없이 참조객체가 되어 양방향이 되어야 하는 경우가 있는데 예제에서는 중간 클래스를 두어 연결하거나, 불러올수 있는 객체의 정보만 넘겨주어(ID값) 실제 객체 정보는 해당 클래스에서 확인 할 수 있도록 한다.
영상을 보고난 후, 제대로된 개발을 하려면, 고려해야할 상황이 많다는것을 다시금 깨닫는다. 현재 이글을 쓰는 시점(영상보고 4일째)에서도 다시 영상을 봐야 할정도로 내용이 방대하고 중요하다. 이런 중요하고 좋은 정보를 무료로 볼수 있게된 이 시대에 개발을 할 수 있다는것에 감사한다.
