1. 오브젝트와 의존관계

searchortype·2022년 7월 20일
1
post-thumbnail

토비의스프링을 읽고 간단히 정리하고 생각해 볼 것들을 기록합니다.

스프링의 철학

스프링의 핵심 철학은 잃었던 객체지향기술을 다시 찾아 객체지향의 장점을 최대한 활용하게 하도록 하는 데 있다.

그렇다면 스프링을 이용하면 무조건 객체지향적인 설계를 할 수 있을까?
스프링 프레임워크가 객체지향적인 설계를 강제하진 않는다. 하지만 어떻게 효과적으로 설계, 구현할지에 대한 기준을 마련해 준다.


객체지향의 장점

여기서 한가지 궁금한게 스프링의 핵심 철학이 객체지향의 장점을 최대로 활용하게 하도록함에 있다고 했는데, 어떤 장점이 있는 것인지 알아보자.

객체지향이란 무엇인가?
이 질문을 면접에서 들어보지 않은 개발자가 있을까. 그렇다면 당신을 뭐라고 대답할 것인가? 또다시 붕어빵틀이라는 단어를 꺼내들 것인가?
나라면 이렇게 대답하겠다. 객체지향이란 연관있는 것들을 class라는 단위로 분류해서 사용하는 방식이다. 이 class 안에는 class와 관련있는 상태와 행동이 들어 있다. 이 상태와 행동을 class라는 단위로 묶음으로서 객체의 추상화와 재사용이 가능해지고 변경에 대한 영향이 최소화된다. 라고

결국 객체지향의 장점은 변경이 일어날 때 필요한 작업을 최소화할 수 있다는 것이다. 관심사가 같은 것은 모으고, 다른 것은 떨어져있게 함(관심사의 분리)으로서 변경이 일어날 때 필요한 작업을 최소화한다.


제어의 역전 (Inversion Of Control)


제어가 역전되었다는 건 무슨말일까? 책에서는 위와 같이 정의하고 있다. 이해가 되는가? 저 정의만 보면 이해가 되지 않을 수 있다. 하지만 라이브러리와 프레임워크의 차이를 알면 쉽게 이해할 수 있다.

우리는 코드를 작성하다가 필요한 부분이 정의되어 있는 라이브러리에서 가져와 쓴다. 반면에 프레임워크는 적당한 시점에 우리의 코드를 가져가 쓴다는 점에서 차이가 있다. 즉, 라이브러리는 개발자가 주체가 되어 필요한 부분을 라이브러리에서 가져다 쓰는 것이고, 프레임워크는 프레임워크가 주체가 되어 필요한 코드를 가져다 쓴다는 점에서 차이가 있다는 것이다.


스프링에서의 IoC

ApplicationContext는 IoC를 적용해 관리할 모든 오브젝트에 대한 생성과 관계설정에 대해 담당한다. 다만, 직접 오브젝트를 생성하고 관계를 맺지 않는다. 별도의 생성정보를 통해 생성정보, 연관관계 정보를 얻거나 외부의 오브젝트팩토리를 통해서 작업을 위임하고 결과를 가져온다.

그렇다면 스프링에서는 왜 ApplicationContext를 사용하는 것일까?
범용적이고 유연한 방법으로 IoC기능 확장을 위해서다.

  • cli는 IoC를 적용할 오브젝트를 일일이 알 필요가 없다.
  • 오브젝트를 효과적으로 활용할 수 있는 다양한 기능을 제공한다.
    (오브젝트가 만들어지는 방식이나 사용되는 시점, 전략등을 다르게 가져갈 수 있다.)
  • Bean을 검색하는 다양한 방법을 제공한다.

싱글톤 레지스트리로서의 ApplicatonContext

스프링은 기본적으로 오브젝트를 싱글톤형태로 관리한다.(싱글톤 은 한개의 오브젝트만 만들어 사용하는 방식이다.)

왜 싱글톤으로 관리할까?

  • 우리는 오브젝트 안에서 주로 함수를 쓴다. 함수는 상태를 갖지 않는다. 때문에 객체 하나만 생성해서 사용해도 문제가 없다.
  • 성능 때문도 있다. 만약에 초당 요청이 5개씩 500개의 요청이 들어오면 2500개의 오브젝트를 생성해야 한다.

의존관계 주입

스프링 IoC의 대표적인 동작원리는 의존관계 주입이다. 그래서 DI 컨테이너라고도 불린다. IoC컨테이너는 런타임시에 의존 오브젝트와 이 의존오브젝트를 사용할 주체를 런타임 시에 연결해준다.

이렇게 제3의 존재가 설계시점에 알지 못했던 두 오브젝트의 관계를 맺도록 도와주면 어떠한 장점이 있을까?
코드에는 런타임 클래스에 대한 의존관계가 나타나지 않고 인터페이스를 통해 결합도가 낮은 코드를 만들게 된다. 다른 책임을 가진 사용 의존관계에 있는 대상이 바뀌거나 변경되더라도 자신은 영향을 받지 않고, 변경을 통한 다양한 확장 방법에 자유롭다.

0개의 댓글