자기 개발

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 9. try-finally보다는 try-with-resources를 사용하라 자바 라이브러리에는 close메서드를 호출해 직접 닫아줘야 하는 자원이 있다. ex) InputStream, OutputStream, java.sql.Connection 직접 닫아주는 방법은 아래와 같다. (finalizer는 믿을만하지 않기 때문에 언급하지 않음. 이전 포스팅 참고) 1. try-finally 자원이 하나인 코드에서의 try-finally 코드는 나쁘지 않지만 자원이 두 개 이상부터는 지저분해지기 시작한다. 또한, 두 번째 예외가 첫 번째 예외를 집어삼킬 가능성이 있다. → 스택 추적 내역에 첫 번째 예외의 정보..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 8. finalizer와 cleaner 사용을 피하라 자바는 finalizer와 cleaner라는 두 가지 객체 소멸자를 제공한다. 이 두 가지 객체 소멸자 모두 일반적으로 불필요하다. - finalizer : 예측할 수 없고, 상황에 따라 위험할 수 있다. - cleaner : finalizer보다는 덜 위험하지만 여전히 예측할 수 없고 느리다. 1. finalizer와 clenaer의 단점 1. finalizer와 cleaner는 즉시 수행된다는 보장이 없기 때문에 제때 실행되어야 하는 작업은 절대 할 수 없다. ex) 파일 닫기를 finalizer, cleaner에 맡기면 중대한 오류를 일으킬 수 있..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 7. 다 쓴 객체 참조를 해제하라 C/C++ 과는 다르게 Java는 GC(Garbage Collector)를 갖추고 있기 때문에 다 쓴 객체를 알아서 회수한다. 하지만, GC가 있다고 해서 메모리 관리에 신경쓰지 않아도 되는 것은 아니다. 1. Stack 스택을 간단히 구현하면 아래와 같다. 1) 메모리 누수가 발생하는 코드 기능적으로는 전혀 문제가 없음 메모리 누수가 발생함 스택이 커졌다가 줄어들었을 때, 스택에서 꺼내진 객체들을 GC가 회수하지 않음 스택에서 꺼내진 객체들은 스택에서 여전히 해당 객체들을 바라보고 있기 때문 (이를 '다 쓴 참조(obsolete reference)' 라고 함) 다 쓴 참..

- 알고리즘 분류 : 트리 - 사용 언어 : JAVA 소스 설명은 주석을 참고해주세요. import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.util.LinkedList; import java.util.Queue; // Link : https://www.acmicpc.net/problem/9934 // 참고로 처음에 Node의 value 타입을 char로 줬었는데, 노드의 depth가 4 이상이 넘어가는 경우 10의 자리가 될 수 있기 때문에 char로 하면 안됨. int로 수정함 public class Main { public static int K; public sta..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 6. 불필요한 객체 생성을 피하라 - 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 빠르고 세련된 경우가 많다. - 불변 객체(String)는 언제든 재사용할 수 있다. (불변 객체라면 재사용해도 안전함이 명백함) - 생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성 피할 수 있다. → Boolean(String) 생성자 대신, Boolean.valueOf(String) 팩터리 메서드를 사용하는 것이 좋음(생성자는 새로운 객체를 만들기 때문) 1. String 1) String 선언의 나쁜 예 실행될 때마다 새로운 Strin..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 클래스에서 하나 이상의 자원에 의존을 할 때, 이를 구현하는 방법 중 잘못된 예가 있다. SpellChecker 라는 클래스가 사전에 의존한다고 가정해보자. 1) 정적 유틸리티를 잘못 사용 public class SpellChecker { private static final Lexicon dictionary = ...;// 의존 대상(사전) private SpellChecker() { }// private 생성자를 정의함으로써 객체 생성 방지 ... } 2) 싱글톤을 잘못 사용 public class SpellChecker { private fi..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라 단순히 정적 메서드와 정적 필드만을 담은 클래스를 만들 때가 있다. 예를 들어 java.lang.Math 와 java.util.Arrays처럼 기본 타입 값이나 배열 관련 메서드들을 모아둘 수 있다. 또, final 클래스와 관련한 메서드들을 모아놓을 때도 사용한다. 이러한 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 것은 아니기에 인스턴스화를 막아야 할 필요가 있다. 클래스를 정의할 때 생성자를 따로 명시해주지 않으면 컴파일러가 자동으로 기본 생성자를 생성한다. 이 때 자동으로 생성되는 기본 생성자는 매개변수를 받지 않는..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보장하라. 싱글턴 인스턴스를 오직 하나만 생성할 수 있는 클래스 싱글턴을 생성하는 방법 1. public static final field 방식 private 생성자는 public static final 필드인 Earth.INSTANCE를 초기화할 때 한 번만 호출하는 방식 public 이나 protected 생성자가 없으므로 Earth 클래스가 초기화될 때 만들어진 인스턴스 뿐이라는 것이 보장 장점 해당 클래스가 싱글턴임이 API에 명백히 드러남(public 필드 방식이기 때문) 코드의 간결함 예외) 권한이 있는 클라이언트는 리플렉션 API인 Acce..