[React-Native-Seoul] React-Native 초심자를 위한 실습위주의 간단한 소개 및 구현법 안내Tae-Seong Park
## React-Native-Seoul meetup ##
- React-Native 초심자를 위한 실습위주의 간단한 소개 및 구현법 안내
## 발표자 ##
박태성
아이디어샘 R&D Dev Specialist
geoseong@ideasam.net
@geoseong by Slack
2018년 11월 26일 COEX에서 진행된 HTML5 Conference 발표 자료입니다. 실제 현장에서 발표한 자료와는 다소 차이가 있을 수 있습니다.
본 발표는 React Native를 통한 하이브리드 웹 애플리케이션 개발의 개념, 배경, 적용 사례를 다루고 있습니다. 발표는 김나람님이 진행해주셨습니다.
[React-Native-Seoul] React-Native 초심자를 위한 실습위주의 간단한 소개 및 구현법 안내Tae-Seong Park
## React-Native-Seoul meetup ##
- React-Native 초심자를 위한 실습위주의 간단한 소개 및 구현법 안내
## 발표자 ##
박태성
아이디어샘 R&D Dev Specialist
geoseong@ideasam.net
@geoseong by Slack
2018년 11월 26일 COEX에서 진행된 HTML5 Conference 발표 자료입니다. 실제 현장에서 발표한 자료와는 다소 차이가 있을 수 있습니다.
본 발표는 React Native를 통한 하이브리드 웹 애플리케이션 개발의 개념, 배경, 적용 사례를 다루고 있습니다. 발표는 김나람님이 진행해주셨습니다.
파울러는 2004년의 글에서 제어의 어떤 측면이 역행되는 것인지에 대한 의문을 제기하고 의존하는 객체를 역행적으로 취득하는 것이라는 결론을 내렸다. 그는 그와 같은 정의에 기초하여 제어 역행이라는 용어에 좀 더 참신한 ‘의존성주입(DI,dependency injection)’이라는 이름을 지어줬다.
모든 어플리케이션은 비즈니스 로직을 수행하기 위해 서로 협업하는 둘 또는 그 이상의 클래스들로 이뤄진다. 전통적으로 각 객체는 협업 할 객체의 참조를 취득해야 하는 책임이 있다.
이것이 의존성이다. 이는 결합도가 높으며 테스트하기 어려운 코드를 만들어낸다.
IoC를 적용함으로써 객체들은 시스템 내의 각 객체를 조정하는 어떤 외부의 존재에 의해 생성시점에서 의존성을 부여 받는데, 의존성이 객체로 주입(inject)된다는 말이다. 따라서 IoC는 한 객체가 협업해야 하는 다른 객체의 참조를 취득하는 방법에 대한 제어의 역행이라는 의미를 갖는다.
일반적으로 IoC는 의존성주입(DI), 의존성룩업(DL) 두 개의 하위부류로 나눌 수 있으며, 일반적으로 DI를 이야기 할 때는 IoC를 가리키지만 IoC를 이야기할 때는 DI를 가리키는 것은아니다. DI도 여러 종류 (세터주입,생성자주입,메소드주입)가 있지만 DL의 경우도 의존성 풀과 컨텍스트화된 의존성룩업(CDL) 두 종류가 있다.
지난 3년여간 비트라는 제품을 Python으로 개발하면서 얻게된 경험들을 나눕니다. 주로 기술적인 의사결정의 방법들과 실수들, 또 그런 실수들을 어떻게 수습하고 다듬어 왔는지 이야기 하고, 그런 과정들을 통해 비트라는 Python 프로젝트를 어떻게 개발하여 관리하는지를 다룰 예정입니다. 상세한 사례보다는 조금은 메타적인 이야기를 하여 가급적 많은 분들에게 도움이 되고자 하였습니다.
- 비교적 오랜시간 동안 많은 인원이 투입된 프로젝트가 어떻게 개발하고 머지하는지,
- 품질 관리를 왜 해야하고 또 어떻게 하는지,
- 적정한 기술을 선택함에 있어 어떻게 해야하는지
같은 부분을 상세하게 다룰 예정입니다.
파울러는 2004년의 글에서 제어의 어떤 측면이 역행되는 것인지에 대한 의문을 제기하고 의존하는 객체를 역행적으로 취득하는 것이라는 결론을 내렸다. 그는 그와 같은 정의에 기초하여 제어 역행이라는 용어에 좀 더 참신한 ‘의존성주입(DI,dependency injection)’이라는 이름을 지어줬다.
모든 어플리케이션은 비즈니스 로직을 수행하기 위해 서로 협업하는 둘 또는 그 이상의 클래스들로 이뤄진다. 전통적으로 각 객체는 협업 할 객체의 참조를 취득해야 하는 책임이 있다.
이것이 의존성이다. 이는 결합도가 높으며 테스트하기 어려운 코드를 만들어낸다.
IoC를 적용함으로써 객체들은 시스템 내의 각 객체를 조정하는 어떤 외부의 존재에 의해 생성시점에서 의존성을 부여 받는데, 의존성이 객체로 주입(inject)된다는 말이다. 따라서 IoC는 한 객체가 협업해야 하는 다른 객체의 참조를 취득하는 방법에 대한 제어의 역행이라는 의미를 갖는다.
일반적으로 IoC는 의존성주입(DI), 의존성룩업(DL) 두 개의 하위부류로 나눌 수 있으며, 일반적으로 DI를 이야기 할 때는 IoC를 가리키지만 IoC를 이야기할 때는 DI를 가리키는 것은아니다. DI도 여러 종류 (세터주입,생성자주입,메소드주입)가 있지만 DL의 경우도 의존성 풀과 컨텍스트화된 의존성룩업(CDL) 두 종류가 있다.
지난 3년여간 비트라는 제품을 Python으로 개발하면서 얻게된 경험들을 나눕니다. 주로 기술적인 의사결정의 방법들과 실수들, 또 그런 실수들을 어떻게 수습하고 다듬어 왔는지 이야기 하고, 그런 과정들을 통해 비트라는 Python 프로젝트를 어떻게 개발하여 관리하는지를 다룰 예정입니다. 상세한 사례보다는 조금은 메타적인 이야기를 하여 가급적 많은 분들에게 도움이 되고자 하였습니다.
- 비교적 오랜시간 동안 많은 인원이 투입된 프로젝트가 어떻게 개발하고 머지하는지,
- 품질 관리를 왜 해야하고 또 어떻게 하는지,
- 적정한 기술을 선택함에 있어 어떻게 해야하는지
같은 부분을 상세하게 다룰 예정입니다.
3. 의존성(의존관계) 주입이란 ?
• 호출할 객체를 직접 선언하는게 아니라 런타임시 외부에서 주입해주는 것
• 이게 가능한 이유는 구체적인 객체가 아닌 인터페이스에 의존하기 때문에
• 따라서, 객체 간의 의존관계를 정적인 클래스 관계에서는 알 수 없다.
4. 의존성(의존관계) 주입이 필요한 이유
• DIP, SRP, OCP를 지킨 좋은 설계를 가능하게 해준다.
✓ 구체적인 객체에 의존하고 있다 (DIP 위반)
✓ 따라서 다른 구현체로 변경해야 하는 경우
해당 코드를 변경해야 한다 (OCP 위반)
✓ 해당 클래스의 책임은 비즈니스 로직을
수행하는 것인데, 구현체까지 결정하고 있다
(SRP 위반)
✓ 인터페이스에만 의존한다 (DIP)
✓ 따라서 다른 구현체로 변경해야 하는 경우
해당 코드에 변경사항은 없다 (OCP)
✓ 해당 클래스는 비즈니스 로직만 수행한다
(SRP)
5. DI Container ??
• 자바 애플리케이션에서 사용하는 객체들을 생성하고 객체들 간의 의존관계 주입 등을 담당
하기 위해 스프링에서 제공하는 클래스
7. 카테고리
• STEP1. 컨테이너에서 AppCon
fi
g 클래스 활용하여 빈 등록하기
• STEP2. AppCon
fi
g를 통해 주입되는 객체는 싱글톤 객체여야 한다
• STEP3. 만들어진 컨테이너를 기반으로 초간단 애플리케이션 작성
8. STEP1. 컨테이너에서 AppConfig 클래스 활용하여 빈 등록하기
• 빈으로 등록하기 위해 AppCon
fi
g에 선언한 다양한 메서드의 메서드 이름, 리턴타입,
실제 구현체를 어떻게 가져오지 ?
✓ re
fl
ection, 제네릭 활용!
• 빈을 담아두는 자료구조는 뭐가 좋을까 ?
✓ 빈 이름/클래스 타입 or 클래스 타입 or 빈 이름으로 원하는 객체를 가져올 수 있어야 한다.
✓ 2개의 Map을 활용해서 (빈 이름 - 인스턴스) 쌍과 (타입 - 빈 이름 리스트) 쌍 만든다.
✓ 두 번째 Map에서 value가 리스트인 이유는 타입이 같은 빈이 여러 개인 경우도 있기 때문에
✓ 결과적으로 타입으로만 조회하는 경우 해당 타입의 빈 이름을 가져와서 그 이름으로 첫 번째 Map에서
인스턴스를 얻어올 수 있다.
• 컨테이너 클래스의 관계는 어떤식으로 구성 하는게 좋을까 ?
✓ 현재는 빈을 등록하고 조회하는 기능 위주의 컨테이너이지만 다른 기능의 확장성을 고려해서
Container 인터페이스에 기능별로 인터페이스를 상속한다(현재는 빈 관련 인터페이스만 상속)
✓ 실제 스프링의 ApplicationContext도 아래와 같이 되어있었다.
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
MessageSource, ApplicationEventPublisher, ResourcePatternResolver
9. STEP2. AppConfig를 통해 주입되는 객체는 싱글톤 객체여야 한다
• 수정자(setter)를 통한 의존관계 주입 방식
✓ public 으로 set메서드를 선언해야 하기 때문에 추후에 실수로라도 변경될 가능성이 있음
✓ 실수로 의존성 주입을 해주지 않으면 런타임시 NPE 발생할 수 있다.
• 생성자를 통한 의존관계 주입 방식
✓ 인스턴스 변수를
fi
nal로 선언할 수 있기 때문에 객체가 주입되고 나면 불변이다.
✓ 대부분의 의존관계는 애플리케이션 종료 전까지 불변해야하므로 불변이 보장되어야 한다.
✓
fi
nal로 선언한 변수에 대해 생성자에서 초기화를 하지 않으면 컴파일 오류가 나기 때문에
실수할 일이 없다.
✓ 스프링 공식 문서에서도 생성자를 통한 주입방식 권장
(https://docs.spring.io/spring-framework/docs/5.0.3.RELEASE/spring-framework-reference/core.html#beans-setter-injection)
✓ 따라서 생성자를 통한 의존관계 주입방식으로 결정
10. STEP2. AppConfig를 통해 주입되는 객체는 싱글톤 객체여야 한다
• 싱글톤 객체를 보장하는 방법 : 모든 구현체 클래스에 싱글톤 패턴 적용
✓ boilerplate 코드가 만들어진다.
✓ 싱글톤 패턴을 적용하면 유연성이 떨어진다(상속 불가 등)
✓ 싱글턴으로 생성되는 객체는 구현체를 내부에 선언하므로 객체간에 결합도가 높아진다.
• 싱글톤 객체를 보장하는 방법 : 템플릿 메서드 패턴 적용 ?
✓ AppCon
fi
g 클래스에 정의된 메서드 이름이 곧 빈 이름이 될 수 있기 때문에 공통된 추상메서드를
갖는 것은 맞지 않다고 생각
<템플릿 메서드 패턴 예시>
11. STEP2. AppConfig를 통해 주입되는 객체는 싱글톤 객체여야 한다
• 싱글톤 객체를 보장하는 방법 : Con
fi
g 클래스들에 공통적으로 적용될 수 있는 부모 클래스 생성
✓ Container가 여러번 생성되더라도 Con
fi
g에 있는 빈은 한 번만 등록될 수 있도록 static 선언
✓ 멀티스레딩 환경에서의 동시 접근 문제를 방지하기 위해 ConcurrentHashMap 사용
12. STEP3. 만들어진 컨테이너를 기반으로 초간단 애플리케이션 작성
CustomerService
(interface)
CustomerRepository
(interface)
PlannerService
(interface)
MyApp
- 회원가입
- 플래너에게 드레스 투어 요청
① 회원등록
② 드레스 투어 요청
③ 해당 회원 스케줄에
‘드레스 투어’ 추가
MyContainer
CustomerService
Impl
생성
PlannerService
Impl
TemporaryCustomer
Repository
생성 생성
13. 느낀점
• 내부가 어떻게 돌아가는지 꾸준히 관심을 갖자
• 프레임워크에 녹아있는 원리를 공부하자
• 자바 기초가 중요한 것 같다
• 테스트 코드 작성하자