반응형 이펙티브자바17 [아이템12] toString을 항상 재정의하라 이 내용은 이펙티브 자바 Effective Java 3/E 를 읽으면서 정리한 내용을 포함하고 있습니다. 객체의 기본 toString 메서드는 적합한 문자열을 반환하는 경우는 거의 없습니다. toString 재정의 필요한 이유 아래 PhoneNumber 객체는 toString 을 재정의하지 않았습니다. 즉 기본 toString을 호출하도록 되어 있습니다. PhoneNumber phoneNumber = PhoneNumber.of(707, 867, 5309); System.out.println("phoneNumber : " + phoneNumber);결과는 다음과 같습니다. phoneNumber : item11.domain.PhoneNumber@b501c phoneNumber의 어떠한 값이 있는지 알아보기가.. 2022. 9. 18. [아이템11] equals를 재정의하려거든 hashCode도 재정의하라 이 내용은 이펙티브 자바 Effective Java 3/E 를 읽으면서 정리한 내용을 포함하고 있습니다. equals 를 재정의한 클래스 모두에서 hashCode 도 재정의해야 합니다. 그렇지 않게 되면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap 이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으키게 됩니다. Object 명세 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 합니다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없습니다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode.. 2022. 9. 18. [아이템10] equals는 일반 규약을 지켜 재정의하라 이 내용은 이펙티브 자바 Effective Java 3/E 를 읽으면서 정리한 내용을 포함하고 있습니다. equals 메소드는 재정의하기 쉬워 보이지만 잘못 수정하게 된다면 자칫하면 끔직한 결과를 초래할 수 있습니다. 재정의 다음에 열거한 상황 중 하나에 해당된다면 재정의하지 않는 것이 최선입니다. 각 인스턴스가 본질적으로 고유하다 인스턴스의 논리적 동치성 을 검사할 일이 없다 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다 그럼, 재정의해야 할 때는 언제일까요? 객체 식별성이 아니라 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지.. 2022. 9. 18. [아이템9] try-finally 보다는 try-with-resources 이 내용은 이펙티브 자바 Effective Java 3/E 를 읽으면서 정리한 내용을 포함하고 있습니다 자바 라이브러리에는 close 메소드를 호출해 직접 닫아줘야 하는 자원들이 있습니다. InputStream, OutputStream, Connection 등이 좋은 예입니다. 이러한 자원 닫기는 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 합니다. 이러한 자원 중 상당수가 안전망으로 finalizer를 활용하고 있지만 그것은 믿을만 하지 못합니다. 전통적으로는 자원이 제대로 닫힘을 보장하는 방법으로 try-finally 를 사용하였습니다. static String firstLineOfFile(String path) throws IOException { BufferedReader br = new.. 2022. 9. 3. [아이템8] finalizer와 cleaner 사용을 피하라 이 내용은 이펙티브 자바 Effective Java 3/E 를 읽으면서 정리한 내용을 포함하고 있습니다. Finalizer는 예측 불가능하고, 위험하며, 대부분 불필요합니다. 그걸 쓰면 이상하게 동작하기도 하고, 성능도 안좋아지고, 이식성에도 문제가 생길 수 있습니다. 딱 두가지 경우 안전망 역할로 자원을 반납하고자 하는 경우. 네이티브 리소스를 정리해야 하는 경우. 일단 자바 9에서는 Finalizer가 deprecated 됐으면 Cleaner라는게 새로 생겨서 Finalizer 보다 덜 위험하지만(별도의 쓰레드를 사용하니까), 여전히 예측 불가능하며, 느리고, 일반적으로 불필요합니다. 단점 1 언제 실행될지 알 수 없습니다. 어떤 객체가 더이상 필요 없어진 시점에 그 즉시 finalizer 또는 cl.. 2022. 9. 3. [아이템7] 다 쓴 객체 참조를 해제하라 이 내용은 이펙티브 자바 Effective Java 3/E 를 읽으면서 정리한 내용을 포함하고 있습니다. 자바는 가비지 컬렉터를 통해서 다 쓴 객체를 회수해 갑니다. 하지만 이러한 장점으로 인하여 자칫 메모리 관리에 더 이상 신경쓰지 않아도 된다고 오해할 수 있습니다. 스택을 간단히 구현한 다음 코드를 보도록 하겠습니다. 스택 코드 // Can you spot the "memory leak"? public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { this.elements = new Object[DEFAUL.. 2022. 9. 3. 이전 1 2 3 다음 반응형