public class XmlMain {
public static void main(String[] args) {
// 컨텍스트 등록을 돕는 메타데이터로 xml 선택시 ClassPathXmlApplicationContext 사용
try (ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
// resources/beans.xml 파일을 읽어서 컨테이너에 객체 등록하겠다.
"beans.xml")) {
English english = context.getBean("english", English.class);
Korean korean = context.getBean("korean", Korean.class);
english.hello();
korean.hello();
}
}
}
korean은 컨테이너에 등록이 안됐기 때문에 다음과 같은 에러가 발생 No bean named 'korean' available
(English와 같은 방식으로 xml에 추가하면 에러가 해결됩니다.)
생성자 주입
public class LanguageSpeakService {
private final Language language;
public LanguageSpeakService(Language language) {
this.language = language;
}
public void speak() {
System.out.println("Speak Service");
language.hello();
}
}
LanguageSpeakService 클래스는 Language에 대한 의존관계를 갖습니다.
Field로 갖고있는 타입이 Interface기 때문에 실질적인 동작은 Language의 SubType인
클래스파일을 reflection으로 읽어 객체를 생성할때 korean 이름으로 등록된 Bean을 참고해
만들어진 languageSpeakService 객체를 컨테이너에 등록해
public static void main(String[] args) {
// 컨텍스트 등록을 돕는 메타데이터로 xml 선택시 ClassPathXmlApplicationContext 사용
try (ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
// resources/beans.xml 파일을 읽어서 컨테이너에 객체 등록하겠다.
"beans.xml")) {
English english = context.getBean("english", English.class);
Korean korean = context.getBean("korean", Korean.class);
english.hello();
korean.hello();
LanguageSpeakService languageSpeakService =
context.getBean("languageSpeakService", LanguageSpeakService.class);
languageSpeakService.speak();
}
생성자 주입 사용시 코드가 문제없이 동작하게 됩니다.
setter 주입
public class LanguageSpeakService {
private Language language;
// setter 주입을 위한 기본 생성자
public LanguageSpeakService(){
}
public LanguageSpeakService(Language language) {
this.language = language;
}
public void setLanguage(Language language) {
this.language = language;
}
public void speak() {
language.hello();
}
}
<bean id="languageSpeakService" class="com.springframework.core.practice.language.service.LanguageSpeakService">
<property name="language" ref="english"/>
</bean>
이 방식은 language 에 대한 표준 명명규칙을 따르는 set메서드를 찾아갑니다.
실질적으론 setLanguage 메서드를 찾아 동작하는 것이죠 따라서 name을 바꾼다면 정상동작 하지 않습니다.
<bean id="koreanChef" class="com.springframework.core.practice.domain.chef.KoreanChef"/>
<bean id="americanChef" class="com.springframework.core.practice.domain.chef.AmericanChef"/>
<bean id="chefCookService" class="com.springframework.core.practice.service.ChefCookService"/>
public class ChefCookService {
//// Autowired 어노테이션 기반 설정
@Autowired
// americanChef 이름을 가진 빈을 사용하겠다
@Qualifier("americanChef")
private Chef chef;
public ChefCookService() {
}
public void makeFood() {
chef.cook();
}
}
Annotation 을 이용하지만 XML방식을 기반으로 두고있기 떄문에
등록하고자 하는 객체들은 기존과 동일하게 전부 XML 파일안에 정의되있어야 합니다.
이러한 방법은 설정을 아예 분리함으로써 프레임워크와의 의존성을 최소화합니다.
하지만 만약 클래스가 5천개쯤 된다면?
지금은 프로그램이 간단해 xml을 읽고 설정하는게 쉽지만 프로그램이 커지는 경우 XML방식은 큰 부담이 됩니다.
따라서 프레임워크와의 의존성이 강화되더라도 순수 자바코드로 해결하는 Java Configuration 방식이 도입됩니다.
Java Configuration 을 이용한 DI
기존에는 XML파일을 메타데이터로 사용했지만 이제는 순수자바를 사용하기 떄문에
AnnotationConfigApplicationContext를 사용합니다.
Java Configuration 이용한 방법은 크게 2가지가 존재합니다.
자바코드로 Bean등록
Component Scan
자바코드로 Bean등록
// 이건 설정하는 파일이야
@Configuration
// JavaConfiguration 에서 XML 설정을 사용할 수 있습니다.
@ImportResource("classpath:/beans.xml")
public class JavaConfig {
@Bean
public AmericanChef americanChef() {
return new AmericanChef();
}
@Bean
public KoreanChef koreanChef() {
return new KoreanChef();
}
// 메서드 주입방식이라 합니다.
@Bean
ChefCookService chefCookService() {
return new ChefCookService(americanChef());
}
}
여기서 Bean에 등록될 이름은 메서드의 이름과 같습니다.
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext("com.springframework.core.practice");
이 코드는 다음과 같습니다.
com.springframework.core.practice 경로 아래에있는 모든 파일에서
@Configuration , @Component , @Controller , @Service , @Repository 에 해당하는
어노테이션이 붙은 클래스들을 자동으로 빈에 등록해.
Component Scan
컴포넌트 스캔은 다음의 어노테이션을 포함하는 클래스를 읽어 자동으로 빈에 등록시킵니다.
@Component : 컴포넌트 스캔에서 사용
@Controller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용
@Repository : 스프링 데이터 접근 계층에서 사용
@Configuration : 스프링 설정 정보에서 사용
(Configuration,Controller,Service,Repository 모두 내부적으로 @Component을 상속하고있습니다.)
@Component
public class English implements Language{
@Override
public void hello() {
System.out.println("Hello");
}
}
@Component
public class Korean implements Language {
@Override
public void hello() {
System.out.println("안녕하세요");
}
}
생성자 주입
@Component
public class LanguageSpeakService {
private final Language language;
// 생성자 주입
@Autowired
public LanguageSpeakService(@Qualifier("english") Language language) {
this.language = language;
}
public void speak() {
language.hello();
}
}
생성자를 이용하기 떄문에 Field를 final로 선언 가능해 불변성을 지킬수 있습니다.
가장 권고되는 주입방식입니다.
setter 주입
@Component
public class LanguageSpeakService {
private Language language;
// setter 주입
@Autowired
public void setLanguage(@Qualifier("english") Language language) {
this.language = language;
}
public void speak() {
language.hello();
}
}
기본생성자 필요 , final 선언 불가
필드주입
@Component
public class LanguageSpeakService {
// 필드주입
@Autowired
@Qualifier("english")
private Language language;
public void speak() {
language.hello();
}
}
코드가 가장 간결하지만 외부에서 변경이 불가능해 테스트가 어렵습니다.
또한 setter와 마찬가지로 final 선언이 불가합니다.
(이러한 단점들 때문에 거의 사용하지 않음이 권고됩니다.)
Bean Vs Component
자바코드를 이용한 Bean등록은 주로 System 전체에서 공통적으로 사용되야 하는 것들을 대상으로 합니다.
예를들어 전체에서 공통적으로 사용되는 Thread Pool , Connection Pool의 경우
설정파일(JavaConfig.class)에 모아서 셋팅하게되면 "아 이것들은 공통적으로 전체 System에서 사용하는 구나" 이런 이해를 돕습니다.
반대로 Business Model들은 각각의 것들이 고유한 성질을 갖습니다.(ChefCookService , LanguageSpeakService...)
이런경우 @Service , @Controller 같은 Component Scan 방식을 이용합니다.
보통 4가지를 통틀어 Dependency라고 뭉뚱그려 부르긴 하지만 각각의 차이를 인지하는 것이 중요합니다.
이제부터 하나씩 알아보겠습니다.
Dependency(의존관계)
public class UserService {
public void saveUser(UserRepository userRepository){
System.out.println("유저저장");
userRepository.save();
}
}
public class UserRepository {
public void save(){
// do something ..
}
}
의존관계란 클래스가 다른 클래스를 일시적으로 참조하는 형태입니다.
이 코드에서는 Service가 User를 저장할 때 UserRepository를 param으로 불러와 사용합니다.
saveUser 연산을 동작시킬때만 일시적으로 참조하게 되며 생명주기와 같은 어떤것도 일치하지 않습니다.
가장 낮은 수준의 결합도를 가집니다.
Association(연관관계)
public class UserService {
private UserRepository userRepository;
public UserRepository getUserRepository() {
return userRepository;
}
public void saveUser() {
this.userRepository = new UserRepository();
System.out.println("유저저장");
userRepository.save();
}
}
public class UserRepository {
public void save(){
// do something ..
}
}
UserService 객체를 생성할 때는 UserRepository가 생성돼있지 않습니다. 이 부분은 의존관계와 동일하지만 saveUser() 메서드를 호출 해 동작이 끝났음에도 Repository 객체가 남아있게 됩니다.
public class Main {
public static void main(String[] args) {
UserService userService = new UserService();
System.out.println(userService.getUserRepository());
userService.saveUser();
System.out.println(userService.getUserRepository());
}
}
이것이 의존관계와의 차이점이며 의존관계보다 높은 결합도를 가집니다.
Aggregation(집합관계)
public class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public UserRepository getUserRepository() {
return userRepository;
}
public void saveUser() {
System.out.println("유저저장");
userRepository.save();
}
}
public class UserRepository {
public void save() {
// do something ..
}
}
생성자를 통해 다른 클래스의 객체를 받아오는 경우입니다.
(Field를 Final로 선언할 수 있다는 장점이 있습니다.)
UserService 생성을 위해서 필수적으로 UserRepo가 필요합니다.
하지만 이것이 UserService와 UserRepository가 동일한 생명주기를 가진다는 건 아닙니다.
UserRepository가 먼저 생성되고 사용된 후 Service 생성도 가능하기 때문입니다.
public class Main {
public static void main(String[] args) {
UserRepository userRepository = new UserRepository();
userRepository.save();
userRepository.save();
userRepository.save();
UserService userService = new UserService(userRepository);
System.out.println(userService.getUserRepository());
userService.saveUser();
}
}
기존 관계들과의 차이점은 메서드 호출없이 객체 생성만해도 Repository가 존재합니다.
Composition(합성관계)
public class UserService {
private final UserRepository userRepository;
public UserService() {
this.userRepository = new UserRepository();
}
public UserRepository getUserRepository() {
return userRepository;
}
public void saveUser() {
System.out.println("유저저장");
userRepository.save();
}
}
public class UserRepository {
public void save() {
// do something ..
}
}
UserService와 UserRepository의 생명주기가 완전히 일치하게 됩니다. 이런 형태를 강하게 결합한다 라고도 말합니다.
코드의 결합이 강해지게되면 재사용성이 크게 떨어지기 때문에 보통 Aggregation 관계를 사용합니다.
IoC/DI와 Dependency의 관계
IoC는 프로그램이 흐름의 제어권을 갖음을 말합니다.
Spring에 경우 Context에 Bean을 등록하고 관리하는 등 Spring Bean의 생명주기를 스스로 관리합니다.
그런데 Aggregation , Composition 과 같이 객체 생성을 위해서 다른 클래스를 필요로하는 경우는 어떡할까요??
public interface Language {
// do something
}
public class Korean implements Language{
// do something
}
public class English implements Language{
// do something
}
public class LanguageService {
private final Language language;
public LanguageService(Language language) {
this.language = language;
}
}
LanguageService는 Aggregation 의존관계를 갖습니다.
따라서 자체적인 객체생성이 불가능하며 다른 타입의 객체가 필요합니다.
하지만 Type이 Language로 되어있기 떄문에 필요한 객체의 타입은 English가 될 수도 Korean이 될 수도 있습니다.
따라서 프로그램이 무엇을 의존할지 자체적으로 정할 수 없게되고
어떤 타입의 객체를 사용할 것인지를 외부에서 주입해줘야 합니다. (Korean,English 또한 설정을 추가해 주입해줘야 함)
이를위한 여러가지 의존관계 주입방법이 나오게됐으며 이를 통틀어 Dependency Injection 이라 부릅니다.
기존의 프로그램은 구현 객체가 프로그램의 제어 흐름을 조종합니다. 즉 사용자에 의해서 흐름이 제어되며 프로그램은 사용자가 만들어놓은 흐름에 따라 실행 될 뿐입니다.
IoC는 이 상태를 반전시킨 것으로 사용자에 의해 흐름이 제어되는 것이 아닌 프로그램 자체가 제어권을 갖는 것입니다.
Non - IoC Exapmle
public class Main {
public static void main(String[] args) {
MemoryMemberRepository memoryMemberRepository = new MemoryMemberRepository();
MemberService memberService = new MemberServiceImpl(memoryMemberRepository);
/**
* memberService 를 이용한 코드
*/
}
}
일반적인 형태의 코드입니다.
main문 안에서 필요한 객체들을 생성하고 사용하게 됩니다
이 경우 해당 객체들의 생명주기는 main이 시작하면서 생성되고 main이 종료되면서 삭제됩니다.
만약 사용자가 코드를 변경한다면
public class Main {
public static MemberService memberService = new MemberServiceImpl(new MemoryMemberRepository());
public static void main(String[] args) {
/**
* memberService 를 이용한 코드
*/
}
}
객체들의 생명주기는 클래스가 로드될때 생성되고 프로그램 종료시 삭제됩니다.
또한 사용자가 언제 memberService를 호출해 사용할 지 흐름을 정의할 수 있습니다.
사용자가 코드를 만드는 방식에 따라서 객체의 생명주기와 동작의 흐름이 바뀌게되며
이는 사용자가 프로그램의 제어 흐름을 조종하는 것과 같습니다.
IoC는 이러한 흐름을 역전시켜 프로그램이 자체적으로 흐름을 제어하는 것입니다.
IoC Exapmle
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memoryMemberRepository());
}
@Bean
public MemoryMemberRepository memoryMemberRepository() {
return new MemoryMemberRepository();
}
}
Spring FrameWork에서 자바 코드를 이용해 Bean을 등록하는 코드입니다.
이 코드를 통해서 MemberService , MemoryMemberRepository는 Spring Bean의 형태로 Context에 등록됩니다.
또한 Bean들의 생명주기또한 Context가 스스로 제어합니다.
사용자는 이 과정에 개입하지 않으며 모든 동작은 Spring이 정의해놓은 순서와 규칙을 통해 이루어집니다.
즉 사용자에게 제어권이있는게 아닌 프로그램 자체가 제어권을 갖고있는 것입니다. 이것을 제어권이 역전되었다 , IoC 되었다 라고 말합니다.
사용자는 @BeforeEach , @Test , @AfterEach 어노테이션만 사용하면 프로그램이 알아서 테스트로 인식하고
실행시 JUnit이 이미 정의한 동작 순서와 생명주기에 따라 테스트하게 됩니다.
따라서 IoC가 됐다 = 프로그램이 자체적으로 흐름을 제어한다.
이렇게 정리할 수 있습니다.
프로그램의 자체적인 흐름이란??
프로그램이 컨테이너를 통해 생명주기를 관리한다.
동작의 순서가 프로그램이 정의한 흐름을 따른다.
(이런 흐름에 사용자가 억지로 개입할수는 있지만 일반적인 경우만 다루겠습니다.)
IoC의 이점
IoC/DI를 구현함으로 사용영역과 구성영역을 나눌 수 있습니다.
쉽게말하면 사용자는 객체의 실행에만 신경쓰고 , 객체들의 관리와 동작의 흐름은 프로그램이 하게 하는것입니다.
// 실행영역
public static void main(String[] args) {
// 사용자가 객체 사용시 new 를 이용해 찍어내지 않음 , Context에 등록된 Bean을 꺼내 사용
// 즉 객체를 사용자가 관리하는게 아님
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
// 따라서 객체자체의 실행에만 집중할 수 있음
Member member = new Member(1L, "memberA", Grade.VIP);
memberService.join(member);
}
// 여기는 구성영역 , 해당 객체들이 Bean에 등록되는 과정과 관리방법은 이미 Spring에 정의돼있음
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
return new MemberServiceImpl(memoryMemberRepository());
}
@Bean
public MemoryMemberRepository memoryMemberRepository() {
return new MemoryMemberRepository();
}
}
실행하는 코드와 구성하는 코드를 분리하게 됨으로써 유지보수의 용이성과 가독성을 높여줍니다.
이런 IoC개념이 기본적으로 깔려있는 FrameWork는 사용자가 제어 해야 할 상당 부분들을 대신함으로써
개발 생산성을 크게 증가시켜줍니다.
Ex) 스프링 사용시 사용자는 객체의
의존관계를 어떻게 주입할것 인지만 설정해주면 Bean을 등록하고 관리하는 모든 과정은 스프링이 제어 함 (IoC/DI의 개념)
추가적으로 흔히 말하는 FrameWork Vs Library 의 가장 큰 차이도 IoC개념이 있냐 없냐의 차이가 가장 핵심적입니다.
여러 부트 캠프 중에 NHN Academy 관련해서는 정보가 많지 않아서 회고를 위장한 정보글을 써봅니다.
아카데미에 지원에 정보를 찾는 분들을 위해 글을 작성하는 것이며 제가 겪은 4기를 기준으로 말씀드리겠습니다.
저의 경우는 체험과정(끝) - 본 과정(끝) - Spring 과정(진행 중) - 프로젝트 과정(추후 선발 필요)의 과정을 거쳤습니다
이는 어디까지나 4기를 기준으로 쓴 글이며 향후 아카데미 교육정책에 따라서 변경이 가능합니다.
교육방식
아카데미가 지향하는 교육 방법은 동료 학습을 통한 성장입니다.
3명~5명을 기반으로 팀을 이루어서 학습이 진행되며 아카데미에서는 공부할 것들에 대한 교재 및 자료들을 제공하고 관리합니다.
각 팀마다 TA(조교)가 배정되고 TA 또한 플레잉코치와 비슷하게 팀원들과 같이 공부하고 코드 리뷰를 진행합니다.
이 부분에 대해서는 자유도가 매우 높아 정해진 교재나 자료를 활용하지 않고 팀 자체적으로 다른 자료를 참고하는 학습도 가능합니다.
뿐만 아니라 학습 진도에 대해서도 팀 차원에서 자율적으로 이루어집니다.
중간중간에 교육 전반에 것들을 책임 지시는 학장님, DB를 담당하시는 부학장님이 단체 교육을 하실 때도 있고 특강의 형태로
진행될 때도 있으며 과제 및 시험을 통한 검증 시스템이 존재합니다.
장점
보장된 교육
가장 중요한 부분은 학습에 도움을 주시는 모든 분들이 NHN 소속이십니다.
오시는 강사분들이 CTO부터 시작해 최소 팀장급의 인사가 오기 때문에 제공하는 교육과 자료의 질 또한 매우 뛰어난 편입니다.
개인적으로 저는 이 부분이 특장점이라 생각합니다.
보통의 부트 캠프에서는 강사진에 대한 정확한 레퍼런스를 알 수 없을 때가 많습니다.
뛰어난 강사진, 네카라 출신 강사진, 현직 xx 개발자 ... 이런 식의 홍보를 하지만 그것이 사실인지
또 사실이라면 얼마나 경력을 쌓은 건지 , 이전 근무지가 어디인지 공개하지 않는 경우가 많습니다.
보통의 회사에서는 겸업금지 조항이 있기 때문에 실제 현직 개발자여도 그 레퍼런스를 공개할 순 없으며 개인적으로 이는 교육과정 자체에 대한 신뢰를 매우 떨어트린다 생각합니다. (이런 이유로 강사진의 수준을 보장받는 네이버 부스트 캠프, 우아한 테크 코스 등등이 유명한 것이라 생각합니다.)
특히 아카데미의 빛과 소금이자 코드의 메시아이신 학장님은 정말 대단합니다.
자유로운 분위기
학습에 대한 자유도가 매우 높기 때문에 중간중간 공부하면서 자체적인 팀 과제를 설정하거나
진도를 재설정하는 것이 가능해 유연하게 계획을 세울 수 있습니다.
동료 학습을 기반으로 하기 때문에 개인으로는 할 수 없는 경험이 가능합니다.
Git을 통해 PR 날리고... Merge 하고.... 코드 리뷰하고...
동료들과 같이 학습하고 리뷰하는 시간을 통해 다양한 의견을 주고받는 것은 협업에 대한 경험치를 확실히 축적시켜줍니다.
충분한 토의 후에도 결론이 나지 않는 문제들에 대해서는 TA를 이용하거나 학장님께 가서 의견을 물을 수 있기 때문에
개인적으로는 이 방식을 매우 선호합니다.
자유로운 장소
기본적으로 조선대에서 제공하는 독자적인 공간을 사용합니다.
이 공간은 NHN Academy 연수생들만 사용 가능하며, 시설 또한 괜찮은 편입니다.
배정된 공간 이외에도 학교 시설물을 이용 가능하기 때문에 공간의 제약이 적은 편입니다.
연계채용
본 과정을 수료한 뒤 선발을 거쳐 프로젝트 과정을 들어가게 되면
프로젝트 결과물과 추가적인 심사 후 NHN에 연계 채용이 가능합니다.
단점
자유로운 분위기
앞서 말했듯이 팀을 이루어 학습하는 동료학습의 방식입니다.
따라서 정해진 시간에 교육장소만 온다면 무엇을 공부하든 , 얼마나 공부하든 그것은 팀의 책임입니다.
이런 높은 자유도는 성향에 따라 장점이 될 수도 단점이 될 수도있습니다.
개개인의 실력이 다르기 떄문에 팀의 학습 진도를 따라가는게 벅찬 경우도 있으며 팀원 모두가 열성적으로 참여하지 않으면 팀 전체의 학습에 지장이 생길 수 있습니다.
"팀의 학습이 느리고 정체되는 건 우리가 직접 개입할건 아니고 팀의 문제야 , 네가 원하면 팀을 변경해 줄게" 이것이 아카데미의 기조기 때문에 빡센 관리를 원하시는 분 혹은 집체교육으로 빠르게 학습하는 방식을 선호하시는 분들에게는 적합하지 않습니다.
거주지
교육이 진행되는 장소는 조선대학교(전라도 광주)입니다.
만약 거주지가 가깝다면 문제가 없지만 타 지역에서 교육을 수강하기에는 무리가 있을 수 있습니다.
저 같은 경우에도 본가는 경기도, 학교는 서울이었기 때문에 자취를 하고 있습니다.
마무리
가장 중요한 건 개인의 성향이라 생각합니다.
자유로운 분위기에서 유동적으로 행동하시는 걸 좋아하시는 분들께는 정말 좋은 경험이겠지만 그렇지 않으신 분들은 만족하기 힘들지 않을까 생각합니다.
개인적으로는 교육에 너무 만족했고 더 많은 사람들 참여해 더욱 뛰어난 분들이 배출되면 좋겠습니다.
