토비의 스프링 - 1권 1장 오브젝트의 의존관계

1. 스프링

스프링 : 자바 엔터프라이즈 애플리케이션 개발에 사용되는 프레임워크이다.

 

2. 객체지향 설계 원칙 (SOLID)

SPR(The Single Responsibility Principle) 단일 책임 원칙

OCP(The Open Closed Principle) 개방 폐쇄 원칙

LSP(The LiskOv Substitution Principle) 리스코프 치환 원칙

ISP(The Interface Segregation Principle) 인터페이스 분리 원칙

DIP(The Dependecty Inversion Principle) 의존관계 역전 원칙

 

높은 응집도 : 응집도가 높다는 의미는 즉 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 의미

낮은 결합도 :  책임과 관심사가 다른 오브젝트 또는 느슨하게 연결된 형태를 유지하는것을 의미한다.

각 오브젝트가 독립적이고 알필요가 없도록 만들어주는 것이다. 높은 결합도의 코드는 일부부만 수정해도

확인해야할 부분이 많기 때문에 낮은 결합도는 중요한 원칙이다.

 

3. 스프링의 핵심 기술들 

스프링 컨테이너 : 애플리케이션 컨텍스트로 불리며 설정정보를 참고로 오브젝트를 생성하고 관리한다. (IoC컨테이너라 불리기도한다)

서비스 추상화 : 특정 기술에 종속 되지 않고 확장이 가능하며 변경이 어렵게 설계되어야한다. (개방폐쇄의 원칙)

IoC :  오브젝트가 직접 코드를 실행하지않고 다른 코드에 의해서 실행되어지도록 제어권을 넘긴다. (제어의 역전)

DI : 오브젝트에서는 정확한 클래스 타입을 알 수 없다. 다만 외부로부터 인터페이스(다형성)를 넘겨 받아 실행한다. (의존관계주입)

 

DI를 사용하는 이유

 

A사에서 개발한 소스를 납품 받음.

↓

사용되는 DB가 달라서 DB커넥션 클래스를 수정해야 한다.

↓

A사 DB커넥션 클래스타입이 코드에 명시 되어있고 필드 초기화 선언으로 수정이 어렵다.

 

해결방안 :

DB커넥션 인터페이스를 생성하여 DB커넥션 클래스를 구현한다.

↓

DB커넥션 코드 부분에 인터페이스타입으로 주입 받을수있도록 한다. (생성자 주입, setter 주입, 자동 주입)

↓

DB커넥션 부분을 변경하고자 할때 DB커넥션 인터페이스를 클래스로 구현하고 주입하면 된다.

 

확장하기 어려운코드

 

public class TestUserDao {

public void userSignUp(){
// DB_A_Vendor_ConnectionClass dbconn = new DB_A_Vendor_ConnectionClass(); <-- 정확한 클래스 타입이 지정됨
// dbconn.start();
// 회원가입 로직
// dbconn.close();
}
}

 

DI를 사용하여 확장에 용이한 코드

 

public class TestUserDao {

public void userSignUp(ConnectionInterface connectionInterface){ // 다형성을 활용해 외부로부터 생성된 코드 실행
// connectionInterface.start();
// 회원가입 로직
// connectionInterface.close();
}
}

 

위 코드에서 조금 더 관심사를 분리하여 핵심로직에 집중하고자 한다면 DB 커넥션 로직을 빼서 프록시패턴, AOP를 적용한다.

 

AOP : 각 로직의 관심사를 나눈다. 예를 들어 유저 회원가입을 구현하고자 할때 트랜잭션(최소 작업 단위)이 필요한데

이러한 비즈니스로직(회원가입)과 트랜잭션 경계설정 코드가 함께 섞여있으면 핵심 로직을 파악하기 힘들다.

이를 위해서 각 로직을 관심사 별로 분리하여 핵심로직에 집중할 수있도록 한다.

(스프링의 프록시, 또는 AspectJ를 통한 바이트코드 조작을 통해서 구현 가능)

 

4. 싱글톤 레지스트리

스프링 빈으로 등록시 스프링컨테이너에 등록된 빈은 싱글톤방식으로 동작한다.

싱글톤은 한번의 인스턴스 생성으로 여러 메서드에서 사용시 동일성을 보장한다.(같은 주소 레퍼런스를 갖고있다)

이러한 싱글톤의 장점은 매 요청마다 객체를 생성할 필요가 없어 오브젝트 생성 비용과 GC(가비지 콜렉트)의 비용이 적다는 점이다.

싱글톤은 패턴 상 여러 요청에서 접근해야 하고 하나의 오브젝트를 공유하기에 클래스 밖에서 오브젝트를 생성하지 못하도록 private로 만들고 static으로 선언한다.

기존의 싱글톤의 단점을 해결하기 위해 스프링 컨테이너는 싱글톤을 생성, 관리, 공급하며 public하게 선언하여 사용 가능하도록 만들어준다.

이런 싱글톤 오브젝트를 공유하며 사용할 수 있는 이유는 메서드의 로컬변수는 독립적인 공간으로 만들어지기 때문에 변수가 덮어써질 일이없다.

단 오브젝트의 클래스 변수의경우 유의해야한다 단순히 읽기전용으로 사용시에는 이상이 없지만 지속으로 값이 덮어써지는 경우에는 사용해서 안된다.