2020-11-20-TIL
2020.11.20 TIL
재능은 몰라도 실력은 확실히 늘어가는 것이다. Problem Solving에서 모든 케이스에 대해 예외사항 없이 처리하는 능력도 실력에 해당된다. 나머지 케이스에 대해 모두 만족했다고 해도 하나라도 맞지 않으면 실력이 부족한 것이 맞다.
Java 배열 초기화
Java 배열은 두 가지 방법으로 만든다. new int[5]처럼 길이만 정하는 배열 생성식과, int[] a = {1, 2, 3}처럼 값을 바로 나열하는 배열 초기화식이다. JLS 10.6에 따르면 초기화식을 쓰면 나열한 값의 개수만큼 배열이 만들어지고, 값은 왼쪽부터 차례로 들어간다.
길이만 정해서 만든 배열의 각 칸은 기본값으로 채워진다. JLS 4.12.5 기준으로 int는 0, boolean은 false, 참조 타입은 null이다. 그래서 String[] names = new String[3]을 만든 직후 names[0].length()를 부르면 NullPointerException이 난다. 모든 칸을 같은 값으로 채우고 싶을 때는 Arrays.fill(arr, value)를 쓴다.
1
2
3
int[] scores = new int[5]; // {0, 0, 0, 0, 0}
int[] primes = {2, 3, 5, 7}; // 길이 4
Arrays.fill(scores, -1); // {-1, -1, -1, -1, -1}
SRP(Single Responsibility Principle)
단일 책임 원칙은 흔히 “클래스는 한 가지 일만 해야 한다”로 요약되지만, 원칙을 이름 붙인 Robert C. Martin의 정의는 조금 다르다. 그는 모듈이 바뀌어야 하는 이유가 하나뿐이어야 한다고 설명하고, 같은 내용을 “Gather together the things that change for the same reasons.”라고 다시 쓴다. 같은 이유로 바뀌는 것은 모으고, 다른 이유로 바뀌는 것은 떼어 놓으라는 뜻이다.
이 기준으로 보면 “한 가지 일”의 단위는 기능 개수가 아니라 변경의 원인이다. 예를 들어 게임 진행 로직과 콘솔 출력 형식은 바뀌는 이유가 다르다. 출력 문구를 바꾸려고 게임 규칙 코드를 열어야 한다면 두 책임이 한 클래스에 섞여 있다는 신호다.
코드 리뷰에 남긴 답변
미션 코드 리뷰에서 받은 피드백에 이렇게 답했다.
- 그냥 Game으로 바꾸었습니다.
- final을 붙여서 주입받은 객체를 보존할 수 있겠군요! 그렇게 수정해보았습니다.
- 아하~ 이제야 구체적으로 이해가 되네요! 객체를 받아서 처리하는 방식으로 변경했습니다.
- 원래 그렇게 되어있던 것을 제가 3번 부분을 잘못 이해해서 이상하게 바꾸었네요. ㅠ 그렇게 다시 변경했습니다.
- 최대한 메서드 별로 ‘단일 책임’을 지도록 분리해보려고 노력했습니다. 로직이 없는 메서드(단순한 출력문만을 포함한 메서드)는 로직을 포함하는 단위로 묶었습니다.
2번의 final은 정확히 무엇을 지켜 주는지 구분해 둘 필요가 있다. JLS 4.12.4에 따르면 final 변수는 한 번만 대입할 수 있다. 생성자로 주입받은 필드에 final을 붙이면 그 필드가 다른 객체를 가리키도록 바뀌는 일은 막는다. 하지만 가리키는 객체의 내부 상태까지 고정하지는 않는다. 객체 자체를 바꿀 수 없게 하려면 그 클래스를 불변으로 설계해야 한다.
1
2
3
4
5
6
private final Player player; // 다른 Player로 재대입은 불가
public Game(Player player) {
this.player = player;
}
// player.changeName("x") 같은 상태 변경은 여전히 가능하다
5번에서 메서드마다 책임을 나눈 것도 위의 SRP와 같은 기준으로 볼 수 있다. 출력만 하는 메서드를 따로 두기보다, 그 출력이 어떤 로직의 결과인지에 맞춰 묶은 셈이다.
댓글
아직 댓글이 없습니다