Study
-
모든 객체의 공통 메서드 - 아이템 13. clone 재정의는 주의해서 진행하라Study/Effective Java 2022. 12. 15. 13:55
clone 재정의는 주의해서 진행하라 개요 Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스지만, 의도한 목적을 제대로 이루지 못했다. 가장 큰 문제는 clone() 메서드가 선언된 곳이 Cloneable이 아닌 Object이고, 그마저도 protected라는 데 있다. 따라서, Cloneable을 구현하는 것만으로는 외부 객체에서 clone() 메서드를 호출할 수 없다. 리플렉션을 사용하면 가능하지만, 100% 성공하는 것도 아니다. 해당 객체가 접근이 허용된 clone() 메서드를 제공한다는 보장이 없기 때문이다. 하지만, 이를 포함한 여러 문제점에도 불구하고 Cloneable 방식은 널리 쓰이고 있어서 잘 알아두는 것이 좋다. 이번 게시글에서는 clone() 메서드를 잘..
-
모든 객체의 공통 메서드 - 아이템 12. toString을 항상 재정의하라Study/Effective Java 2022. 12. 14. 14:38
toString을 항상 재정의하라 toString을 재정의해야 하는 이유 1. toString() 메서드를 재정의하지 않은 클래스에서는 적합한 문자열을 반환하지 않는다. 2. toString() 메서드를 재정의하지 않은 경우 "User@2d363fb3"와 같이 "클래스_이름@16진수로_표시한_해시코드"를 반환한다. 3. "User{name='홍길동'}"과 같이 객체의 정보를 직접 알려주는 형태가 훨씬 유익하다. 4. toString() 메서드를 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 해당 클래스를 사용한 시스템은 디버깅에 용이하다. 5. 직접 호출하지 않더라도 println(), printf(), 문자열 연결 연산자(+), assert 구문에 넘길 때 혹은 디버거가 객체를 출력할 때 등 자동으로 불..
-
모든 객체의 공통 메서드 - 아이템 11. equals를 재정의하려거든 hashCode도 재정의하라Study/Effective Java 2022. 12. 14. 11:29
equals를 재정의하려거든 hashCode도 재정의하라 equals() 메서드를 재정의한 클래스는 hashCode() 메서드고 재정의해야 한다. 그렇지 않으면, hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. hashCode 일반 규약 Object 명세에서 발췌한 내용에 따르면 hashCode의 규약은 아래와 같다. 1. equals() 메서드 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode() 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. 2. equals() 메..
-
모든 객체의 공통 메서드 - 아이템 10. equals는 일반 규약을 지켜 재정의하라Study/Effective Java 2022. 12. 13. 17:16
equals는 일반 규약을 지켜 재정의하라 equals를 재정의하면 안 되는 경우 1. 각 인스턴스가 본질적으로 고유한 경우 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스가 여기에 해당한다. Thread가 좋은 예로, Object의 equals() 메서드는 이러한 클래스에 딱 맞게 구현되었다. 2. 인스턴스의 '논리적 동치성'을 검사할 일이 없는 경우 public class Main { public static void main(String[] args) { final Pattern p01 = Pattern.compile("//.*"); final Pattern p02 = Pattern.compile("//.*"); System.out.println(p01.equals(p02)); // fal..
-
객체의 생성과 파괴 - 아이템 9. try-finally보다는 try-with-resource를 사용하라Study/Effective Java 2022. 12. 13. 14:07
try-finally보다는 try-with-resource를 사용하라 try-finally 문제점 자바 라이브러리에는 close() 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. InputStream, OutputStream, java.sql.Connection 등이 그 예이다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 문제로 이어지기도 한다. static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } 위 코드는 Buffer..
-
객체 생성과 파괴 - 아이템 8. finalizer와 cleaner 사용을 피하라Study/Effective Java 2022. 12. 13. 11:09
finalizer와 cleaner 사용을 피하라 사용하지 말아야 하는 이유 Java에서 제공하는 두 가지 객체 소멸자인 finalize와 cleaner는 기본적으로 쓰지 말아야 한다. 사용하지 말아야 하는 이유는 다음과 같다. 1. finalizer : 예측할 수 없고, 위험하며, 느리고, 일반적으로 불필요하다. 2. cleaner : finalizer보다는 덜 위험하지만 여전히 예측할 수 없고, 느리며, 보통을 불필요하다. 좀 더 구체적으로 살펴보도록 하겠다. 단점 1. 즉시 수행된다는 보장이 없다. finalizer와 cleaner는 즉시 수행된다는 보장이 없다. 즉, finalizer와 cleaner로는 제때 실행되어야 하는 작업을 절대 할 수 없다. finalizer와 cleaner의 수행 속도는..