22일차_현재 도움이 될 것 생각하기 (디자인패턴과 mvc2 과감히 패스)

1. 이번주 공통 피드백에서 인상 깊었던 것에 생각 붙이기

• 비즈니스 로직과 UI 로직 분리 (단일 책임 원칙)
• 현재 객체의 상태를 보기 위한 로그 메시지 성격이 강하다면 toString() 사용
• View에서 사용할 데이터라면 getter 메서드 통해 데이터 전달
• 🐱 나는 getter를 쓰기 싫어서 dto를 쓰고서 이를 outputFormatter에서 포맷팅 해줬었는데, toString(로그 메시지 성격 강할 시)을 쓰는 것도 방법이 될 수 있단걸 배웠다.

• 연관성 있는 상수는 static final 대신 enum 활용
• 🐱 상수로 표현 가능한 것들에 대해 enum을 쓸지 상수를 쓸지 고민한적이 있었는데, LottoRule 같은 enum을 활용했음 좋았을 거 같다.

• 객체는 객체 스럽게 사용 → 데이터 꺼내지 말고 메시지 던지도록 구조 바꿔 데이터를 가지는 객체가 일하도록 하기
• 🐱 getter를 무조건적으로 지양해야 하는 건 아니지만, 이런 경우엔 지양해야 한단 디렉팅이 명확해서 좋았다. tda 원칙을 이야기 하는 거 같다. 나도 저번 주차에 이런 이상한 객체가 있었는데, 리팩토링하면서 tda 원칙을 따르니 디렉팅처럼 객체를 객체스럽게 사용할 수 있었다.
getter를 사용하는 대신 객체에 메시지를 보내자
getter는 멤버변수의 값을 호출하는 메소드이고, setter는 멤버변수의 값을 변경시키는 메소드이다. 자바 빈 설계 규약에 따르면 자바 빈 클래스 설계 시, 클래스의 멤버변수의 접근제어자는 private이며, 모든 멤버변수에 대해 get…
https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/

• 인스턴스 변수 수를 줄이기
• 🐱 필드 수가 많은 건 그 인스턴스가 여러 책임을 떠맡은건 아닐지 의심해볼 만 하다 생각해왔다. 책임 관점에서 가 아닌 버그 발생 가능성, 객체 복잡도 측면에서 불필요한 필드를 없애 필드 수를 최소화하란 관점이 인상깊었다.

• 성공이랑 예외 둘다 테스트하기. 특히 경계값 부분
• 🐱 테스트코드를 작성하면서부터 생성 테스트는 꼭 해야할까란 고민이 들었었는데 이 역시 쌓여서 단위 테스트의 일부로 동작할것이기에 성공 테스트로서 생성테스트도 해야 한다 판단했다.

•  테스트코드도 리팩터링 하기. 특히 중복 코드 제거
• 🐱 테스트코드,, 무지성으로 짜다보면 중복 코드가 왕창 나오기 쉽다. 주의하자.

• 테스트를 위한 편의 메서드는 구현 코드에 구현하지 않기
• 🐱 테스트를 위한 메서드를 stub 같은 형태로 테스트패키지쪽으로 빼는 것도 방법이 될 거 같고, functional interface로 만들어 람다식으로 활용해보는 것도 좋은 거 같다.

• 단위 테스트가 어려운 코드 리팩토링 → 테스트 하기 어려운 것을 클래스 내부가 아닌 외부로 분리
• 🐱 테스트 하기 어려운 것과 쉬운 것의 관계를 그림처럼 표현해서 좋았다. 더 나아가, 테스트 하기 어려운 부분은 단위 테스트하지 않아도 된단 건 랜덤값은 테스트하지말라는 힌트도 된다 생각했다. 한 단계 윗 객체로 보낸다해도 여전히 그 윗 객체는 테스트가 어려울텐데, 이런 경우 인터페이스와 구현체를 활용하면 좋을 거 같다.

• 테스트 쉽게 구현하기 위해 가독성 이상의 일을 하는 private 함수를 테스트하고 싶다면 이는 객체 분리의 신호
• 🐱 private 함수의 역할을 가독성 그 이상인지 이하인지 측면에서 바라보는 게 인상깊었다. 어쩌면 당연한 이야기인데 이는 테스트코드를 안짜고선 느끼기 힘들다. 테스트코드가 주는 이점이란 생각이 들었다.

2. 이번주 코수타를 보고 든 생각 정리하기

• 디자인 패턴에 대해
• 2주차에 썼다가 뒤늦게 yagni 원칙에 위반한단 걸 알게 됐었다. 따라서 3주차엔 최대한 yagni 원칙을 위반하지 않게 생각하려 하다보니 자연스레 사용하지 않게 됐었다.
• 코수타에서도 해당 과제에선 디자인 패턴에 대해 권장하지 않는단 걸 보고 잘 따라가고 있었구나 라고 생각했다.

• mvc1과 mvc2
• mvc1을 1주차부터 써왔다.
• mvc 패턴을 썼을 때 다가온 장점은 controller가 모델과 뷰 사이에서 코드를 간결하게 정리해준 단 점이 컸다.
• 그러다 지난 주차에 controller가 너무 비대해져 service 레이어가 추가된 mvc2를 적용해볼까 고민한 적이 있었다.
• 하지만, 이는 도메인끼리 역할 분담이 제대로 되지 않아 발생한 일이었다 판단해 mvc2 도입은 적절치 않다 결정했다.
• 이번 4주차에선 도메인끼리 적절히 메시지를 주고받게해 controller가 비대해지는 문제를 해결해보겠다.

Today in 프리코스