들어가며
2~4주차 미션 문자열 계산기와 로또를 진행하며 리뷰어님께 집중적으로 받은 피드백을 정리하고 실수를 반복 하지 않게 위해 정리한 포스트입니다.
🍊 1,2차 피드백 전체 내역
1차 GIT Full-Request 진행내역에서 1차 피드백 전체 내역을 확인 할 수 있습니다.
🍎 상수와 메서드의 접근제한자를 올바르게 사용하자
-
메서드 및 상수가 public으로 외부에 노출되어 있는 문제가 자주 발생했다.
-
외부에서 사용해야하는 메서드가 아니라면 private를 사용해서 접근이 불가능하게 만들어 줘야한다!
-
특히 테스트코드를 작성하기 위해 private를 public으로 열어서 사용한 케이스가 몇 몇 있었는데
이러한 경우 클래스(책임) 분리의 신호이지 않을까 고민해 보자
🍒 reference 타입 vs primitive 타입
반환 타입 혹은 리스트 타입 선언에서 reference 타입(Boolean, Integer)을 사용한 경우가 발생했다.
이 부분은 reference 와 primitive 타입을 잘 몰라서 발생한 경우였다.
김영한님 강의에서 엔티티를 설계할때 reference 타입을 사용 하라고 했었는데
이는 reference 타입의 특징인 null값이 존재 할 수 있음을 염두에 두고 설계를 한 것이었고
현재 미션에서는 null값이 발생할 이유가 없기 때문에 primitive 타입을 사용하는 것이 맞았다.
자세한 내용은 reference vs primitive 비교 참고
🥝 방어적복사를 사용하자
생성자 파라미터로 받은 외부 파라미터 객체를 객체 필드에 바로 할당을 하게되면
외부 파라미터가 변경되면 객체의 필드값 또한 동일하게 변경이 된다는 문제가 발생한다.
이를 해결하기 위해선 깊은 복사 혹은 방어적 복사가 필요하며
자세한 내용은 내 블로그의 [얕은복사/깊은복사]방어적복사를 참고하자
🍑 static import는 언제 사용해야 할까?
import문을 사용하면 클래스의 패키지명을 생략할 수 있는 것과 같이 static import문을 사용하면 static멤버를 호출할 때 클래스명을 생략할 수 있다.
즉 아래와 같이 Output클래스를 생략 할 수있다.
Output.printSomeThing
//클래스명 생략
printSomeThing하지만 코드가 간결해지고 특정 클래스의 static 멤버를 자주 사용할 때 편리하지만 남용하면 독이 될 수 있기 때문에 주의해야 한다.
Util성 클래스에 사용하거나 view 패키지에 사용하는게 일반적이며 사용하더라도 클래스명을 생략하지 말고 사용하는등 직관성을 유지하도록 고민해야한다.
🍓 캐싱을 사용하여 불필요한 객체 생성을 피하자
내 코드에서 정규표현식을 사용하기 위해
Pattern.matches() 를 호출하고 Pattern 객체의 matches() 기능의 내부에서 정규표현식용 Pattern 인스턴스를 생성하여 한번만 사용하고 버리는 코드가 있었다
Pattern은 인스턴스 생성 비용이 높은 비싼객체라 더더욱 성능이 떨어지게 되었는데
이런경우 캐싱을 사용하고 Pattern을 재사용 함으로 성능 향상을 할 수있다.
🍋 디자인 패턴을 사용하자
MVC패턴을 사용하여 모델과 컨트롤러 뷰를 분리 하라는 피드백을 받았고
전략패턴을 사용하여 코드의 중복을 줄여보라는 피드백을 받았다
각 패턴을 적용해 보았는데 자세한 내용은 내 블로그 MVC총정리 , 전략패턴 정리를 참고하자
🍈 객체에게 메세지를 던지자
객체의 값을 꺼내와서 변경하는 경우가 자주 발생했고
ex) Aaa.getName()후 파라미터로 넘긴다던지 비교를 한다던지?
이러한 방식은 리팩토링의 대상이 된다(클린하지 못하다)
이러한 경우 객체에게 메세지를 던져 해결 해야한다
아래는 객체의 이름을 꺼내서 비교하는 대신 메세지를 보내 결과를 리턴 받는 메서드이다.
ex) Aaa.compareName(String Name)
🍐 클래스 분리를 하자
🥥 일급 컬렉션을 사용하자
