우아한테크 세미나 #우아한 객체지향

우아한 객체지향

https://www.youtube.com/watch?v=dJ5C4qRqAgA&t=1843s

의존성을 이용해 설계 진화시키기

의존성 Dependency

• B가 변경될때 A도 변경되는 것, A dependes-on B

• 같이 변경되는 코드를 같이 넣어야 된다

• 클래스 이름, 메서드, 구현등이 변경될 가능성

클래스 의존성의 종류

• 연관 관계 - 영구적 경로

• classA{
      private B b;
  }

• 의존 관계 - 협력을 딱 하고 헤어지는 경우

• class A{
      public B method(B b){
          return new B();
      }
  }

• 상속 관계

• class A extends B{
  
  }

• 실체화 관계

• class A implements B{
  
  }

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

• 어떤 패키지 안의 클래스가 다른 패키지 안의 클래스에 의존성이 있는 경우
• import 문에 다른 패키지가 있는 경우

기본적인 가이드

• 양방향 의존성을 피하기

• 다중성이 적은 방향을 선택하라 Many to one

  • class A{
        private Collection<B> bs;
    }
    class B{
    
    }

  • class A{
    
    }
    class B{
        private A a;
    }

  • A 가 여러 B를 가지는거 보다 많은B가 A를 가지고 있는게 좋다

• 의존성이 필요 없다면 제거

• 패키지 사이의 의존성 사이클(양방향) 제거

관계의 방향 = 협력의 방향 = 의존성의 방향

런타임에 객체들이 어떻게 동작하는지에 따라, 방향성에 따라 어떤 관계를 설정 할지 정해주어야 함

• 연관 관계 - 협력을 위해 필요한 영구적인 탐색 구조
  • 어떤 객체에서 다른 객체로 매우 빈번하게 방향이 진행되는 경우, 객체 참조(구현 방법)
  • 탐색 가능성 - Order를 알면 OrderLineitem을 찾아갈 수 있다
• 의존 관계 - 협력을 위해 일시적으로 필요한 의존성
  • 파라미터, 리턴, 지연변수

메세지를 결정하고 메서드를 만들자

일단 작성해보고 내 코드의 의존성 관점에서 설계를 검토 (사이클이 생기는지?, 이 위치에 참조를 가져가는게 맞는지?)

​

패키지 간의 양방향 의존성이 발견되는 경우

• 의존성의 방향이 잘못 되어 있거나, 패키지의 구분이 잘못 되었다
• 중간 객체를 이용한 의존성 사이클 끊기
• 클래스들이 구체적인것에 의존하지 말고 추상적인것에 의존해야 한다
• 추상적인거면 꼭 interface일 필요는 없고 그저 잘 변하지 않는 것! 공통적인 것! 양쪽에 필요한 데이터!

객체 참조로 인한 문제점

• 연관 관계가 있는경우 성능 문제 - 어디까지 조회할 것인가?
• 시작 객체가 변경되었을때 연관되 도메인 규칙을 함께 적용해야하는 객체의 범위는?
• 어떤 테이블에서 어떤 테이블까지 하나의 단위로 트랜젝션을 설정할 것인가? 요구사항이 추가될 수록 트랜잭션이 길어진다
• 객체들을 쫓아가면서 수정을 하다보면 트랜젝션 경합으로 issue가 발생

해결방법은?

• Repository를 통한 탐색

• @Entity
  @Table(name="ORDERS")
  public class Order{
      @Column(name="SHOP_ID")
      private Long shopId;
  }
  
  Shop shop = shopRepository.findById(order.getShopId());
  
  @Entity
  @Table(name="SHOPS")
  public class Shop{
      @Id
      @GeneratedValue(strategy = GenerrationType.IDENTITY)
      @Column(name="SHOP_ID")
      private Long id;
  }

객체간 그룹으로 묶고 이 단위로 트랜잭션 설정 한다 이 그룹 단위로 조회 경계가 설정된다

내부에서는 연관관계가 필요하면 설정하고 객체 그룹끼리는 id를 이용해서 탐색한다

각 객체가 Validation 로직을 처리하다보니 파악하기가 힘들다

이걸 한군대 보아서 Order에 전달해서 처리(OrderValidationService 만들어서 실행)

Order는 주문 처리에 대한 내용이 있어야되고 validation은 같은 내용이 아니기 때문에 주문 처리에 대한 내용이 수정된다고 validation이 수정되지 않기 때문에 이는 응집도가 낮은 객체

어떨때는 절차적으로 끝내서 Validation 로직에 대한 파악이 쉽게

id로 연결되었을때 순차적 실행이 필요한 경우

• 절차지향적으로 로직을 모으는 경우, 앞의 Validation과 동일
  • 사이클이 생기면 interface로 (주문 완료는 order 그룹 쪽에 실제 실행은 delivery 그룹 쪽에) 끊어내기
• 도메인 이벤트 퍼블리싱