본문 바로가기

책/effective java29

[effective java] item 4. 인스턴스화를 막으려거든 private 생성자를 사용하라. 결론 클래스 중에는 인스턴스(객체)로 만들어 쓰려고 설계한 클래스가 아닌 경우도 있습니다. (ex) 정적(static) 멤버만 담은 유틸리티 클래스) 하지만, 생성자를 명시하지 않으면 컴파일러가 자동으로 public 생성자를 만들어 객체를 생성할 수 있으므로, private 생성자를 만들어 이를 방지해야 합니다. ex) 인스턴스를 만들 수 없는 유틸리티 클래스 (p. 26~27) public class UtilityClass { // 기본 생성자를 막는 private 생성자 - 인스턴스화 방지 private UtilityClass() { throw new AssertionError(); } ... // 나머지 코드는 생략 } 인스턴스화를 막고 싶은 클래스? 이따금 단순히 정적 메서드와 정적 필드만을 담은.. 2023. 7. 23.
[effective java] item 3. 싱글톤임을 보장하기 위해 private 생성자 또는 열거 타입을 사용해라 싱글톤(singleton)이란? 인스턴스를 오직 하나만 생성할 수 있는 클래스입니다. 함수와 같은 무상태(stateless) 객체나, 설계상 유일해야 하는 시스템 컴포넌트를 예시로 들 수 있습니다. 단점 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있습니다. 타입을 인터페이스로 정의한 다음 그 인터페이스를 구현하여 만든 싱글톤이 아니라면, 싱글턴 인스턴스를 가짜(mock) 구현으로 대체할 수 없기 때문입니다. 싱글턴을 구현하는 3가지 방법 public static final 필드 private static 멤버를 정적 메토리 메서드로 제공 열거 타입 방식의 싱글톤 BEST 1번과 2번 방법은 모두 생성자를 private 으로 감춰두고, 유일한 인스턴스에 접근할 수 있는 .. 2023. 7. 17.
[effective java] item 2. 생성자에 매개변수가 많다면 빌더를 고려하라 정적 팩토리 메서드와 생성자의 제약 : 선택적 매개변수가 많을 때 대응하기가 어렵다. 정적 팩터리 메서드와 생성자에는 같은 제약이 하나 있습니다. 선택적 매개변수가 많을 때 적절히 대응하기가 어렵습니다. 식품 포장의 영양정보를 표현하는 클래스를 예시로 살펴봅시다. 영양정보는 1회 내용량, 총 n회 제공량, 1회 제공량 당 칼로리 같은 필수 항목 몇 개와 총 지방, 트랜스지방, 포화지방, 콜레스테롤, 나트륨 등 총 20개가 넘는 선택 항목으로 이뤄집니다. 그런데 대부분 제품은 이 선택 항목 중 대다수의 값이 그냥 0입니다. 대안 1. 점층적 생성자 패턴(telescoping constructor pattern) 우선 먼저, 이런 클래스를 생성할 때, 점층적 생성자 패턴(telescoping construc.. 2023. 7. 17.
[effective java] item 1. 생성자 대신 정적 팩토리 메서드를 고려하라 정적 팩토리 메서드(Static Factory Method)란? 정적 팩토리 메서드는 객체의 생성을 담당하는 클래스 메서드입니다. 자바의 String 클래스를 이용해 정적 팩토리 메서드가 무엇인지 알아봅시다. String.java의 valueOf public static String valueOf(@NotNull char data[]) { return new String(data); } 위 코드의 valueOf()은 파라미터로 char[]을 받아 String 객체를 생성해 반환합니다. 해당 함수를 호출하는 코드는 다음과 같습니다. String str = String.valueOf("hello"); 즉, 자바에서 String 객체를 만드려면 new 생성자를 사용하는 방법 외에 valueOf()을 사용하는 .. 2023. 7. 17.
[effective java] 1장. 들어가기 이 책의 규칙 대부분은 아주 핵심적인 기본 원칙 몇 개에서 파생된다. 바로 명료성(clartiy)과 단순성(simplicity)이다. 컴포넌트는 사용자를 놀라게 하는 동작을 해서는 절대 안된다. (정해진 동작이나 예측할 수 있는 동작만 수행해야 한다.) 컴포넌트는 가능한 작되, 그렇다고 너무 작아서는 안 된다. (이 책에서 컴포넌트란 개별 메서드부터 여러 패키지로 이뤄진 복잡한 프레임워크까지 재사용 가능한 모든 소프트웨어 요소를 뜻한다.) 코드는 복사되는 게 아니라 재사용되어야 한다. 컴포넌트 사이의 의존성은 최소로 유지해야 한다. 오류는 만들어지자마자 가능한 한 빨리 (되도록 컴파일 타임에) 잡아야 한다. 이 규칙들을 맹종하진 말아야 하나, 어겨야 할 때는 합당한 이유가 있어야 한다. 대다수 규율과 마.. 2023. 7. 17.