4. 인스턴스화를 막으려거든 private 생성자를 사용하라
안녕하세요, 이번 포스팅은 전 아이템 챕터의 핵심 요소인 private 생성자 파트입니다.
요즘 인프런에서 김영한님의 스프링 고급 강의를 듣고있는데, 마치 이펙티브 자바의 핵심 요소들을 쏙쏙 뽑아 실무에 적용하는 느낌이 들었습니다.
책을 읽고 나니 더욱 더 이해가기도 하구요 ㅎㅎㅎ
대놓고 홍보하는겁니다, 김영한님 최고 ㅎㅎ
흔히 정적 메서드와 정적 필드는 OOP에서 미움 받는 형식이기도 합니다.
하지만, 분명 쓰임새가 있습니다.
예를 들어, java.lang.Math와 java.util.Arrays처럼 기본 타입 값이나, 배열 관련 메서드들을 모아놓을 수 있고, JAVA 8부터 java.util.Collections처럼 특정 인터페이스를 구현하는 객체를 생성하는 정적(팩터리) 메서드를 모아놓을 수 있습니다. 또한, final 클래스와 관련한 메서드를 모아놓을 때도 사용합니다.
아시다시피 final 클래스를 상속해서 하위 클래스에 메서드를 넣는 것은 불가능하기 때문입니다.
정적 멤버만 담은 클래스는, 기본적으로 인스턴스로 만드려고 설계한 것이 아닙니다.
하지만, 여기서 생성자를 명시하지 않는다면, 컴파일러가 파라미터를 받지 않는 기본 파라미터를 받는 것이 문제입니다.
간단한 예시를 들어보겠습니다.
package item4;
// 기본 생성자가 자동으로 만들어짐
public class PublicConstructHuman {
private String name;
private int age;
}package item4;
// private으로 생성자를 선언한 경우
public class PrivateConstructHuman {
private String name;
private int age;
private PrivateConstructHuman() {
}
}
package item4;
public class PrivateConstTest {
public static void main(String[] args) {
PublicConstructHuman publicConstructHuman = new PublicConstructHuman();
PrivateConstructHuman privateConstuctHuman = new PrivateConstructHuman();
//컴파일 오류 발생!!
}
}기본적인 내용이지만, 지금까지 포스팅한 싱글턴, 정적팩터리 메서드의 가장 기본적인 개념이라고 볼 수 있습니다.
개인적인 생각으로, public 생성자를 사용하여 인스턴스를 받는것은 매우 편리하다고 생각하지만, API 설계나 기타 보안측면, 심지어 유지보수 측면에서도 이러한 기본 생성자를 만들어 두는것은 좋지 않다고 생각합니다.
(혹여 다른 좋은 의견이 있으신 분은 꼭!!! 댓글 부탁드립니다 ㅎㅎ)
이 방식은 상속을 불가능하게 하는 효과도 있습니다.
왜냐하면, 상속을 받는 클래스의 생성자는 super() 메서드로 무조건 부모 클래스의 생성자를 사용해야 하는데, 이것이 private이기 때문입니다.
package item4;
public class PublicChildOfHuman extends PrivateConstructHuman{
public PublicChildOfHuman() {
super(); // 컴파일 오류 발생!!
}
}회고
금일 포스팅은 간단하면서도, 지금까지 개발해온 것들에 대한 부정(?)을 느꼈습니다.
학부 시절 생성자의 개념도 이해를 못했는데, 이제는 public 생성자를 쓰지말라니..
하지만, 스프링 강의나 여타 토이 프로젝트를 하면서 되게 중요하다는 개념임을 느꼈습니다.
마지막으로 영한님이 늘 말씀하시는 명언 하나 투척하고 포스팅 마치겠습니다.
개발자가 불편해야 고객이 편하다!
