전체 글
-
아이템11. equals를 재정의하려거든 hashCode도 재정의하라DevBook/Effective Java 2023. 5. 7. 12:57
📍상황 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 함 이유 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 됨 규약 문제가 되는 부분 hashCode를 잘못 재정의했을 때 문제가 되는 조항은 두 번째임 hashCode를 재정의하지 않으면 논리적 동치인 두 객체가 서로 다른 해시코드를 반환하여 두 번째 규약을 지키지 못함 --> 즉, 논리적으로 같은 객체는 같은 해시코드를 반환해야 함 예시 Map map = new HashMap(); map.put(new PhoneNumber(010, 1234, 5678), "java"); //PhoneNumber 클래스의 equals를 재정의했는데 hashC..
-
아이템10. equals는 일반 규약을 지켜 재정의하라DevBook/Effective Java 2023. 5. 6. 22:53
📍상황 Object 클래스의 equals() 메서드를 오버라이딩해야 하는 경우는 무엇일까? 오버라이딩을 할 때 지켜야 할 일반 규약은 무엇일까? 📍방법 ▶️ equals를 오버라이딩하지 않아도 되는 경우 오버라이딩하지 않으면 기본으로 그 클래스의 인스턴스는 오직 자기 자신과만 같게 됨 다음에서 열거한 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선임 1. 각 인스턴스가 본질적으로 고유함 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스가 여기 해당함 ex) Thread --> Object의 equals 메서드는 이러한 클래스에 딱 맞게 구현되었음 2. 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없음 인스턴스의 내부 값이 동일한지 검사하지 않아도 됨 3. 상위 클..
-
3장 - 모든 객체의 공통 메서드DevBook/Effective Java 2023. 5. 6. 21:17
📍학습할 내용 Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로는 상속해서 사용하도록 설계되었음 Object에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 오버라이딩을 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있음 따라서 Object를 상속하는 클래스, 즉 모든 클래스는 이 메서드들을 일반 규약에 맞게 재정의해야 함 메서드를 잘못 구현하면 대상 클래스가 이 규약을 준수한다고 가정하는 클래스(HashMap, HashSet 등)를 오동작하게 만들 수 있음 Comparable.compareTo의 경우 Object의 메서드는 아니지만 성격이 비슷하여 이번 장에서 함께 다룸
-
아이템9. try-finally보다는 try-with-resources를 사용하라DevBook/Effective Java 2023. 5. 6. 18:56
📍상황 자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 존재함 ex) InputStream, OutputStream, java.sql.Connection 이러한 자원 닫기는 클라이언트가 놓치기 쉬워 예측할 수 없는 성능 문제로 이어지기도 함 그렇다면 꼭 회수해야 하는 자원을 다룰 때는 어떻게 해야할까? 📍방법 1) try-finally 전통적으로 자원이 제대로 닫힘을 보장하는 수단 코드 9-1 try-finally - 더 이상 자원을 회수하는 최선의 방책이 아님 public class BadBufferedReader extends BufferedReader { public BadBufferedReader(Reader in, int sz) { super(in, sz); } publ..