사다리타기 - FP, OOP(생성)
미션하며 정리한 내용
👨💻 Java 서식(format)
%d: 정수 서식%s: 문자열 서식%와 포맷문자(d,s) 사이에 정수를 설정하면 글자 길이를 설정할 수 있습니다.- 양수인경우 오른쪽 정렬이고 음수인 경우 왼쪽 정렬입니다.
- 표현 대상의 길이가 설정한 길이보다 작은 경우 공백으로 채워집니다.
- [java] 자리수 맞추기, printf
- [Java] String.format 을 이용한 문자열 형식 설정하기
👨💻 Java Deque(덱, Double Ended Queue)
-
양쪽 끝에서 삽입과 삭제가 모두 가능한 자료 구조의 한 형태입니다.
-
제공되는 메서드는 굉장히 많은데 조금 간단히 요약하면 아래와 같습니다.
add~
자료구조에 데이터를 추가하여 사이즈를 초과하게 되는 경우IllegalStateException을 발생시킵니다.offer~
자료구조에 데이터를 추가하여 사이즈를 초과하게 되는 경우false(데이터 추가 실패)를 반환합니다. 데이터 추가가 성공되는 경우true를 반환합니다.remove~
자료구조에서 데이터를 반환 및 삭제할 때 자료구조가 비어있는 경우NoSuchElementException를 발생시킵니다.poll~
자료구조에서 데이터를 반환 및 삭제할 때 자료구조가 비어있는 경우null을 반환합니다.get~
자료구조에서 데이터를 반환할 때 자료구조가 비어있는 경우NoSuchElementException를 발생시킵니다.peek~
자료구조에서 데이터를 반환할 때 자료구조가 비어있는 경우null을 반환합니다.
-
capacity-restricted deque(용량 제한 덱)
LinkedBlockingDeque를 이용하면 용량(사이즈) 크기를 제한할 수 있는 덱을 만들 수 있습니다.
👨💻 Collectors.joining
매번 Collectors.toList()를 후 반복문을 돌면서 StringBuilder에 append하여 결과 문자열을 구하였는데 더 편한 방법이 있어 정리하게 되었습니다.
-
delimiter
-
delimiter, prefix, suffix
👨💻 Domain, VO
- 결국 VO도 Domain 객체입니다.
- Domain, VO에 대한 좋은 글이 있어 기록합니다.
리뷰 내용
🤔 리뷰 링크
사다리타기 - FP, OOP: 2단계 - 사다리(생성) #2074
🤔 검증 로직들을 굳이 유틸리티 클래스에 모아 놓을 필요가 있을까?
리뷰어
검증 로직들을 굳이 유틸리티 클래스에 모아 놓을 필요가 있을까? 한 군데서만 쓰이는 로직들이 유틸리티 클래스에 모여 있어 응집도가 떨어지는거 같다.
나
처음에는 저도 범용적으로 사용되는 검증 로직만 Validator(유딜리티 클래스)에만 모아 놓고 사용하려고 하였습니다. 하지만 개발 후 다시 보니 실제 범용적으로 사용되는 로직은 얼마 없었습니다. 따라서 리뷰 받은 내용데로 정말 범용적으로 사용되는 로직을 제외하고는 모두 도메인 클래스로 이동시켜 응집도를 향상 시켰습니다. 항상 유틸리티 클래스에 작성한 로직이 범용적인지 생각해봐야겠습니다.
🤔 Stream.generate()을 사용해보자
mapToObj대신Stream.generate을 사용해보는게 어떨까?
Stream.generate()
Returns an infinite sequential unordered stream where each element is generated by the provided Supplier. This is suitable for generating constant streams, streams of random elements, etc.
Stream Oracle Document
- 인자로 함수를 받고, 함수가 리턴하는 객체들을 요소로 갖는 Stream을 생성합니다.
- 무조건
limit으로 제한을 걸어줘야 합니다. 그렇지 않으면 무한하게 생성합니다. - [Java] Stream을 생성하는 다양한 방법
- Java - Stream 생성 방법 및 예제
🤔 리스트 참조를 주의하라
리뷰어
리스트를 아무 처리 없이 반환시키면 객체 외부에서 내부의 값을 수정하는 일이 벌어질 수 있다.
나
이전 단계에서 동일한 피드백을 받았었는데 또 놓쳐버려서 많이 아쉬웠습니다. 해당 문제는 리스트 조회시 Collections.unmodifiableList()를 이용하여 해결할 수 있습니다.
🤔 생성자는 작게 만들어라
리뷰어
생성자는 최적화, 객체 생성을 위한 검증, 객체 생성 이외에 로직은 포함하고 있지 않는게 좋다.
🤔 원시값 전달을 주의하라
리뷰어
원시 포장객체의 값을 꺼내서 함수 파라미터로 전달하지 않는게 좋다. 기껏 해놓은 검증이 무의미해질 수 있다.
🤔 커스텀 예외를 너무 사용하지 말자
리뷰어
이펙티브 자바나 코틀린 등의 도서에서도 상위 수준에서 저수준 예외를 활용해야 하는 경우나 동일한 예외(IllegalArgumentException)가 이미 처리된 예외처리 구문과 겹치는 경우 등 꼭 필요한 경우가 아니면 가급적 표준 예외를 사용할 것을 가이드하고 있다.
나
- 예외 메시지를 도메인에서 분리하여 관리하는 방법을 고민하다 커스텀 예외를 사용하였지만 Enum으로 따로 예외 메시지들만 관리해주는 것으로도 충분하였습니다.
- 참고) 이 피드백을 받으며 이전에 프로젝트를 하면서 팀원이 모든 예외 사항 마다 커스텀 예외를 만드는 경우 관리가 힘들고 복잡해지기 때문에 너무 많은 커스텀 예외를 만들지 않는게 좋다는 의견을 냈던게 기억났습니다.
