📂 JAVA/이펙티브 자바

clone 재정의는 주의해서 진행하라(2) - [3장. 모든 객체의 공통 메서드(아이템13)]

이전 글을 통해 불변 객체에서 clone을 사용하는 방법을 알아보았다. 이번에는 가변 객체에서 clone을 사용하는 방법을 알아보자. 가변 객체를 복제하는 3가지 방법을 살펴보자. 1. 배열 복사를 이용하는 경우 👨‍🚀 public class Stack implements Cloneable{ private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { this.elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { ensureCapacity(); elements[..

clone 재정의는 주의해서 진행하라(1) - [3장. 모든 객체의 공통 메서드(아이템13)]

이번 글에서는 clone을 재정의 할 때 어떤 점을 주의해서 재정의 해야 하는지 알아보고자 한다. clone의 기본적인 사용방법보다는 주의점에 초점이 맞춰져 있으므로 clone의 기본적인 사용방법을 알고 싶다면 이전 글을 참고하기 바란다. clone을 재정의할 때 크게 2가지 상황으로 구분할 수 있다. 첫 번째는 불변 객체에서의 clone이고 두 번째는 가변 객체에서의 clone이다. 먼저 불변 객체에 clone을 재정의할 때 주의점을 살펴보고, 다음 글을 통해 가변 객체에 clone을 재정의할 때 주의점을 살펴보도록 하자. 1. clone 규약 👩‍🌾 clone을 오버라이딩해서 우리가 만든 클래스에 재정의를 할 때 다음과 같은 조건(규약)을 만족하게 만들어야 한다. 아래의 3가지 규약을 기억하고 어떻게..

toString을 항상 재정의하라 - [3장. 모든 객체의 공통 메서드(아이템12)]

1. toString을 재정의 해야 하는 이유 🧃 1. Object의 toString 메서드의 기본 형식 Object의 기본 toString 메서드는 '클래스이름@16진수로 표시한 해쉬코드'를 반환해 준다. test.Test@15db9742이 하나의 예시이다. 이는 우리가 작성한 클래스에서 toString으로 반환받을 적절한 값의 형태가 아니다. 또한, Object.class에 정의된 toString을 살펴보면 아래의 내용을 확인할 수 있다. The result should be a concise but informative representation that is easy for a person to read. 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해라 It is recommended ..

equals를 재정의하려거든 hashCode도 재정의하라(2) - [3장. 모든 객체의 공통 메서드(아이템11)]

앞에서 살펴본 것처럼 좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시 코드를 반환한다. 이상적인 해시 함수는 주어진 (서로 다른) 인스턴스들을 32비트 정수 범위에 균일하게 분배해야 한다. 이상을 완벽하게 실현하기는 어렵지만 비슷하게 만들기는 그다지 어렵지 않다. 해당 글을 통해 해시 코드를 구현하는 4가지 방법과 주의 사항을 알아보자. 1. 전형적인 hashCode 구현 🥑 핵심 필드 중에 하나를 골라서 hashCode를 구한다. 기본 타입(primitive type) 필드라면 해당 타입의 hashCode라는 메서드를 사용해서 구하면 된다. (Type.hashCode(f)) 참조 타입(reference tyep) 필드라면 해당 타입의 hashCode를 호출해서 구한다. (Point라는 타입을 사용한..

equals를 재정의하려거든 hashCode도 재정의하라(1) - [3장. 모든 객체의 공통 메서드(아이템11)]

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. 다음은 Object 명세에서 발췌한 hashCode에 대한 규약이다. equals 비교에 사용되는 정보가 변경되지 않았다면 hashCode는 매번 같은 값을 리턴해야 한다. 정보가 변경되거나, 애플리케이션을 다시 실행했다면 값이 달라질 수 있다. 두 객체에 대한 equals가 같다면, hashCode의 값도 같아야 한다. 두 객체에 대한 equals가 다르더라도, hashCode의 값은 같을 수 있다. 하지만, 해시 테이블 성능을 고려해 다른 값을 리턴하는 것이 좋..

equals는 일반 규약을 지켜 재정의하라(3) - [3장. 모든 객체의 공통 메서드(아이템10)]

이번 글에서는 지금까지의 내용을 종합해서 양질의 equals 메서드 구현 방법과 주의 사항에 대해서 알아보고자 한다. 1. equals 구현 방법 == 연산자를 사용해 입력이 자기 자신의 참조인지 확인한다. instanceof 연산자로 입력이 올바른 타입인지 확인한다. 입력을 올바른 타입으로 형변환한다. 입력 객체와 자기 자신의 대응되는 '핵심' 필드들이 모두 일치하는지 하나씩 검사한다. float와 double을 제외한 기본 타입 필드는 == 연산자로 비교하고, 참조 타입 필드는 각각의 equals 메서드로, float과 double 필드는 각각 정적 메서드인 Float.compare(float, float)와 Double.compare(double, double)로 비교한다. (float와 doubl..

equals는 일반 규약을 지켜 재정의하라(2) - [3장. 모든 객체의 공통 메서드(아이템10)]

이번 글에서는 equals 메서드를 재정의할 때 반드시 지켜야 하는 일반 규약 5가지를 조금 더 자세히 알아보고자 한다. 1. 반사성(reflexivity) A.equals(A) == true 반사성은 단순히 말하면 객체는 자기 자신과 같아야 한다는 뜻이다. 이 요건은 일부러 어기는 경우가 아니라면 만족시키지 못하기가 더 어려워 보인다. 2. 대칭성(symmetry) A.equals(B) = B.equals(A) 대칭성은 두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다는 뜻이다. 대소문자를 구별하지 않는 문자열을 구현한 다음 클래스가 있다고 하자. public final class CaseInsensitiveString { private final String s; public CaseInsens..

equals는 일반 규약을 지켜 재정의하라(1) - [3장. 모든 객체의 공통 메서드(아이템10)]

꼭 필요한 경우가 아니면 equals를 재정의하지 말자. equlas 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있어서 자칫하면 끔찍한 결과를 초래하기 때문이다. 이번 글에서는 'equals를 재정의 하지 않아도 되는 4가지 상황'과 '만약 equals 재정의를 해야 한다면, 만족해야 하는 5가지 규약'에 대해서 알아볼 것이다. 1. 재정의 하지 않아도 되는 4가지 상황 🚩 1. 각 인스턴스가 본질적으로 고유한 경우 🌴 싱글톤, ENUM 등 각 인스턴스가 본질적으로 고유한 경우 equals를 재정의 하지 않아도 된다. 2. 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없는 경우 🌴 설계자가 논리적 동치성 방식을 원하지 않거나 애초에 필요하지 않다고 판단하는 경..

try-finally 보다는 try-with-resources를 사용하라 - [2장 객체 생성과 파괴(아이템9)]

전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 try-finally가 쓰였다. 하지만 아래의 2가지 문제점으로 인해 try-with-resources의 사용이 권장된다. 복수의 자원을 처리하게 되면 코드가 지저분해진다. 스택 추적 내역에 이전의 예외에 관한 정보는 남지 않게 되어, 실제 시스템에서의 디버깅을 몹시 어렵게 한다. try-with-resources의 장점들을 통해 해당 기능을 알아보자. 장점 1. 코드를 간결하게 작성할 수 있다. try-finally의 기본구조는 아래와 같다. static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(p..

finalizer와 cleaner 사용을 피하라 - [2장 객체 생성과 파괴(아이템8)]

자바는 finalizer와 cleaner라는 두 가지 객체 소멸자를 제공한다. 하지만 여러 가지 문제점으로 인해 사용이 자제된다. 해당 글에서 문제점들과 적절한 쓰임새에 대해서 알아보자. 📢문제점 1. finalizer와 cleaner는 즉시 수행된다는 보장이 없다. finalizer나 cleaner를 얼마나 신속히 수행할지는 전적으로 가비지 컬렉터 알고리즘에 달렸으며, 이는 가비지 컬렉터 구현마다 천차만별이다. finalizer나 cleaner 수행 시점에 의존하는 프로그램의 동작 또한 마찬가지다. 📢문제점 2. finalizer와 cleaner는 실행되지 않을 수도 있다. 이는 접근할 수 없는 일부 객체에 딸린 종료 작업을 전혀 수행하지 못한 채 프로그램이 중단될 수도 있다는 얘기다. 따라서 프로그램..

다 쓴 객체 참조를 해제하라 - [2장 객체 생성과 파괴(아이템7)]

자바에서는 가비지 컬렉터가 메모리 관리를 도와준다. 하지만 가비지, 컬렉터가 있다고 해도 메모리 누수가 발생하지 않는 것은 아니다. 이번 글에서는 다 쓴 객체 참조를 해제하여 메모리 누수를 방지할 수 있는 3가지 상황을 알아보고자 한다. 1. Stack에서의 메모리 누수 & 해결책 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){ ensureCapacity(); el..

불필요한 객체 생성을 피하라 - [2장 객체 생성과 파괴(아이템6)]

해당 장에서는 불필요하게 객체 생성을 하는 3가지 경우를 말해주고 있다. 하나씩 알아보자. 1. 문자열 public static void main(String[] args){ String hello1 = "hello"; String hello2 = new String("hello"); String hello3 = "hello"; System.out.println(hello1 == hello2); // false // 다른 인스턴스 System.out.println(hello1.equals(hello2)); // true // 같은 문자열 System.out.println(hello1 == hello3); // true // 같은 인스턴스 System.out.println(hello1.equals(hell..