간펴니
간편 자바프로그래밍
간펴니
전체 방문자
오늘
어제
  • 전체보기 (185)
    • 알고리즘 (2)
    • JAVA (69)
      • 이펙티브 자바 (47)
      • JAVA 병렬프로그래밍 (5)
      • 자바 (17)
    • SPRING (60)
      • Spring (12)
      • IceWater Community (37)
      • Homme Shop (10)
      • 토비의 스프링 (1)
    • SPRING BOOT (4)
      • WhiteRecord (7)
    • 오류 (9)
    • DB (10)
      • ORACLE (5)
      • MYSQL (1)
      • MYBATIS (4)
      • JPA (0)
      • 대용량 데이터 베이스 (0)
      • SQL (0)
    • FRONT (8)
      • JSP (2)
      • JavaScript (2)
      • Jquery (3)
      • Thymeleaf (1)
    • AWS (6)
    • JNI (10)
    • 회고 (0)
    • MQ (0)
    • Radis (0)
    • Git (0)
    • Docker (0)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

  • 블로그 컨셉 변경

인기 글

태그

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
간펴니

간편 자바프로그래밍

JAVA/이펙티브 자바

4. 인스턴스화를 막으려면 private 생성자를 사용하라

2023. 6. 10. 18:29
728x90

이따금 단순히 정적 메서드와 정적 필드만 담은 클래스를 만들어야할 때가 있다.

 

정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한게 아니다.

 

하지만 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만든다.

 

즉, 매개변수를 받지 않는 public 생성자가 만들어지고, 사용자는 설계자가 생성자를 의도한건지, 아니면 실수로 자동생성된건지 구분 할 수 없다.

 

실제로 공개된 API에서 의도치않게 인스턴스화 할 수 있게 된 클래스들이 보일 때가 있다.

 

추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다.

 

하위 클래스를 만들어서 인스턴스화 하면 그만이다.

 

이것은 사용자에게 상속해서 쓰라는 오해를 불러일으킬 수 있다.

 

이런 오해를 막기위해 private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다.

 

또, 상속을 불가능하게 하는 효과도 있다. 모든 생성자는 상위 클래스의 생성자를 호출하게 되는데, 이를 private 로 선언했으니

 

하위 클래스가 상위 클래스의 생성자에 접근할 길이 막혀버린다.

 

 

특정API를 만들 때 사용자가 사용할 수 있는 부분과 사용할 수 없는 부분을 확실히 구분해놓는 것은 매우 중요하다고 생각한다.

 

설계자가 의도하지 않는 대로 API를 사용하게 된다면 API의 안정성,보안 많은 문제가 발생 할 수 있다.

728x90
저작자표시 (새창열림)

'JAVA > 이펙티브 자바' 카테고리의 다른 글

6. 불필요한 객체 생성을 피하라  (0) 2023.06.14
5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라  (0) 2023.06.11
3. private 생성자나 열거타입으로 싱글턴을 보증하라  (0) 2023.06.10
2. 생성자에 매개변수가 많다면 빌더를 고려하라  (0) 2023.06.08
1. 생성자 대신 정적 팩터리 메서드를 고려하라  (0) 2023.06.07
    'JAVA/이펙티브 자바' 카테고리의 다른 글
    • 6. 불필요한 객체 생성을 피하라
    • 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
    • 3. private 생성자나 열거타입으로 싱글턴을 보증하라
    • 2. 생성자에 매개변수가 많다면 빌더를 고려하라
    간펴니
    간펴니
    개발공부 기록하는 곳

    티스토리툴바