[Spring] 1장 오브젝트와 의존관계(2)

 

[Spring] 1장 오브젝트와 의존관계(1)

지난 시간에 이어서...

---

[관계설정 책임의 분리]

public UserDao(ConnectionMaker connectionMaker){
  this.connectionMaker = connectionMaker;
}

수정한 생성자의 모습. 이전의 DConnection이 사라진 이유는 DConnectionMaker를 생성하는 코드 UserDao와 특정 ConnectionMaker 구현 클래스의 오브젝트 간 관계를 맺는 책임을 담당하는 코드였는데, 그것을 UserDao의 클라이언트에게 넘겨버렸기 때문.

 

여기서 이제 관계설정 책임이 추가된 UserDao 클라이언트인 main() 메소드를 보게되면,

public Class UserDaoTest{
        public static void main(String[] args) throws ClassNotFoundException, SQLException {
            ConnectionMaker connectionMaker = new DConnectionMaker();
            //UserDao가 사용할 ConnectionMaker 구현 클래스를 결정하고 오브젝트를 만듬            
            UserDao dao = new UserDao(connectionMaker);
            // 1. UserDao 생성
            // 2. 사용할 ConnectionMaker 타입의 오브젝트 제공. 결국 두 오브젝트 사이의 의존관계 설정 효과
            ...
        
        }
}

ConnectionMaker에 오브젝트가 제공되는것을 확인 할 수 있다.

이제 클라이언트 역할을 통해 Connection ConnectionMaker = new NConnectionMaker(); 형태로 N 사와 D사는 자신들만을 위한 DB 접속 클래스를 만들 수 있다. ConnectionMaker로 인터페이스를 구현했다면 이제 어떤 클래스로 만든 오브젝트라도 크게 상관이 없을것.

관계설정 책임을 담당한 클라이언트 UserDaoTest가 추가된 구조

UserDao의 테스트를 위해선 add(), get() 메소드를 사용하여 UserDao는 생성자를 통해 전달받아 인스턴스 변수에 저장해둔 DConnectionMaker 오브젝트의 maekConnection() 메소드를 호출해서 DB 커넥션을 생성하면 된다.

 

[원칙과 패턴]

 

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

: 깔끔한 설계를 위해 적용 가능한 객체지향 설계 원칙 중 하나. ' 클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다' 라고 정의 할 수 있음.

앞서 코드를 통해 이해하자면 UserDao는 DB연결 방법이라는 기능을 확장하는데 열려있으며, UserDao에 전혀 영향을 주지 않고도 얼마든지 기능을 확장 할 수 있게 되어 있음. 동시에 UserDao 자신의 핵심 기능을 구현한 코드는 그런 변화에 영향을 받지 않고 유지 할 수 있으므로 변경에는 닫혀 있다라고 볼 수 있다. 바로 위에 있는 그림은 개방폐쇄원칙을 나타나는 예라고도 볼 수 있음.

 

※ 객체지향설계원칙(SOLID)

객체지향의 특징을 잘 살릴수있는 설계의 특징이며, SOLID라고 불리우는 5가지 원칙이 있다.

1) SRP(The Single Responsibility Principle) : 단일 책임 원칙

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

3) LSP(The Liskov Substitution Principle) : 리스코프 치환 원칙

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

5) DIP(The Dependency inversion Principle) : 의존관계 역전 원칙

 

개방폐쇄원칙 같은 경우에는 높은 응집도와 낮은 결합도(high coherence and low coupling)라는 고전적 원리로도 설명 가능

 

응집도가 높다는건 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻. 불필요하거나 직접 관련이 없는 외부의 관심과 책임이 얽혀 있지 않으며, 하나의 공통 관심사는 한 클래스에 모여있음. 높은 응집도는 클래스뿐 아니라, 패키지, 컴포넌트, 모듈에 이르기까지 그 대상의 크기가 달라도 동일한 원리로 적용 가능

 

낮은 결합도는 높은 응집도보다 더 민감하다. 결합도가 낮아지면 변화에 대응하는 속도가 높아지고, 구성이 깔끔하며 확장하기에도 매우 편리함.

 

※ 전략패턴(Strategy Pattern)

자신의 기능 맥락(Context)에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통쨰로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게하는 디자인 패턴

---

출처 : 토비의 스프링 Vol.1