79개의 Conversation 정리

1주차엔 코드리뷰의 정체를 늦게 알고 몇 개 못해본것이 못내 아쉬워서, 이번에는 코드리뷰를 왕창 하고 다녔더니.! 많은 분들이 내 코드에도 리뷰를 달아주셨다.
하나씩 정리하며 공부해보자!

👌controller에 인스턴스 주입하기

생성자 주입을 통한 생성자의 호출 시점에 1회 호출 되는 것이 보장된다. 그렇기 때문에 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용할 수 있다.
MangKyu's Diary:티스토리

controller는 외부에서 생성된 view객체의 의존성 주입을 통해 결합도가 낮아지고 유연성이 높아진다!
단, view의 경우에는 함수를 static으로 처리하면 객체를 생성하지 않고도 사용할 수 있었다.

따라서, 주입할 객체는 controller내부에서 생성되는 객체를 분리할때 쓰는 것은 어떨까..!
-> 3주차에 적용완

👌 그놈의 Naming 잘하기

변수 이름은 항상 고민하게 되는데도... 차라리 이름에 넣을 변수를 그대로 함수명에 표기하는게 더 직관적이었을것 같다!

무지성으로 로직만 처리했다고 하면 Controller붙이기 반성..!
Controller는 View와 Domain의 '중개자' 역할임을 항상 명심하자

👌 그놈의 static

그러게? generator를 인터페이스로 분리하는 건 생각했지만 왜 항상 객체를 새로 생성하기만 했을까..!

1. 변화를 가정하지 않는다.
2. 메소드가 인스턴스 변수를 사용하지 않는다.
3. 인스턴스 생성에 의존하지 않는다.
4. 메소드가 공유되고 있다면, 정적 메소드로 추출해낼 수 있다.
5. 메소드가 변화되지 않고, 오버라이딩 되지 않는다.

심지어 generator() 함수는 외부에서 공유되는 메소드인데..!
그러나!
이렇게 static으로 처리하게 될 경우 Generator를 Interface화 하는 전략이 사라지게 된다. 그렇게 되면 2주차에 적용했던 Generator 다형성 전략이 사라지는 셈..
[공부] interface 활용기

코드에 적용하진 않았지만 적어도 내가 '왜' static을 적용하지 않고, '오버라이딩'을 선택했는지 확신했다.👌

읽으면서 많이 도움되었던 자료 :
[ Java ] static함수 static 변수
[Java] 정적 메소드(static Method)는 언제 사용할까?

👌 누구는 인스턴스 변수로 주고, 누구는 주입받을 파라미터로..

2주차에 코드리뷰를하며 가장 아쉬웠던 부분 중 하나..! 인데 딱 집어 리뷰해주셨다. 덕분에 다시 공부할 수 있었어요. 매우 감사👍👍

나의 코드가 응집도가 높은지 검사해보는 방법은 메소드들에 대하여 인스턴스 변수를 사용하는 비율이 높은지 보는 것이다. 어떤 클래스의 응집도가 높다면 메소드와 변수가 서로 의존하고 있을 것이고, 응집도가 낮다면 상태와 기능의 논리적 연결이 약할 것이고 이는 클래스를 더욱 분리할 수 있음을 암시하기도 한다.
Inpa Dev 👨‍💻:티스토리

나는 당연히 Racing객체, Racing관련 로직을 관리하는 녀석이 RacingController라고 생각했기에 아무생각 없이 넣어줬다..! 앗차..

해당 인스턴스 변수는, RacingController내에서는 잘 사용되고 있었다. 무엇보다 이녀석이 이 변수를 가지고 있지 않으면 GameController가 자동차 경주 목록을 가지고 있어야 하니, 그것도 응집도가 낮아질 것 같았다.

더 알아보기 : 응집도는 어떻게 올릴 수 있을까?

• 클래스에는 인스턴스 변수가 많아서는 안된다.
• 또 메소드는 적어도 하나이상의 인스턴스 변수를 내부에서 사용해야한다.
• 연관있는 코드를 클래스내에 묶어두는 것이 바로 응집도를 높이는 길이다.
• 이상적인 클래스는 인스턴스 변수가 존재하고 모든 인스턴스변수를 모든 메소드에서 사용하는 클래스는 응집도가 높은 클래스이다.

어렵다..! 3주차 리팩토링에서 다시 적용해보자 👊

👌 View에서는 View만

view는 자신의 함수만 쓸 수 있게 하자
고민 : InputView에서 안내 메세지, 에러 메세지를 출력하는 것은 사실 OutputView가 해야하는 일이 아닐까?
그러나 나의 생각에는, InputView에서 출력했을때 함수의 할 일이 더욱 직관적으로 표현된다고 생각한다..!

👌 원시값 포장하기

• 일급컬렉션
• 추가 : Getter 지양
  
  일급 컬렉션

처음 읽었을때 왜 이 문장을 이해 못했나 했더니..! 일급컬렉션과 unmodifiableList 를 몰랐던 나의 잘못이었다.
RacingCar를 관리하는 List를 RacingCars에서 관리 중이었는데, getter를 써버린 것..!
List는 final 선언시 주소값은 변하지 않아도 그 안의 값은 변할수 있다. 😭💦💦

👌 기타 문제와 고민

• 해당하는 for문에서도 변수에 대한 네이밍을 지정 해주시면 가독성이 많이 올라갈 거 같아요!

• List의 conatins() 메서드는 검사할 대상이 많아질수록 효율이 감소합니다! Set을 사용해보시는 건 어떨까요??

• 이름은 바뀌지 않기 때문에 final로 선언하셔도 좋을 것 같습니다!
  추가 공부 : final 파라미터 받기, final 변수와의 차이

• 검증을 생성자에서 진행하는 것은 어떨까요?
  생성자는 검증과 할당 두가지 책임을 가지고 있습니다!
  : 생성자의 성능을 위해 부생성자(from, of..등 생성자를 호출하는 녀석들) 을 통해 검증의 역할을 넘겼다!

• 클래스 네이밍도 중요한 컨벤션 규칙 중 하나입니다. 대중적인 자바 컨벤션은 CamelCase를 사용하고 있으며, 이를 적용하면 StopNumberGenerator가 됩니다.
  💦 : 사실 여기서만 실수 한 것이 아니다.. test케이스를 짜다보니 파라미터를 넣을 때 구분을 위해 snakeCase를 섞어 썼다.. 이번주에는 확실하게 하나로 통일할 수 있도록 하자!

• 매번 [ERROR] 를 반복해서 적어주는 것 보다는 EXCEPTION_PREFIX = "[ERROR]" 와 같이 선언해두셔도 좋을 것 같아요!
  (++) PREFIX를 고정하면 변경 가능성이 줄지만, 모든 상수리터럴에 전부 새로 붙여야 할까?! => 접두사를 붙여주는 함수로 분리하면 어떨까?

• 마지막 쉼표를 삭제하기 위해 문자열의 길이를 계산하는 로직이 있네요! StringBuilder 보다는 String.join() 을 활용하는 방법도 추천드립니다! ( 완전꿀팁 )

추가 :

했보았다! @MethodSource 뽀개기로
JUnit, Test 뽀개기 👊 - @MethodSource 👊