이펙티브 자바 3,4,5장 - 인스턴스화 막기/의존 객체 생성자 주입/ 싱글톤 보장

이펙티브 자바 3,4,5장  - 인스턴스화 막기/의존 객체 생성자 주입/ 싱글톤 보장

 

  이펙티브 자바 3,4,5장을 읽고 정리한 내용이다.  1장,2장 내용과 마찬가지로 객체 생성과 파괴에 대해서 다루고 있다. 1장,2장의 내용은 아래 글에서 확인할 수 있다. 현재 5장까지 읽었는데 자바의 Collection Framework나 Spring Framework의 내부 구현체를 보면 정말로 이펙티브 자바에서 나온 패턴을 많이 사용하고 있는것을 확인할 수 있다. 

 

 

정적 팩토리 메서드 (static factory method)

 

빌더패턴

 

 

 

 

private생성자나 열거 타입으로 싱글턴임을 보증하라

 

  싱글톤 객체를 구현하면 Reflection을 이용해서 전혀 싱글톤하지 않은 객체가 될수가 있다. 따라서 싱글톤을 구현할때는 잘 구현해야한다.!!! 어떻게 싱글톤 객체를 잘 구현할까?? 싱글톤 패턴을 이용해서 객체를 구현하는 여러가지 방법과 장단점은 아래 글에 아주 자세히 설명되어 있다.

 

디자인패턴 - 싱글톤 패턴

 

 

인스턴스화를 막으려거든 private 생성자를 사용하라

 

  4장에서는 객체의 인스턴스화를 막기위해서 private 생성자를 사용해서 외부에서 직접 인스턴스를 생성하지 못하도록 막는 방법을 소개하고 있다. static메서드와 static 필드만 들어있는 객체가 존재한다면 이 객체는 인스턴스로 만들 필요가 전혀없다. 이런 경우 생성자를 외부에서 사용하지 못하도록 막아주면 안전하게 객체를 사용할 수 있는 장점이 있다.

 

  또한, private 으로 선언한 생성자는 상속을 제한해주기 때문에 하위클래스가 부모클래스를 상속받아서 마음대로 접근하는 문제를 막을 수 있다.

 

 

자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

 

객체 외부에서 생성자를 통해서 의존관계를 주입하자

 

  비즈니스 모델을 구현할때 객체간의 의존관계는 엄청나게 복잡하다. 이 복잡한 관계를 클래스 내부에서 직접 명시해서 사용하면 유연성이 떨어진다. (사용하는 시점에 따라서 클래스가 참조하는 구현체가 다른경우)  이펙티브 자바에서는 자원을 클래스에서 직접 명시하지 말고 `의존 객체 주입패턴`을 사용해서 의존하라고 권장하고 있다.

 

  `의존 객체 생성자 주입패턴`은 객체의 의존관계를 생성자를 통해서 주입하는 방식이다. 만약 A객체가 B객체를 의존하는경우 A객체를 생성할때 생성자에 B객체를 주입시켜주는 방식으로 의존관계를 맺어주는 패턴이다.  결국 의존성 주입은 외부에서 의존관계를 주입시키는 기법이다.

 

 

의존 객체 생성자 주입패턴 vs Strategy Pattern

 

   Dependency Injection이 Strategy pattern과 조금 유사한것이 아닐까 라는 생각을 했다. 결론은 둘은 서로 해결하는 문제가 다르다. Dependency Injection은 하드코딩된 객체의존관계를 제거하는데 도움을 준다. 반면, Strategy pattern은 행동을 정의하는 패턴인데 런타임 시점에서 동적으로 객체의 행동을 변경시키는 방법이다.

 

 

Dependency Injection

 

객체를 생성자를 통해 주입한다고 모든 문제가 해결될까? 그렇지 않다. 객체의 의존성을 분리시켜서 인터페이스를 통해 주입시킨다면 객체를 더 유연하게 만들수 있고 결합도를 낮추면서 확장성을 향상시킬 수 있다. 대표적으로 스프링 프레임워크를 사용하면 IoC Container를 통해 객체의 의존관계를 제어한다.

 

 

 

 

 

 

 

 

참고

 

 

[DI] Dependency Injection 이란?

 

의존성 주입(DI, Dependency Injection)이란?