📘 Effective Java
[Item 5] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
결론 Item 4에서 다른 객체의 상태에 의존하는 경우에는 정적 메소드가 아닌 @Bean이나 @Component를 사용해야한다고 말했다. 책에서는 Item 5에서 이 설명을 하고 있다. 유틸리티 정적 메소드를 만들게 되면 유틸리티성 메소드에만 사용하는 게 좋다. 만약 다른 클래스의 상태를 의존한다거나 사용하는 자원에 따라 동작이 달라지는 방식에는 사용한다면 정적 메소드는 적합하지 않다. 왜냐면 static method는 의존성 주입으로 연결된 객체를 사용할 수 없기 때문이다.(미리 메모리에 올라오기 때문에) 이러한 경우에는 스프링에서는 @Bean이나 @Component를 통해 공통 클래스를 만든다면 해당 클래스는 다른 객체를 의존성 주입을 통해서 사용 할 수 있다.
[Item 4] 인스턴스화를 막으려거든 private 생성자를 사용하라.
결론 보통은 공통 함수를 만들기 위해 @Bean 혹은 @Component를 사용할 수도 있지만 유틸리티 클래스를 만들기 위해 static을 사용할 수 있다. static은 상태에 대한 저장이나 다른 메소드의 상태를 의존한다거나 하는 경우가 아닌 경우(Autowired로 의존성 주입이 필요하지 않은 경우)에 보통 사용한다. 그래서 static 메소드를 사용하는 경우 배열 관련 메소드나 final 관련 메소드를 모아둔 유틸리티 공통 클래스를 만든다. 보통 이러한 클래스는 서버가 올라갈 때 static의 특성상 메소드를 바로 사용할 수 있기 때문에 생성자를 통해 사용한다는 개념이 아니다. 단순히 메소드 사용을 위함에서 쓰이지만 일부 개발자들은 유틸리티 클래스에 생성자를 적지 않는 경향이 존재하는데 이때 생성자..
[Item 3] private 생성자나 열거 타입으로 싱글턴임을 보증하라
싱글턴 싱글턴은 유일한 단 한개의 객체를 생성하기 위한 패턴이다. 그렇기에 단 한개라는 사실을 보증하기 위해선 private 생성자나 열거 타입을 통해 싱글턴을 만들어줘야 한다고 책은 설명하고 있다. 그런데 단 한개라는 사실을 보증해버리고 나면 단점이 존재하는데 유닛 테스트 시에 Mock 객체(가짜 객체)를 만들 수가 없을 수도 있기 떄문이다.(이미 만들어져있어서) 이러한 문제점의 해결을 위해 의존성 주입을 사용하곤 한다. 결론 사실 중요한 파트인지는 모르겠다. 스프링 개발을 하면서 싱글턴 패턴은 굉장히 개발자에게 밀접한 영역이며 상식지만 싱글턴 패턴을 실제 구현할 일은 없을 것 같다는 생각 때문이다. 그래서 싱글턴을 실제 실무에서 사용하고 있는지 찾아봤는데 그래봐야 이미 구축된 Runtime, 스프링 ..
[Item 2] 생성자에 매개변수가 많다면 빌더를 고려하라
빌더 패턴 @Builder public Member(String name, String email, String picture, Role role) { this.name = name; this.email = email; this.picture = picture; this.role = role; } Member.builder() .name(name) .email(email) .picture(picture) .role(role) .build(); 생성자에 @Builder를 걸면 아래와 같이 사용가능하다. 빌더 패턴은 점층적 생성자 패턴와 자바빈즈 패턴의 장점만을 따다 만든 패턴이다. 정적 팩토리 메소드나 생성자를 사용할 때 매개변수가 많다면 빌더 패턴을 이용하는 것이 좋다. 점층적 생성자 패턴과 자바빈즈 패..