본문 바로가기

전체 글48

Java | Comparable을 구현할지 고려하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심순서를 고려해야 하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야한다.compareTo 메서드에서 필드의 값을 비교할 때 연산자는 쓰지 않는다.그 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나 Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자. 이유compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있다는 것이 Object의 equals와 다른 점이다.compareTo 메서드의 일반 규약이 객체와 주어진 객체의 순.. 2024. 7. 4.
Java | clone 재정의는 주의해서 진행하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다.  핵심Cloneable이 몰고 온 모든 문제를 되짚어봤을 때, 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안 되며, 새로운 클래스도 이를 구현해서는 안 된다.final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 허용해야 한다.기본 원칙은 ‘복제 기능은 생성자와 팩터리를 이용하는 것이 최고’라는 것이다.단, 배열만은 clone 메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라 할 수 있다. 이유Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다.리.. 2024. 7. 4.
Java | toString을 항상 재정의하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다.toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야한다. 이유toString: “모든 하위 클래스에서 이 메서드를 재정의하라”toString은 유익한 정보를 담고 있고, 핵심을 직접 전달해야한다.{ Jenny=PhoneNumber@adbbd } 보다는 { Jenny=010-1234-5678 }로 오는 것이 더 반가운 것과 같은 이치이.. 2024. 7. 4.
Java | equals를 재정의하려거든 hashCode도 재정의하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다.재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야하며, 서로 다른 인스턴스라면 되도롣 해시코드도 서로 다르게 구현해야 한다. 이유equals를 클래스 모두에서 hashCode도 재정의해야한다.그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashSet이나 HashMap 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다.hashCode 일반 규약equals 비교에 사용되는 정보가 변경되지 않았다면.. 2024. 7. 4.
Java | equals는 일반 규약을 지켜 재정의하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심꼭 필요한 경우가 아니라면 equals를 재정의하지 말자. 많은 경우에 Object의 equals가 우리가 원하는 비교를 정확하게 수행해준다.재정의해야할 때는 IDE에게 맞기거나, 그 클래스의 핵심 필드를 모두 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다. 이유equals 메서드equals 메서드는 곳곳에 함정이 도사리고 있어서 자칫하면 끔찍한 결과를 초래한다.재정의 하지 않는 것이 최선이다.1. 각 인스턴스가 본질적으로 고유하다.값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스(Thread)Thread@Overridepublic boolean equals(Obje.. 2024. 7. 4.
Java | try-finally보다는 try-with-resources를 사용하라 (Effective Java 3/E - joshua bloch) 해당 글은 이펙티브 자바 (Effective Java 3/E - joshua bloch) 를 읽고 정리한 글입니다. 핵심꼭 회수해야 하는 자원을 다룰 때는 try-finally 말고, try-with-resources를 사용하자.예외는 없다. 코드는 더 짧고 분명해지고, 만들어지는 예외 정보도 훨씬 유용하다.try-finally로 작성하면 실용적이지 못할 만큼 코드가 지저분해지는 경우라도, try-with-resources로는 정확하고 쉽게 자원을 회수할 수 있다. 이유close를 여러번 호출하는 경우 try-finally의 문제점만약 close를 여러 번 호출해야 하는 상황이 오면 어떻게 될까?package effectivejava.chapter2.item9.tryfinally;import java.i.. 2024. 7. 4.