[이펙티브 자바] 10. equals는 일반 규약을 지켜 재정의하라

1. 개념equals를 단순히 재정의 하는 것은 쉽지만 함정이 많다. 이번 장에서는 equals를 재정의 할 때 고려해야 하는 점과, 재정의가 완료된 후 확인해야 하는 부분들에 대해 다루고 있다.2. equals를 재정의하는 경우와 재정의하지 말아야 하는 경우2-1. equals를 재정의하지 말아야 할 경우각 인스턴스가 본질적으로 고유한 값을 표현하는 클래스: 예를 들어, Thread 클래스는 각 인스턴스가 고유한 ID를 가지므로 equals를 재정의할 필요가 없다.논리적 동치성 검사가 필요 없는 경우: 대부분의 경우 객체 식별성만 중요하며, 논리적 동치성은 필요하지 않을 수 있다.상위 클래스에서 재정의한 equals가 하위 클래스에 적절한 경우: 상위 클래스에서 이미 equals를 적절히 구현했고, 이..

• format_list_bulleted 이펙티브 자바
• · 2024. 6. 29.
• textsms

[이펙티브 자바] 9. try-finally 보다는 try-with-resources를 사용하라

1. 개념 자바 라이브러리에는 close 메서드를 직접 호출해서 닫아줘야 하는 자원이 많다. 대표적으로 InputStream, ouputStream java.sql.connection 등이 있으며 해당 자원들은 클라이언트에서 놓치기 쉬워 예측할 수 없는 성능 문제로 이어지곤 한다. 이중 상당 수가 finalizer를 안정망으로 사용하여 문제에 대비하고 있긴 하지만, 완전히 안전하다고 할 수 없다. (해당 내용은 다음 포스트에서 확인 가능) 2024.03.31 - [이펙티브 자바] - [이펙티브 자바] 8. finalizer와 cleaner 사용을 피하라 [이펙티브 자바] 8. finalizer 와 cleaner 사용을 피하라 1. finalizer와 cleaner란? finalizer와 cleaner는 ..

• format_list_bulleted 이펙티브 자바
• · 2024. 4. 6.
• textsms

[이펙티브 자바] 8. finalizer 와 cleaner 사용을 피하라

1. finalizer와 cleaner란? finalizer와 cleaner는 자바의 2가지 객체 소멸자이다. finalizer는 Object.finalize() 메서드를 오버라이딩 함으로써 사용된다. 작동 여부 및 시점을 예측할 수 없고 상황에 따라 위험할 수 있어 일반적으로 불필요하며, 기능의 잘못된 동작, 낮은 성능, 이식성 문제의 원인이 되기도 한다. 기본적으로는 사용하면 안 되고, 자바 9에서는 finalizer를 deprecated API로 지정하고, java.lang.ref.Cleaner 클래스를 사용하여 구현된 cleaner를 대안으로 제시하였으나, cleaner 또한 finalizer보다는 덜 위험 하지만 여전히 예측불가하고 성능이 좋지 않아 일반적으로 불필요하다. 2. 사용 시 문제점 ..

• format_list_bulleted 이펙티브 자바
• · 2024. 3. 31.
• textsms

[이펙티브 자바] 7. 다 쓴 객체 참조를 해제하라

1. 메모리 관리 자바에선 가비지 컬렉터가 다 쓴 객체를 알아서 회수해 가기에 편리하고 효율적으로 메모리를 관리할 수 있다. 하지만 메모리 관리에 신경 쓰지 않아도 된다는 말은 절대 아니다. 메모리를 적절하게 관리하지 못하면 메모리 누수가 발생하고 심하면 프로그램이 종료될 수 있다. 메모리를 적절하게 관리하지 못하는 경우의 예제를 살펴보자. 다음은 스택을 간단하게 구현한 자바 코드이다. 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..

• format_list_bulleted 이펙티브 자바
• · 2024. 3. 27.
• textsms

[이펙티브 자바] 6. 불필요한 객체 생성을 피하라

1. 객체의 재사용 똑같은 객체를 매번 새로 생성하는 것보다 하나를 생성 후 재사용하는 것이 훨씬 효율적이다. 특히 불변 객체는 언제든 재사용이 가능하다. 다음은 객체 생성 시 사용하면 안 되는 극단적인 예이다. String s = new String("bikini"); 보기만 해도 불편한 이 생성방식은 실행될 때마다 String 객체를 새로 생성한다. 이후에 기능적으로는 동일하게 사용되지만 큰 반복문이나 자주 호출되는 메서드 안에 있다면 쓸모없는 인스턴스가 여러 개 생성될 것이다. 개선된 객체 생성 방식을 확인해 보자. String s = "bikini"; 이제 익숙한 String 객체 선언 방식이 되었다. 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스 사용하는 방식으로, 이 방식을..

• format_list_bulleted 이펙티브 자바
• · 2024. 3. 26.
• textsms

[이펙티브 자바] 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

1. 개념 한 클래스 내에서 여러 개의 자원에 의존하여 사용되는 경우에 의존 객체 주입을 통해 유연성과 테스트 용이성을 개선하는 내용이다. 스프링의 의존성 주입 개념을 생각해 본다면 이미 당연하게 사용하고 있는 경우가 많을 것이지만, 의존 객체 주입의 장점을 다시 한번 생각해 볼 수 있는 내용이다. 2023.11.06 - [Spring] - [Spring] IoC(제어의 역전) & DI(의존성 주입)의 개념 [Spring] IoC(제어의 역전) & DI(의존성 주입)의 개념 1. IoC (Inversion of Control) 제어의 역전 IoC란 메인 프로그램에서 컨테이너나 프레임워크로 객체와 객체의 의존성에 대한 제어를 넘기는 것을 말한다. 프레임워크 없이 개발할 때는 각 객체에 대한 junhkang..

• format_list_bulleted 이펙티브 자바
• · 2024. 3. 25.
• textsms