전체 글
[Item 6] 불필요한 객체 생성을 피하라
스프링 컨테이너는 기본적으로 싱글톤 패턴이기 때문에 불필요한 객체 생성을 피하도록 구현되어 있다. 다만 개발자가 임의적으로 만드는 bean이 아닌 클래스에서는 싱글톤임을 보증하지 못하는 클래스로 구현할 때가 많은데 이런 부분은 클라이언트 쓰레드마다 무분별하게 객체 생성이 이루어진다(자바 엔터프라이즈 개발에서 스프링 프레임워크가 만들어진 이유이기도 하다.) 한번 쓰고 버려진 객체들은 가비지 컬렉션 대상이 된다. public class RomanNumerals{ private static final Pattern ROMAN = Pattern.compile("^(?=[MDCLXVI])M*D?C{0,4}L?X{0,4}V?I{0,4}$"); public static boolean isRomanNumeral(Str..
[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, 스프링 ..