책/effective java29 [effective java] item 17. 변경 가능성을 최소화하라 결론 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전합니다. 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐입니다. getter가 있다고 해서 무조건 setter를 만들지 말고, 다른 합당한 이유가 없다면 모든 필드는 private final로 선언합시다. 설명 참고 불변 클래스? 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스입니다. 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않습니다. 자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있습니다. String, 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal이 여기에 속합니다. 클래스를 불변으로 만들기 위한 5가지 규칙.. 2023. 8. 7. [effective java] item 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 결론 public 클래스는 절대 가변 필드를 직접 노출하면 안 된다. 불변 필드라면 노출해도 덜 위험하지만 안심할 수는 없다. 하지만, package-private 클래스나 private 중첩 클래스는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다. 설명 데이터 필드에 직접 접근할 때의 단점 내부 표현을 바꾸기 위해선 API를 수정해야 합니다. 불변식을 보장할 수 없습니다. 외부에서 필드에 접근할 때, 부수 작업을 수행할 수 없습니다. 따라서 필드를 모두 private으로 바꾸고 public 접근자 (getter)를 추가합니다. public 클래스라면 반드시 이 방식을 사용해야 합니다. 접근자와 변경자 메서드를 활용해 데이터를 캡슐화한다. (p. 102) public class Circ.. 2023. 8. 7. [effective java] item 15. 클래스와 멤버의 접근 권한을 최소화하라 결론 프로그램 요소의 접근성은 가능한 한 최소한으로 하라. 꼭 필요한 것만 골라 최소한의 public API를 설계하자. 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다. public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안 된다. 단, public static final 필드가 참조하는 객체가 불변인지 확인해야 한다. 설명 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리합니다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리입니다. 자바는 접근 제한자(private, protected, public)를 제공하고 이것을 제대로 활용하.. 2023. 8. 7. [effective java] item 14. Comparable을 구현할지 고려하라 결론 순서를 고려해야 하는 값 클래스를 작성한다면 꼭 Comparable 인터페이스를 구현하여, 그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 해야 한다. compareTo 메서드에서 필드의 값을 비교할 때 연산자는 쓰지 말아야 한다. '값의 차'를 기준으로 하는 Comparator도 좋지 않다. 그 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나 Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자. 정적 compare 메서드를 활용한 Comparator static Comparator hashCodeOrder = new Comparator() { public int compare(Object o1, Object .. 2023. 8. 1. [effective java] item 12. toString을 항상 재정의하라 결론 모든 구체 클래스에서 Object의 String을 재정의하자. 단, 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다. toString의 반환값 포맷을 문서화하는 것은 선택이다. AutoValue 프레임워크를 사용하여 자동 생성하는 방법도 있지만, 직접 작성하는 것이 가장 좋고 재정의하지 않는 것보단 좋다. PhoneNumber 클래스 예제 public final class PhoneNumber { private final short areaCode, prefix, lineNum; ... /** * .. 2023. 8. 1. [effective java] item 11. equals를 재정의하려거든 hashCode도 재정의하라 결론 equals를 재정의했다면, hashCode도 규약을 지켜 재정의해야 한다. 그렇지 않으면, 해당 클래스의 원소를 HashMap이나 HashSet과 같은 컬렉션의 원소로 사용할 때 문제가 발생한다. 이때, equals와 hashCode 메서드를 AutoValue 프레임워크로 자동으로 생성하는 방법도 있다. IDE들도 이런 기능을 일부 제공한다. PhoneNumber 클래스 예제: 전형적인 hashCode 메서드 public final class PhoneNumber { private final short areaCode, prefix, lineNum; ... @Override public boolean equals(Object o) { if (o == this) return true; if (!(o.. 2023. 7. 31. 이전 1 2 3 4 5 다음