문자열 덧셈 계산기
Last updated
Last updated
미션 챕터가 바뀌었다. 메인 미션을 해결 하기 전 웜업 미션으로 문제 해결 능력을 예열 시키고 있다.
처음 보다 미션을 풀이 하는데 조금은 편해진 것 같다. 예를 들면 어떤 행동을 바탕으로 테스트 할 것인지, 어떤 인자를 테스트 할 것인지 등 초반 설계를 나름 하기 시작했다.
아직 요구사항이 많지 않기 때문에 분량이 적어 쉽게 재미를 느낄 수 있었다.
프로덕션 코드를 작성 하기 전 테스트 코드를 어떻게 작성 해서 프로덕션 코드를 만들어 낼지 고민을 하는 단계였다.
우선적으로 원시 값을 포장 할 생각이었고 해당 객체에 대한 유효성 검증을 바탕으로 비즈니스 로직에 접근 하면 되겠다고 생각했다.
문자열 숫자를 포장 해 줄 객체와 해당 객체를 인자로 받아 덧셈을 구현 하는 계산기가 내가 테스트 할 대상이다.
객체에게 자주 메시지를 던지는 연습을 해야 겠다고 생각 하고 객체를 만들었다. 그렇게 원시 값 포장 객체인 StringNumber(VO) 가 등장 했고 문자열 숫자를 포장 하고 있다.
미션의 요구사항 중 "빈 문자열 또는 Null을 입력 할 시 0을 반환 하라" 라고 되어 있다. Getter로 접근 하지 말고 StringNumber에게 메시지를 보낼 좋은 기회이다.
"StringNumber 야, 혹시 너가 갖고 있는 문자열이 비어있니?" 라고 물어보고 아니라고 한다면 계산기에서 0을 반환 하면 된다.
"왜 객체에게 메시지를 보내서 상태를 관리 해야 할까?"
만약, 계산기가 문자열 숫자 객체의 호주머니에 손을 집어 넣어 숫자를 덜컥 꺼내와서 0인지 아닌지 또는 Null인지 아닌지 판별하고 있다고 가정 해보자.
일단, Setter에 대해 먼저 얘기 해 볼 필요가 있다.
내 주머니 속에 초콜릿이 들어 있었고 일 하다 답답할 때 먹으려고 먹지 않고 넣어뒀다. 만약 누군가 내 주머니에 손을 집어 넣어 초콜릿을 다 먹어버리고 쓰레기만 다시 넣어뒀다.
초콜릿을 먹고 싶던 내가 주머니에서 초콜릿이라고 생각 했던 것을 꺼내 들어 쓰레기란 것을 확인 했을 때 분노를 어떻게 감당할 수 있을까?
여기서 초콜릿은 객체가 갖고 있는 데이터이고 누군가 주머니에 손을 집어 넣은 것은 객체의 행동이다. 초콜릿 대신 쓰레기가 나온 것은 객체의 반환 값이 의도한 것과 다른 상황이 된다.
두 번째로 객체의 값을 조회(Getter) 하여 전지전능한 객체가 되기로 마음 먹는 상황이다.
계산기는 기존에 사용자가 문자열 숫자를 입력 하면 계산기 내부 로직에 의해 모든 덧셈이 된 결과가 출력된다.
이 때, 계산기는 사용자의 입력 값을 잘 받아왔는지 또는 0인지 물어보지 않고 입력된 내용을 자신이 직접 들여다본 후 판단 했다.
만약 구조가 바뀌었다고 해보자. 0과 Null, 음수, 그리고 의도치 않은 문자들이 들어오면 모두 0을 반환 하기로 했다.
그렇다면 계산기가 직접 판단 해야 할 조건이 늘었다. 0, Null, 음수, 이상한 문자를 계산기가 판단하고 0을 반환 해야한다. 그 다음, 또 요구사항이 바뀌었고 또 바뀌어서 계산기가 무수히 많은 검증을 하고 있다.
이렇게 요구사항이 변할 때 마다 메인 비즈니스 로직이 같이 변하게 되는 문제는 요구사항을 하나 수용 할 때 마다 매번 검증을 새롭게 다시 해야한다. 이전 방식에서 검증이 끝났다고 하더라도 새롭게 검증을 해야하기 때문에 우린 객체에게 메시지를 보내 반환 받는 값만을 갖고 판단한다.
절대 전지전능한 객체를 만들어내지 말자.
생성자 팩터리 메서드 패턴을 사용 하는 데 자유로워졌다. 확실히 생성 하는 데 네이밍이 붙으니 코드를 읽어 나갈 때 거부감이 덜 하다.
저번과 비슷하게 Java Stream 문법을 많이 사용하면서 부담스러운 인식을 벗어냈다. 개인적으로 For loop 내부에서 많은 연산 또는 작업 하는 뎁스를 좋아하지 않는다.
마치 매우 힘들게 운동장을 돌고 있는데 중간 중간 미션을 주는 것 같다."100미터 지점에서 팔굽혀펴기 해, 200미터 지점에서 전력 질주 해, 300미터 지점에서 천천히 달려, 400미터 지점이 다가오면 멋있는 세레머니 해."
일급 컬렉션을 사용 해야겠다 라고 생각 했고, 적절한 상황도 있었다.
사용자 문자는 결국 배열로 변환 되어 반복 연산에 의해 결과 값이 출력되는 구조였기 때문에 배열을 포장하는 일급 컬렉션을 만들어내었어야 했는데 초반 설계 때 생각 하지 못 했던 도메인이 갑작스레 생각이 났지만 솔직히 매우 귀찮았다.
앞으로 유지보수나 가독성 좋은 코드를 위해 초반 코스트는 높지만 잠재적 코스트는 비등한 작업을 해야 하는데 이번 미션은 사실상 손해 본 것이나 마찬가지라고 생각한다. 정말 고쳐야 할 습관이다.
미션에서 정답을 찾는 것 처럼 완수만을 바라봤다는 것이 매우 어리석었다. 여러번 만들고 부숴야 개념을 체화 할 수 있다.