23/12/14 스프링에서 static 사용을 지양하는 이유

 

최근 자바책을 펴 볼 기회가 있었다.

그 책에서는 익숙하게 사용하였지만,

스프링에서는 뭔가 위화감이 드는 부분을 발견하였는데

 

스프링에선 클래스에 static을 쓰지 않는다는 것이다.

생각보다 사소한 변화였기에 왜 이상한지 그동안 알아차리지 못하였는데

그 이유를 적어보고자 한다.

 

---

 

 

static을 지양하는 이유

 

첫번째. 스프링은 기본적으로 빈을 싱글톤으로 관리한다.

그렇기 때문에 하나만 생성되어 여러곳에서 공유하여 사용하는 것이 일반적인 사용방법인데,

static은 인스턴스가 아닌 클래스 수준에서 관리되기 때문에 싱글톤 빈의 생명주기와 맞지 않게 된다.

 

 

두번째. 테스트 호환성 문제

static은 실행시점에 초기화된 후 종료시점까지 메모리에 남아있는다.

그래서 테스트 수행 시  한 테스트 케이스에서 static 변수 값을 변경하는 경우 

다른 테스트에서 문제가 발생할 수 있다.

 

 

세번째. AOP

AOP는 로깅 및 트랜잭션 관리와 같은 문제를 모듈화 할 수 있다.

하지만 Aspect에 static 메소드를 사용하는 경우 이를 특정 빈이나 메소드에 선택적으로 적용하기가 어려워진다.

 

 

네번째. OOP와의 불일치

static은 인스턴스 수준이 아닌 클래스 수준에서의 동작을 허용하기 때문에 OOP원칙과 불일치가 발생한다.

	일반적인 OOP	static
캡슐화	클래스는 상태와 동작을 캡슐화한다.	static멤버는 객체를 만들지않고도 전역에 액세스 할 수 있기 때문에 캡슐화가 되지 않는다.
상속	코드 재사용성 증가	static멤버는 하위 클래스에서 오버라이딩 되지 않기 때문에 상속을 방해할 수 있으며, 계층 구조 설계 시 유연성이 떨어질 수 있다.
다형성	단일 인터페이스가 다양한 유형을 나타낼 수 있다.	static 메소드는 컴파일 시 클래스에 바인딩되기 때문에 다형성에 포함되지 않는다.

 

 

 

다섯번째. 안되는게 많은 static

static 메소드는 오버라이딩 불가  :  확장성, 유연성 제한

static 멤버는 직렬화 불가  :  객체 직렬화는 인스턴스에 적용되기 때문

 

*직렬화는 인스턴스의 상태를 바이트 스트림으로 변환하는 과정을 말하는데

이때 인스턴스의 상태는 필드 값으로 구성되지만, static필드는 클래스 수준에서 관리되기 때문에 

특정 인스턴스의 상태로 볼 수 없다.  그래서 static필드는 직렬화 대상에서 제외된다.

 

 

---

 

 

그래서 static 대신 @Autowired,  @Inject를 사용하여 의존성 주입(DI)을 활용한다.

 

DI 활용 시

 

코드 결합도 감소

재사용성 향상

테스트 용이성

 

세 가지 이점을 챙길 수 있게 된다.

 

 

---