공부하는 개발자

짧은 코멘트 당연히 try with resources를 사용해야 한다. JDK 7부터 try with resources를 사용할 수 있게 되었는데 혹시 프로젝트가 JDK 6이라면.... (와.. AWS AMI에서 JDK8도 사라지고 JDK11을 권장하고 있는데, JDK 6이요..?) 다른회사로 도망쳐야 한다 try-finally 보다는 try-with-resources를 사용하라 자바 라이브러리에는 close 메소드를 호출하여 직접 닫아줘야 하는 자원이 많다. (ex. InputStream, OutputStream, java.sql.Connection) 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다 전통적으로 자원 닫힘을 보장하는 수단으로는 try - finally가..

짧은 코멘트 실제로 사용해본적이 없다. ThreadPoolExecutor가 finalizer 역할을 제공한다고 되어 있지만 JDK 버전에 따라 다른 모습을 보여준다. (모든 버전을 확인해본 것은 아니지만, 9버전부터 아무것도 하지 않게 변경된 것 같다. // Override without "throws Throwable" for compatibility with subclasses // whose finalize method invokes super.finalize() (as is recommended). // Before JDK 11, finalize() had a non-empty method body. /** * @implNote Previous versions of this class had a ..

짧은 코멘트 다 쓴 객체의 참조를 해제하지 않아 메모리 문제가 된적은 아직까지 경험해보지 못했다. 하지만 OOM이 발생한 적은 몇 번 존재했는데, OOM 발생시 heap dump를 뜨게 해둔 옵션이 OOM을 해결하는데 큰 도움을 주었다. JAVA 개발자라면 head dump 를 연습삼아 한 번 씩 떠보는 것도 좋아 보인다. 다 쓴 객체의 참조를 해제하라 다음 Stack 코드에서 이상한 부분을 발견할 수 있는가? public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[D..

짧은 코멘트 의존성 주입은 정말 중요한 개념으로, 스프링을 사용하는 개발자라면 누구나 의존성 주입을 활용하고 있다. 의존성을 주입을 적절하게 함으로써, 하위 구현체를 갈아 끼울 수가 있고 테스트도 아름답게 작성할 수가 있는데... 의존성은 나중에 찐하게 한 번 다뤄봐야 겠다 ㅎㅎ 자원을 직접 명시하지 말고 의존 객체 주입을 사용해라 사용하는 자원에 따라 동작이 달라지는 클래스는 정적 유틸리티 클래스나 싱글톤 방식이 적합하지 않다 예를 들어, 맞춤법 검사기가(SpellChecker) 안에 어휘사전(Lexicon)을 가지고 있다고 하자 정적 유틸리티 클래스로 구현 public class SpellChecker { private static final Lexicon dictionary = ...; privat..

짧은 코멘트 유틸성 클래스에 private 생성자가 없으면 '엇 이 개발자분 Effective Java 안읽으셨나?' 라는 생각이 가장 먼저 든다 ㅋㅋㅋ 클래스 본문의 길이를 줄이고 싶어, lombok의 NoArgsConstructor(accessLevel = AccessLevel.PRIVATE)을 사용하는 것을 개인적으로 선호한다 ㅎㅎ 인스턴스화를 막고 싶을 때는 private 생성자를 사용하면 된다 단순히 정적 메소드와 정적 필드만을 담은 클래스를 만들고 싶다면, 그리 곱게 보이지는 않지만 아래의 경우에 쓸모가 있다 기본값이나 관련 메소드들을 모아 놓을 때 (ex. java.util.Arrays, java.lang.Math) 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메소드를 모아 놓을 때 f..

짧은 코멘트 Spring Bean의 기본 scope이기도 한 싱글톤 알아두면 유용하다. Spring을 사용할 경우 객체를 직접 싱글톤으로 만들 일을 드물지만, 정말 간혹 쓰는 경우가 있다. 그럴때는 주로 2번의 방법을 사용했다. 싱글톤 보증 싱글톤 : 인스턴스를 오직 하나만 생성할 수 있는 클래스 (GOF) 함수와 같은 무상태 객체나 설계상 유일해야 하는 시스템 컴포넌트가 싱글톤의 예이다. 클래스를 싱글톤으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다 싱글톤을 만드는 방법과 장단점은 아래와 같다 방법 1 생성자는 private으로 감춰두고, 인스턴스를 만들 수 있는 유일한 수단으로 public static 멤버를 하나 만들어 둔다. public class Elvis { // fina..

짧은 코멘트 빌더 역시 굉장히 많이 사용하는 패턴이다. 점층적 생성자 패턴과 자바빈즈 패턴은 요즘 코드에서 찾아볼 수 없다. lombok의 @Builder를 사용하여 쉽게 구현할 수 있으며, accessLevel 역시 조정할 수 있다. lombok의 @Builder를 이용해 빌더를 여러개 만들때 빌더 클래스와 메소드 이름을 적절히 조정해줄 필요가 있다. 그렇지 않으면, 오류가 날 수 있는데 빌더 클래스가 동일한 이름으로 2개 이상 존재하기 때문이다. 빌더 정적 팩토리 메소드(이하 정적 팩토리)와 생성자에는 똑같은 제약이 하나 있다. 선택적 매개변수가 많을 때 적절히 대응하기 어렵다는 점이다. 이를 해결하기 위해서 점층적 생성자 패턴(telescoping constructor pattern)을 즐겨 사용했..

짧은 코멘트 개인적으로 굉장히 애용하는 정적 팩토리 메소드이다 ㅎㅎ lombok에서 @RequiredArgsConstructor 와 같은 어노테이션과 함께 staticName을 제공해주는데, 이는 자동으로 정적 팩토리 메소드를 만들어 주는 것이다. 이와 관련해 팀내 개발자 분들과 의견 교환을 해봤을때는 이를 사용하기는 애매하다는 의견이 다수였다. 꼭 필요한 필드들만 설정하거나 final을 쓰지 못할 이유가 있거나 등등의 어려움이 있기 때문이었다. 어떤 사람은 new Person() 보다 Person.of()가 깔끔해보인다는 이유로 정적 팩토리 메소드를 사용하는 경우도 있다. 나 역시 간혹 그럴 때가 있는데, 이보다 더 좋은 방법은 프로젝트를 구성하는 개발자들이 모여, 어떤 경우에 new를 이용한 객체 생..