독서
-
Item 16: In public classes, use accessor methods, not public fields독서/Effective Java 2021. 12. 19. 00:06
public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라. public 가변 필드 사용 클래스의 데이터 필드에 직접적으로 접근할 수 있어서, 캡슐화의 장점이 무색해진다. // 쓰면 안되는 방법 class Point { public double x; public double y; } // 어디서 많이 본 스타일인데... @Slf4j class PointTest { @Test @DisplayName("이렇게 쓰지 마세요") void publicPointTest(){ Point point = new Point(); point.x = 0.01; point.y = 0.01; log.info("x:{}, y:{}", point.x, point.y); } } 쓰지 말아야 하는 이유 클래스의 데이터 ..
-
Item 15: Minimize the accessibility of classes and members독서/Effective Java 2021. 12. 18. 21:01
클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 구성 요소와 잘못 설계된 구성 요소를 구별하는 가장 중요한 차이점은 구성 요소가 내부 데이터 및 기타 구현 세부 정보를 다른 구성 요소로부터 숨기는 정도이다. 잘 설계된 구성 요소는 모든 구현 세부 정보를 숨기고 API를 구현과 명확하게 분리한다. 그런 다음 구성 요소는 API를 통해서만 통신하고 서로의 내부 작동을 무시한다. 정보 은닉 또는 캡슐화로 알려진 이 개념은 소프트웨어 설계의 기본 원칙이다. 정보 은닉, 캡슐화의 이점 주된 목적은 시스템을 구성하는 구성 요소를 분리하여 개별적으로 개발, 테스트, 최적화, 사용, 이해 및 수정할 수 있기 때문이다. 구성 요소를 병렬로 개발할 수 있으므로 시스템 개발 속도가 빨라진다. 구성 요소를 더 빨리 이해하고..
-
Item 14: Consider implementing Comparable독서/Effective Java 2021. 12. 12. 18:35
이 장에서 설명하는 다른 메서드와 달리 compareTo 메서드는 Comparable 인터페이스의 유일한 메소드로, 단순 동치성 비교와 순서 비교를 허용하고 제네릭하다는 점을 제외하면 Object의 equals 메서드와 특성이 비슷하다. Comparable을 구현함으로써 클래스는 해당 인스턴스에 자연스러운 순서가 있음을 의미한다. Comparable을 구현하는 객체 배열을 정렬하는 것은 다음과 같이 간단하다. Arrays.sort(a); 자바 플랫폼 라이브러리의 모든 값 클래스와 열거타입이 Comparable을 구현했고, 이 인터페이스를 활용하는 수많은 제네릭 알고리즘과 컬렉션의 힘을 누릴 수 있다. compareTo() 규약 이 Object와 주어진 Object의 순서를 비교한다. 주어진 Object보..
-
Item 11: Always override hashCode when you override equals독서/Effective Java 2021. 12. 12. 17:47
"equals"를 재정의하는 모든 클래스에서 hashCode를 재정의해야 한다. 이유: 재정의하지 않을 경우 hashCode에 대한 일반 규약을 위반하여 HashMap 및 HashSet과 같은 컬렉션에서 제대로 작동하지 않는다. Object 명세에서 발췌한 hashCode 일반 규약 응용 프로그램 실행 중에 객체에 대해 hashCode 메서드가 반복적으로 호출되면 equals 비교에 사용된 정보가 수정되지 않는 한 일관되게 동일한 값을 반환해야 한다. 이 값은 애플리케이션을 다시 실행한다면 일관성을 유지할 필요가 없다. equals(Object) 메서드에 따라 두 객체가 동일한 경우 두 객체에 대해 hashCode는 동일한 결과여야 한다. 두 객체가 equals(Object) 메서드에 따라 같지 않은 경..
-
Item 12: Always override toString독서/Effective Java 2021. 12. 12. 15:28
항상 toString을 재정의하라. 재정의의 이유 Object는 toString 메서드의 구현을 제공하지만 반환하는 문자열은 "일반적으로는" 내가 원하는 형태는 아니다. package com.tistory.povia.effectivejava.item1; public class User { private static final int FIRST_AGE = 1; private final String firstName; private final String lastName; private int age; private User(String firstName, String lastName, int age){ this.firstName = firstName; this.lastName = lastName; this..
-
Item 9: Prefer try-with-resources to try-finally독서/Effective Java 2021. 12. 5. 06:30
try-finally보다는 try-with-resources를 사용하자 Java 라이브러리에는 close 메서드를 호출하여 수동으로 닫아야 하는 많은 자원들이 포함되어 있다. close를 직접 호출하는 대표적인 예: InputStream, OutputStream, BufferedReader 등 만약 이걸 닫지 않는다면? 예측할 수 없을 정도로 심각한 성능 결과를 초래한다. 꼭 닫게 하기 위해 finalizer를 사용하는 경우도 있지만...(Item 8). 전통적으로 try-finally 문은 예외 또는 반환에 직면하더라도 리소스가 제대로 닫히도록 보장하는 가장 보편적인 방법이었다. Try-Finally 사용 Try-Catch-Finally를 사용하는 가장 익숙한 예는 개인적으로는 JDBC이다. publi..
-
Item 8: Avoid finalizers and cleaners독서/Effective Java 2021. 12. 5. 06:10
finalizer와 cleaner를 피하라 finalizer와 cleaner Java에서는 GC 대상이 될 때 소멸 메소드를 호출하는 finalizer, cleaner를 제공한다. 더보기 Finalizer: https://docs.oracle.com/javase/9/docs/api/java/lang/Object.html#finalize-- Cleaner: https://docs.oracle.com/javase/9/docs/api/java/lang/ref/Cleaner.html Finalizer: 예측할 수 없고 종종 위험하며 일반적으로 불필요하다. 오동작, 성능 저하 및 이식성 문제의 원인이 될 수 있다. 몇 가지 유효한 용도가 존재하나, 일반적으로는 사용하지 말아야 한다. Java 9부터 depreca..
-
Item 6: Avoid creating unnecessary objects독서/Effective Java 2021. 12. 4. 19:49
불필요한 객체 생성을 피하라 단일 개체를 재사용하는 것은, 필요할 때마다 기능적으로 동일한 새 개체를 만드는 것보다 더 나은 경우(더 빠르거나, 자원을 더 아끼거나)가 많다. 특히, 객체가 변경 불가능한 경우(불변) 항상 재사용할 수 있다(Item 17). Ex) 매번 String Object 생성 String s = new String("bikini"); 항상 새 String 인스턴스를 생성 => 불필요한 Object 생성 증가 "bikini" 자체가 String 인스턴스이며, 생성자에 의해 생성된 모든 객체와 기능적으로 동일하다. 만약 반복문에서 실행된다면? 수백만 개의 String 인스턴스가 불필요하게 생성될 수 있다. 수정한다면? String s = "bikini"; Object 생성 비용이 비쌀..