Study

Study/이펙티브 자바

[Effective Java 3E] toString을 항상 재정의하라

💥 개요 Object의 기본 메서드는 적합한 문자열을 반환하는 경우가 거의 없습니다. PhoneNumber@abddb 처럼 [클래스명@16진수로_표현한_해시코드]를 반환합니다. 읽기 불편하고,무슨 정보인지 클라이언트는 확인하기가 힘듭니다. 💡 toString 생성시 주의점 toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅 하기가 쉽다. toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불립니다. 하지만 재정의를 하지 않는다면 그다지 쓸모없는 메시지가 출력될 것 입니다. map 객체를 출력할 때 System.out.println(phoneNumber..

Study/이펙티브 자바

[Effective Java 3E] equals를 재작성하려거든 hashcode도 재정의하라

💥 개요 equals를 재정의한 클래스 모두에서 hashcode도 재정의해야 합니다. 그렇지 않으면 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으키게 됩니다. 다음은 Object 명세에서 발췌한 규약입니다. - equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션이 다시 실행한다면 이 값이 달라져도 상관없다. - equals가 두 객체를 다르다고 판단했다면, 두 객체의 hashcode는 똑같은 값을 반환해야 한다. - equals가 두 객체를 다르다고 판단했더라도, 두 객체의 hashcode가 서로 다른 값을..

Study/이펙티브 자바

[Effective Java 3E] equals는 일반 규약을 지켜 재정의하라

💥 개요 equals 메서드는 재정의하기 쉬워 보이지만, 곳곳에 함정이 있습니다. 문제를 피하는 방법은 재정의하지 않는것이고, 아래와 같은 상황 중 하나에 해당한다면 재정의하지 않는것이 좋습니다. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스(예를 들어 Thread) equals는 이미 이 객체에 딱 맞게 구현되어 재정의 할 필요가 없습니다. 인스턴스의 논리적 동치성(logical equality)를 검사할 일이 없다. java.util.regex.Pattern은 equals를 재정의해서 두 Pattern의 인스턴스가 같은 정규표현식을 나타내는지(논리적 동치성)를 검사하는 방법도 있습니다. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다...

Study/이펙티브 자바

[Effective Java 3E] try-finally 보다는 try-with-resources를 사용하라

💥 개요 자바 라이브러리에는 close 메서드를 호출, 명시적으로 close를 해야하는 경우가 많습니다. InputStream, OutputStream, Connection 등이 대표적으로 있습니다. close를 하지 않으면 예측할 수 없는 성능 문제로 이어지기도 합니다. 이런 자원 중 상당수가 안전망으로 finalizer를 활용하고 있긴 하지만 그리 믿음직하지 못합니다. 전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 예외가 발생하거나, 메서드에서 반환하는 경우를 포함해서 try-finally가 사용됐습니다. 위 예시를 보면 왼쪽에서 하나의 자원을 사용하는 경우는 그나마 괜찮지만, 2개 이상의 자원을 close해야 하는 경우에는 가독성이 좋지않고, 코드가 지저분해 보입니다. 그리고 기기에 문제가 생긴..

Study/이펙티브 자바

[Effective Java 3E] finalizer와 cleaner 사용을 피하라

💥 개요 자바에서는 2가지 객체 소멸자를 제공합니다. 그중 finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요합니다.(앞으로 개발하면서 쓸 일이 없을지도...) 심지어 자바9에서 deprecated API 로 지정되었고, 그 대안으로 cleaner를 제시했지만, cleaner 역시 위험하고, 예측할 수 없고, 느리고, 불필요합니다. 🩻 문제 언제 수행될지 모른다 finalizer와 cleaner는 즉시 수행된다는 보장이 없습니다. 객체에 접근할 수 없게 된 후 finalizer와 cleaner로는 제때 실행되야 하는 작업은 절대 할 수없습니다.(파일, db처럼 사용 후 즉시 반납되어야 하는 자원에 절대 사용X) finalizer와 cleaner가 언제 수행될지는 전적으로 ..

Study/이펙티브 자바

[Effective Java 3E] 다 쓴 객체 참조를 해제하라

💥 개요 C나 C++처럼 메모리를 직접 관리해야 하는 언어를 쓰다, 자바를 사용하면 가비지 컬렉터로 인해 훨씬 편안하게 메모리를 관리 할 수 있습니다. 다 쓴 객체를 GC가 알아서 회수해가니까 이런일이 가능합니다. 하지만 메모리 관리를 더 이상 하지 않아도 된다고 오해할 수 있는데, 절대 사실이 아닙니다. public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { ens..

Study/이펙티브 자바

[Effective Java 3E] 불필요한 객체 생성을 피하라

💥 개요 똑같은 기능의 객체를 매번 생성하기 보다, 객체 하나를 재 사용하는게 더 나을때가 많습니다. 재사용은 빠르고 세련됐고 불변 객체는 언제든 재사용이 가능합니다. 하지만 아래와 같은 코드는 엄청난 문제가 발생합니다. String s = new String("bikini"); 이 문장은 실행될 때마다 String 인스턴스를 새로 만듭니다. 하지만 아래의 코드는 새로운 인스턴스를 만드는 대신 하나의 String 인스턴스를 사용합니다. 자바는 문자열을 직접 할당할 시 문자열 상수 풀 내부에 모든값을 저장하기 때문에 같은 가상 머신 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장됩니다. String s="bikini"; 👍 정적 팩터리를 제공하는 불변 클래스 정적 팩터..

Study/이펙티브 자바

[Effective Java 3E] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

💥 개요 많은 클래스가 하나 이상의 자원에 의존합니다. 가령 맞춤법 검사기는 사전(dic-tionary)에 의존하는데, 이런 클래스를 정적 유틸리티 클래스로 구현한 모습을 드물지 않게 볼 수 있습니다. 1. 정적 유틸리티 클래스 public class SpellChecker { private static final Lexicon dictionary = ...; private SpellChecker() {} public static boolean isVaild(String word) {...} public static List suggestions(String typo) {...} } 2. 싱글턴 public class SpellChecker { private final Lexicon dictionary ..

mntdev
'Study' 카테고리의 글 목록 (6 Page)