책 정리17 [이펙티브 자바] 박싱된 기본 타입보다는 기본 타입을 사용하라 - item 61 박싱 타입 (Boxing type) 식별성을 가짐 같은 값을 가져도 다르다고 판단될 수 있음 필자) Wrapper class라고도 불리며 primitive type을 Wrapping한 클래스입니다 ex) Integer, Long @Test @DisplayName("Boxing된 기본 타입은 같은 값을 가져도 다르다고 판단될 수 있다") void test() { assertThat(new Integer(42) == new Integer(42)).isFalse(); } 필자) 간단한 테스트를 돌려봤습니다. ==는 내부에 동작된 equals가 동작하지 않고 주소값을 비교하기 때문에 같지 않다고 판단됩니다. //in Integer.class public boolean equals(Object obj) { if .. 2023. 7. 24. [이펙티브 자바] toString을 항상 재정의하라 - item 12 toString의 일반 규약 "간결하면서 사람이 읽기 쉬운 형태의 유익한 정보"를 반환해야한다. 모든 하위 클래스가 이 메서드를 재정의하는 것이 좋다. 구현의 장점 toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁다. 그 클래스를 사용한 시스템은 디버깅하기 쉽다. 해당 클래스를 직접 호출하지 않더라도 다른 어딘가에서 쓰인다 (printf, 문자열 +연산, assert 등) 실제 구현 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다 포맷 명시에 대하여 장점 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다 그 값 그대로 입출력에 사용하거나 csv 파일 등으로 저장할 수 있다. 포맷에 맞는 문자열 객체를 상호 변환할 수 있는 정적 팩토리 메서드를 제공하는 것이 좋다 단점 포맷을 한번 .. 2023. 6. 29. [이펙티브 자바] equals를 재정의하려거든 hashCode도 재정의하라 - item 11 equals를 재정의한 클래스 모두에서 hashCode도 재정의 해야한다 hashCode의 일반 규약을 어긴다면 HashMap, HashSet 등 컬렉션에서 문제를 일으킬 수 있다. Object class에 명세된 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대.. 2023. 6. 29. [이펙티브 자바] equals는 일반 규약을 지켜 재정의하라 - item 10 equlas 메서드 재정의를 조심해야한다 다음과 같은 상황이 아니라면 재정의하지 않는 것이 최선이다 각 인스턴스가 본질적으로 고유하다 인스턴스의 '논리적 동치성'을 검사할 일이 없다 상위 클래스에서 재정의한 equals가 하위 클래스에서도 딱 들어맞는다 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다 equlas를 호출할 일이 없다면 아래처럼 구현한다 @Override public boolean equals(Object o) { throw new AssertionError(); // 호출 금지~! } equals 재정의가 필요할 때는? 아래 사항을 만족해야한다 논리적 동치성을 확인해야할 때 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의 .. 2023. 6. 23. [이펙티브 자바] try-finally보다는 try-with-resources를 사용하라 - item 9 try-finalizer의 문제점 첫번째 예외가 덮어써지는 문제 static String sfirstLineOfFile(String path) IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } try 문 안의 readLine이 예외를 던지고 br.close가 예외를 던지면 readLine의 의 예외가 br.close의 예외에 덮어씌워짐 첫 번쨰 예외에 관한 정보가 남지 않게 되어 디버깅을 어렵게 만듬 둘 이상의 try-finally가 사용 시 코드의 가독성 문제 void method() { try { try{ ... } .. 2023. 6. 22. [이펙티브 자바] finalizer와 cleaner 사용을 피하라 - item 8 finalizer란? Object 클래스에서 제공하는 finalize() Method이며 자바 9 버전 이후로 Deprecated 되었습니다. 해당 메서드를 Override하여 사용하는데 가비지 컬렉터가 해당 인스턴스를 회수하기 전에 호출합니다. finalizer의 문제점 위의 상황이 문제가 될 수 있는데 GC가 언제 회수를 할지 알 수 없습니다. 즉, finalizer와 cleaner로는 제 때 실행되어야 하는 작업은 절대 할 수 없습니다. ex) 시스템이 열 수 있는 파일 개수가 한정되어 있는 경우 이펙티브 자바의 저자는 "예측할 수 없고 상황에 따라 위험할 수 있어 일반적으로 불필요하다" 라고 언급합니다. finalizer 스레드는 우선순위가 낮아 실행이 지연될 수 있습니다. 심각한 성능 문제 fi.. 2023. 6. 22. 이전 1 2 3 다음
