차곡차곡.

토비의 스프링 1장: 오브젝트와 의존관계 ApplicationContext : 스프링의 가장 대표적인 오브젝트로 IoC를 적용하여 관리하는 모든 오브젝트에 대한 생성과 관계설정을 담당한다. 또한, 스프링의 각종 부가 서비스를 추가로 제공한다. (자동생성, 오브젝트 생성 후처리, 정보의 조합, 설정 방식의 다변화, 인터셉팅 등..) BeanFactory 인터페이스를 상속한다. 기존의 오브젝트 팩토리와의 차이점으로, Factory는 직접 오브젝트를 생성하는데에 반해 ApplicationContext에서는 이 생성/연관관계정보를 설정정보(메타정보 configuration)를 통해 얻는다. ==> Factory 오브젝트가 추가됨에 따라 클라이언트가 알맞은 팩토리 클래스를 찾아 생성, 사용할 필요가 없다. ==>..

토비의 스프링 1장: 오브젝트와 의존관계 제어의 역전 (IoC : Inversion of Control) 특정 클래스의 생성 / 관계 설정에 대한 책임과 권한을 가지는 제 3의 클래스가 존재하여 (=Factory) 프로그램의 흐름에서 필요한 시점에 직접 오브젝트를 생성하고 만들어진 오브젝트의 메소드를 호출 하는 것이 아니라, 클라이언트에서는 내부에서는 이에 대한 동작, 생성에 대해서는 신경쓸 필요가 없이 필요에 따라 오브젝트의 생성 메소드를 호출하여 사용하기만 한다. ==> Client는 요청만! Factory는 설계를 담당! 스프링에서는 IoC오브젝트인 빈 팩토리/어플리케이션 컨텍스트(bean factory/application context) 에서 오브젝트를 생성하며, 여기서 생성될 오브젝트를 빈(B..

토비의 스프링 1장: 오브젝트와 의존관계 관심사의 분리 하나의 관심사가 여기저기 흩어져 있으면 중복되는 코드로 존재하면, 그 관심사에 변경이 일어날 때 엄청난 수정이 발생된다. 먼저, 이는 메소드 추출 리팩토리 기법(extract method)으로 중복된 코드를 하나의 메소드로 정의하여 분리할 수 있다. 아주 기본적인 관심사의 분리 작업이다. 이를 좀 더 유연하게 확장해보자. 예로, 한 기업이 어떠한 Solution을 A고객사와 B고객사에 판매하려고 한다. 단, 이는 기업의 독자적인 기술이 들어가있기 때문에 Binary File만 제공하고 소스는 공개하지 않는다. 이 때, 고객사가 Solution을 사용하기 위한 Setting을 다르게 설정하고 싶다면 어떻게 할 수 있을 까? (Solution는 하나의 ..