협력과 책임, 역할을 고민하며 만들어보는 커피점

목록

1. 포스팅 개요
2. 본론
  2-1. 프로젝트 개요
  2-2. 고민 및 어려웠던 점
  2-3. 아쉬운 점
  2-4. 배운 것
3. 다음으로

1. 포스팅 개요

[이전에 객체지향의 사실과 오해를 읽고 기록한 포스팅](https://ssangsu.tistory.com/300)에서서서 보고 느낀 점을 고민하면서 커피점을 구현한다고 했었던 거 같다.

구현했던 레포는 여기에 링크되어있다.

2. 본론

2-1. 프로젝트 개요

해당 프로젝트는 순수 POJO로 구현한 커피샵이다.
최대한 객체 지향적인 프로젝트로 만들려다보니 순수 자바로 구현했다.

2-2. 고민 및 어려웠던 점

구조가 그려지지 않았던 문제

구조가 그려지지 않은 것이 가장 혼란스러웠다.
항상 뭔가 만들면, 스프링을 써왔고, 컨트롤러-서비스-데이터접근 계층적으로 생각하면서 코드를 작성해오다가 이번엔 정말 순수 객체 그 자체로 생각하려다보니 책임, 역할을 생각하고 고민하려고 해도 쉽게 풀리지 않았다.

레포의 readme에는 도메인 객체가 해야할 일(책임) , 도메인 기능 요구사항을 기록하고, 책임, 역할 등등을 작성했지만, 2-3번을 "이건 아닌 거 같다"하면서 갈아엎었다.

참고로 현재는 위에 링크된 레포지토리의 readme를 보면 유스케이스도, 워크플로우도 아닌 이상한 그림이 하나 그려져있다.

여하튼 정말 구조가 그려지지 않았다.
책임, 역할, 메세지, 협력을 생각하면서 코드를 작성했는데,

처음엔 책임은 인터페이스에 작성했고,
그 책임들을 수행하는 객체에 역할을 부여했다.
이건 어느 정도 가능했던 거 같다.

그런데 이제 메세지와 협력을 생각하니 인터페이스에 모든 책임을 작성해놓았다고 하더라도 햇갈렸다.

물론 다른 생각이나, 몰입하지 못한 환경에서 코드를 작성해서 그런 것도 영향이 있다.

책에 보면 객체는 협력을 하기 위해 메세지를 주고받는다고 되어있다.
그리고 객체를 정의할 때 상태(필드)가 아닌 행동(메서드)를 먼저 정의해라고 되어있다.
그리고 그 행동은 결국 메세지로 이어지는데,

나는 메세지는 행동 즉 메서드라고 생각했다.
물론 메세지는 자바 코드상에선 메서드로 구현된다.

그러나 행동과 메세지는 코드를 작성해보니깐 조금 다른 이야기인 거 같다는 생각을 했다.

구현한 커피숍의 예를 들어, 고객은 키오스크를 통해 커피를 주문한다.
그리고 여기서 알 수 있는 것은 고객은 키오스크를 통해 주문할 책임 이 있는 것이다.

처음 내가 생각했던 것은
..(참 바보같은 생각이었다고 반성하고 있다. 그리고 굵은 표시한 부분은 나를 헷갈리게 하는 주요 내용이었다. )
책임은 인터페이스에 정의된다고 했었는데,
고객이 키오스크를 통해 주문할 책임을 인터페이스에 정의했다.
(아마 실력있는 사람은 웃으면서 바보같다고 생각할 것 같다..)

그리고 구현하려 했다..
그러나 구현하지 못했다.
왜 못했는지는 말로 표현할 수 없지만, 결과적으로는 애초에 잘못된 접근이다.

그렇다. 고객은 키오스크를 통해 주문할 책임은 있지만,
고객으로부터 커피를 주문 받을 책임은 키오스크애 있는 것이다.

정리하자면, 고객이 커피를 주문하고 커피를 받기 위해서는 고객이 아닌 키오스크가 주문에 대한 요청 메세지를 받도록 해야한다는 것이다.

협력은 객체들의 요청과 응답에 의해 기능이 수행되는 것이다.

지금 구현한 레포애서 커피주문 프로세스는 다음과 같다.

고객 <-주문-> 키오스크 <-제조-> 바리스타 와 같이 되어있다.

그리고 주문을 요청받는 내용은 키오스크에 그 책임이 정의되어있다.
"커피를 제조하라"는 키오스크의 메세지는 바리스타가 받도록 되어있다.

이걸 깨닫고 생각하기까지 좀 오랜 시간이 걸렸던 거 같다.

협력, 책임, 역할, 메세지를 고민한다면 다음과 같이 생각하면 쉬울 것이라고 생각한다.
예를 들어 만약 고객이 커피를 주문해야하는 기능이 있다고 가정하자.

1. 고객은 커피를 주문해야 한다.
2. 커피를 주문하기 위해선 어떤 요청 값들이 필요할까?
3. 필요한 값을 정리한다.
4. 정리되었다면, 누가 이 값들을 받고 고객의 요청을 처리할까? => 즉 누가 이 요청메세지를 받을까?
5. 당연히 키오스크다. -> 키오스크가 고객의 요청 메세지를 받도록 요청을 수행할 행동을 정의하자.

이런 식으로 생각하면 보다 좀 더 쉬워지지 않을까.. 공유해본다.

테스트 코드

테스트 코드를 습관화가 필요할 거 같아서 각각의 객체마다 테스트코드를 작성해서 테스트를 돌려봤다.
지금 제일 위에 사진이 바로 모든 테스트가 통과한 사진인데, 사실 잘 작성했는지, 내가 검증하고자 하는 부분을 제대로 잘 작성하고 처리했는지는 의문이 많다.

여하튼 말하고자 하는 것은
테스트 코드 작성.., 빡세다... 어렵다...

특히 이 테스트를 위해 어떤 값들이 세팅이 되어있어야 하는가 에 대한 내용인 given 쪽을 생각하는 것이 어려웠지만, 한번 작성하고 나면 계속 복붙하고 수정하며 사용할 수 있기 때문에 후에 갈수록은 괜찮았다.

그리고 검증하는 과정에서 내가 의도한 대로 값이 나오지 않는 경우가 발생하긴 했는데, 이 때마다 코드를 살펴보고 어디서 버그가 발생하는지 보고 찾아내서 수정하는 경우가 있었다.
이 때 기분이 좀 묘하게 좋았다.

테스트 코드 작성은 힘들고 귀찮지만, 테스트를 검증하는 과정에서 디버깅이 이루어지는 게 작은 규모의 토이 프로젝트에도 불구하고, 오묘한 희열감(?)이 느껴졌다.

이에 대한 아쉬운 점은 방금 말했다시피 given 값을 복붙한다고 했는데, 다른 프로젝트의 코드들을 보면, given 쪽이 아예 메서드화 되어있다.
계속 반복적으로 쓰다보니 메서드로 되어있었던 거 같은데, 지금은 귀찮아서 안 했다.

테스팅 강의 들을 때도 우빈님이 그렇게 하셨던 걸로 기억하긴 하는데, 나중에 필요할 때 다시 그렇게 작성해보려고 한다.

스프링은 너무...

스프링은 너무 좋은 녀석이라는 걸 더욱 더 느끼게 되었다.
이 프로젝트를 스프링으로 옮기면 Response의 역할을 하는 객체들도 있고, DTO의 역할을 하는 객채도 있다.

스프링을 사용하면 Layered 아키텍처에서 각각의 계층마다 책임과 역할, 그리고 계층마다 오고가는 DTO의 역할이 너무도 명확하기 때문에 스프링을 했더라면 구조가 머릿 속으로 그려지고, 구현은 한 층 더 쉬웠을 거라 생각했다.

순수 자바로 구현하다보니 계층적인 구족의 그림이 아니라, 각각의 독립적인 객체들로 보고 협력을 생각해야했던 터라, 낯설긴 했다.

단순히 자바로 뭔가 이런 협력 구조를 만들어본 적이 없어서 이렇게 생각 할 수도 있겠지만,
여하튼 스프링이 정말 개발하기엔 너무 편하다는 것을 이번 계기로 느꼈다.

2-3. 아쉬운 점

아쉬운 점..
모든 게 아쉽다.
이번 POJO 커피점을 얼른 마무리 짓고 스프링으로 빨리 구현해보고 싶어서 얼렁뚱땅 끝냈다.

그리고 코드도 최대한 잘 작성하고 싶었긴 했는데, 뜯어보면 분명 개판일 것이다.

테스트 코드도 불필요한 검증 내용이 있을 거고,
코드에 대한 리팩터링도 좀 더 고민해보고 싶지만, 나는 다른 걸로 빨리 넘어가고 싶고, 해보고 싶은 내용이 많아서 일단은 패스한다...

나중에 좀더 차근차근히 다시 코드를 봐야겠다는 생각을 하게 된다.

2-4. 배운 것

객체 지향적인 개발을 하고 싶었지만, 추상화하려면 할 수 있는 것도 많고, 책임과 역할을 더욱 더 명확히 하고, 자바독도 더 잘 달았어야 했지만, 그리고 코드도 더욱 더 깔끔하게 작성하면 더 좋았겠지만,

확실히 하나 배운 것은 있다.

협력, 메세지 이다.
책임과 역할은 조금 더 고민해볼 필요가 있지만,
협력과 메세지는 서로 객체들이 어떻게 주고 받도록 해야하는지는 선명하게 기억될 거 같다.

3. 다음으로

다음은 이 프로젝트를 스프링을 이용해서 REST API 로 개발해볼 것이다...!
-끝-