로직 구현, 어떻게 하면 좋을까?

Snoop So·2023년 2월 10일
0

입력/검증/저장/변환/출력 분리

입력 -> 분리/검증 \
				저장/생성
출력 <- 형식/변환 /
  1. 입력(View),
  2. 분리/검증(Controller),
  3. 저장/생성(Use-Case),
  4. 형식/변환(Presenter),
  5. 출력(View)
    코드를 짤 때 항상 이 다섯개의 형식을 고민해보자.

어제 작성한 커피숍 문제를 어떻게 이런 형식으로 구현해볼 수 있을까?

  1. Waiter (입력): 주문을 입력 받는다.
  2. Manger (검증): 주문이 조건에 부합한지 확인하고 주문 커피 목록에 주문서의 커피들을 차례로 추가한다.
  3. BaristaController (검증): 어떤 바리스타가 손이 남는지 확인한다.
  4. Barista (생성): 커피를 만든다.
  5. CoffeePresenter (변환): 생산된 커피를 주문에 맞게 배치한다.
  6. Printer (출력): 주문을 바탕으로 완성된 주문을 출력한다.

근데 확실히 적다 보니 객체 위주로 변수명을 작성하면 객체와 로직이 섞여서 부자연스럽다는 생각이 들었다. 이렇게 작성해봐도 좋을 것 같다.

-객체-
1. Order
2. OrderContainer
3. Coffee
4. CoffeeContainer
5. Baristar

-함수-
1. addOrder (입력): 주문을 입력 받는다. 이때 음료 목록에는 isDone이라는 변수를 포함시킨다.
2. checkOrder (검증): 주문이 조건에 부합한지 확인한다.
3. convertOrderToCoffee (변환): 주문을 확인하고 음료로 변환한다.
4. addCoffee (생성): DrinkContainer에 Drink를 추가한다.
5. printCoffeeContainer (출력): 현재 제작 대기 중인 음료 목록을 출력한다.
6. findBaristaNotWorking (검증): Baristar 인스턴스 중 isWorking 이 아닌 것을 찾는다.
7. convertCoffeeStatusToDone (변환): 전달 받은 음료의 isDone을 true로 변환시킨다.
8. convertCoffeeToOrder (변환): 가장 오래된 주문부터 확인해 해당 음료를 isDone 으로 변환한다.
9. printCompleteOrder (출력): 완성된 주문이 있다면 출력한다.

나는 확실히 객체 지향이 더 어려운 것 같다.. .ㅇ. 물론 UI 쪽은 객체로 취급하는 게 맞겠지만, 로직을 굳이 객체로 구분해야 할 필요가 있을까? 그런데 또 여러 instance가 존재하는 경우에는 객체로 설정해야 할 것 같고..참 어렵다.

갑자기 DDD는 객체 지향일지 함수 지향일지 궁금해진다. 다음에 찾아보자.^ㅡ^

0개의 댓글