2021-06-25-TIL
의존성의 관리
설계란 무엇인가? 코드를 어떻게 배치할 것인가에 대한 의사결정. 어떤 패키지에 어떤 프로젝트에 코드를 넣을것인가에 대한 고민들. 핵심은 ‘변경' 같이 변경되는 것들끼리 묶는것이 바람직하다. 변경은 곧 의존성이다.
의존성
B가 변경될때 A도 변경될수 있다. 그 가능성을 의존성이라고 한다. 의존성이 있다고해서 반드시 바뀌는것은 아니다. 설계를 잘 하면 변경에 대하여 무조건 바뀌지는 않는다. (설계를 잘하면)
클래스 의존성
- 연관관계
- A -> B로 영구적으로 갈 수 있는 관계
- 의존관계
- A -> B로 갈수도 있는 관계
- 상속관계
- 구현이 바뀌더라도 영향을 받음
- 실체화 관계
- 시그니처가 바뀌면 영향을 받음
패키지 의존성
- 양방향 ``` class A { private B b;
public void setA(B b) {
}
} ```
- 단방향
JPA를 사용하면 성능이슈가 많이 발생하게 되는데, 다중성이 적은 의존성의 방향을 선택하는 것이 유리하다. 예를 들어, A가 B의 리스트를 가지는 것 보다는 B가 A의 참조를 하나 가지는 것이 낫다는 것이다. 가장 좋은 것은 불필요한 의존성을 빼버리는 것이다.
패키지 3개가 a->b->c->a라면 결국 하나의 패키지라는 것이다. 이것이 가장 기본적인 의존성 관리의 법칙이다. 의존성의 사이클이 생기지 않도록 해야한다.
가게 & 메뉴
장바구니 데이터는 보통 로컬에 저장을 한다. 서버에 저장을 하지는 않는다. 여기서 발생할 수 있는 문제가 있다. 예를 들어, 사장님이 판매하고자 하는 데이터를 삭제하게 되면 장바구니의 데이터와 판매상품의 불일치가 발생하게 된다. 따라서 주문데이터와 실제로 있는데이터와의 일치여부를 검증하는 것이 필요하다.
처음엔 메뉴-주문항목, 옵션그룹-주문옵션그룹, 옵션-주문옵션을 모두 비교해야한다. 즉, 바뀔 수 있는 값에 대해 상호검증이 모두 들어가야한다. 추가적으로 가게가 영업중인지, 최소주문금액을 충족하는지를 한 번 더 검증을 해야한다.
검증로직을 하나하나 태워야한다. 첫번째로 주문금액이 최소주문금액 이상인지 확인 -> 가게가 영업중인지 확인 -> 옵션의 가격과 주문옵션의 가격이 같은지 비교 -> 옵션의 이름과 주문옵션의 이름 비교 -> 옵션그룹의 이름과 주문옵션그룹의 이름 비교 -> 메뉴의 이름과 주문항목 이름 비교
관계의 방향 = 협력의 방향 = 의존성의 방향
연관관계 -> 협력을 위해 필요한 영구적인 탐색 구조 Order가 Shop으로 가는 경우가 간혹 한번있다면 이것을 연관관계가 있다고 보기 어렵다. 그런데 이것이 아주 빈번하다면 연관관계라고 볼 수 있다.
핵심은 연관관계로 갈 것인지, 의존관계로 갈 것인지가 아니라 방향성이다.
- 연관관계 = 탐색가능성(navigability)
어떤 객체가 있는데, 이 객체를 알면 다른 객체를 찾아갈 수 있음을 뜻한다. - 연관관계와 협력
어떤 객체를 참조하려면 어떤 객체가 있어햐 해 라는 타당성이 있어야한다.