2021-02-24-TIL

"Read-only" Instance - Collections.unmodifiableList()

class ClassA {
		public void callee (List<String> copiedList) {
				copiedList.remove(0); // This must be banned!
		}
}

class ClassB {
		public void caller () {
				ClassA a = new ClassA();
				List<String> originalList = new ArrayList<>();
				originalList.add("java");
				originalList.add("Collections");
				originalList.add("unmodifiableList");
				a.callee(originalList);
		}
}

자바에서 객체를 리턴해주면 얕은 복사(shallow copy)가 되어서 넘어간다. 즉, List<String> copiedList 변수에 ArrayList<String> originalList 객체를 넘겨주면 객체의 주소가 직접 복사되어 넘어간다. 따라서 참조 변수를 통해 remove 등 배열의 요소에 접근하여 수정을 할 수 있는 문제가 발생한다. 따라서 읽기 전용으로 사용하고자 할 때, 외부클래스에서 수정을 못하도록 Collections.unmodifiableList를 사용하여 막을 수 있다.

참고로, final로 선언해도 그 참조값만 바꿀 수가 없다는 것이지 List의 각 요소는 얼마든지 바뀔 수 가 있다. 그렇기 때문에 불변객체로 선언하여 각 요소에 대한 수정까지 완전히 막아주는 것이 바람직하다.

https://www.techiedelight.com/unmodifiable-list-java/

[CODE REVIEW] Mission 4 : 모든 기물 배치하기 by Rodin

Board

  • chess 패키지안에 pieces가 있는데 요구사항과는 다릅니다. chess 패키지로 나눈 이유가 따로 있는 것인지는 잘 모르겠지만, 두 개의 패키지를 병렬 배치하는 것이 좋을 것 같습니다.
  • emptyLine() 메서드가 반드시 필요한 것인지, 그냥 필드로 선언해도 되는지 고민해볼 필요가 있는 것 같습니다. (담당하는 기능이 거의 없는 것 같습니다.)
  • pieceCount()는 getter와 역할이 완전히 동일한데, getPieceCount()로 선언하는 것도 그 의미를 더 명확히 하기위해서 나쁘진 않을 것 같습니다. (하지만 크게 상관 x)
  • 오류를 내지않고 검증이 된 piece만 추가하는 방법이 있습니다.

GameMain

  • try~with~resource 문 안에 ;는 여러 자원을 서술하지 않는 경우에는 필요가 없습니다.
  • start, end 이외의 명령에 대해서 처리를 해주는 것이 좀 더 좋을 것 같습니다.

StringUtils

  • EOF를 추가하는 것이 좋다고 합니다.

BoardTest

  • assertEquals(expected, actual) -> assertThat(actual).isEqualTo(expected)

[roach]

  • method로 빼서 color나 piece를 검증하는 로직을 추가하면 될 것 같다. 하지만 나중에 자료구조가 바뀌므로 그 때 변경 가능한 부분
  • initialize()는 메서드 분리를 해도 좋을 것 같다.
  • getWhitePawnResult 시리즈는 중복인 것 같다.
  • emptyLine()은 굳이 메서드로 관리될 필요가 없다.
  • 필드에 final 처리가 잘 안 되어있다. 변경이 안 되도록 막아줄 필요가 있다.
  • board.initialize()를 @BefreEach로

[Wan]

  • by Honux -> getBlackPawnsResult() 이름이 직관적이지 않다는 지적
  • blackResult 지역변수와 이름이 겹친다? -> 괜찮다
  • pieceCount테스트 코드에 값->갯수 DisplayName을 정확하게 작성하는 것이 좋다.

[Freddy]

  • try~with~resource에서 세미콜론 생략
  • catch문은 예외에 대한 동작을 이어나가고 싶을 때 사용한다. 지금은 크게 필요없어 보인다.
  • 패키지 변경 요망
  • pieceCount는 메서드 내부에서 계속 카운트 하지말고, list의 사이즈를 가져오는 것이 의미상이나 논리상으로나 좀 더 정확한 것 같다.
  • Piece에서 color를 검증하는 것이 옳다. color가 red나 blue가 들어오면? Piece 생성자에서 검증을 한다던지.. representation도 마찬가지인데, 일일이 검증하기 복잡해지므로 다른 구조로 설계하는 것이 나을 것이라는 생각이 들 것이다.
  • 8개 까지만 추가하고 더 이상 추가하지 못 하도록 예외처리 할 수도 있다.
  • 초기화를 안한 상태에서 이전의 객체를 그대로 쓰면 테스트가 의도와 다르게 작동할 수 있다.

[hiro]

  • enum을 사용하면 Freddy가 지적한 부분이 해결될 수 있을 것 -> hiro의 PR참조
  • enum은 소문자/대문자 각각 따로 두었다가 지적받음. 아예 따로 클래스로 빼는게 좋다고 함.

[Woody]

  • 지역변수를 밖으로 빼는 것도 좋은 것 같다.
  • 정렬요정

[Tree]

  • 테스트코드를 메서드 별로 작성한게 좋아보인다.
  • enum은 equals말고 ==로 비교 가능해서 좀 더 좋은 것 같다.

보일러 플레이트 - 핵심 로직을 제외한 코드

알고리즘 스터디

String " " + " " + " "

https://coding-factory.tistory.com/529

https://jamesdreaming.tistory.com/179

study-whiteship

안녕하세요? 백기선님의 라이브 스터디를 뒤늦게나마 따라가기위해 스터디 그룹을 만들었습니다. 다들 의견을 수렴하여 스터디 방향을 잡고 시작하려고 합니다.

  1. 목표 : 백기선님의 라이브 스터디(18주 과정) 완료

  2. 시간 : 매주 토요일 10:00 ~ 12:00 (약 2시간)

  3. 스터디 진행 방식

    • TODO: 스터디 진행 시간표

    • TODO: 의논해보고 결정

  4. 스터디 유의사항

    • 2주차의 진도를 한 주 만에 끝내는 것이 목표이므로 다소 빡셀(?) 수 있습니다. 하지만 ‘꼼꼼히 다 한다'보다는 ‘한번이라도 모든 범위를 다루는 것'이 목표입니다.

  5. 참여인원

    • 적정인원은 4~5 명 정도라는 의견이 있습니다. 이 부분은 좀 더 이야기 해보고 결정하면 될 것 같습니다.
    • 참여 확정인원 : 4명 (Dong, August, roach, 새리)