학습계획
- 프레임워크 vs 라이브러리
- 스프링 프레임워크란?
- 디자인 패턴은 무엇이며 왜 생겨났나?
- 관심사의 분리 장점
Today I Learned
프레임워크 vs 라이브러리
- 프레임워크 라이브러리의 모음이며, 액션을 호출할 수 있는 제어권을 가지고 있다. → IoC
- 라이브러리 프로그램에서 재사용할 수 있는 기능, 동작의 모음 프로그램이 라이브러리를 호출한다. → 제어권이 프로그램에 있음
스프링 프레임워크란?
POJO기반의 프레임워크며(=특정 인터페이스를 구현하거나 특정 클래스를 상속받을 필요없이 java 클래그로 개발 가능), Ioc/DI를 통해 객체생성, 소멸과 같은 라이프 사이클을 관리하며, AOP를 통해 관점지향 프로그래밍을 지원한다.
디자인 패턴은 무엇이며 왜 생겨났나?
프로그램 개발 시 자주 나타나는 과제를 해결하기 위해 탄생
개발 과정에서 발견된 설계의 노하우를 패턴화 한것
관심사의 분리 장점
관심사를 분리하여 코드를 작성하면, 독립된 특정 기능에만 집중할 수 있으며, 특정 기능을 변경할때도 분리된 부분만 수정하면 되므로 다른 코드에 추가적인 영향 없이 수정이 가능하다.
@Autowired 를 통한 주입(필드를 통한 주입)
- setter를 통한 주입방식이 갖는 문제점을 동일하게 갖으며, 필드 주입은 IoC 컨테이너에 의해서만 가능하고 외부 주입이 불가하다.
- 순환참조 문제를 가지고 있다. 런타임 시 순환참조 문제를 발견하는것은 객체 생성 시점에 순환참조가 발생하는것과 스프링 컨테이너에 의해 객체 들이 생성되고, 비즈니스 로직에 의해 순환참조 호출이 일어나는것은 전혀 다른 이야기기 때문이다.
생성자 주입 방식
- setter 주입 방식에서 발생한 NullPointerException의 위험에서 벗어날 수 있다.
- 의존관계를 주입하지 않으면 객체를 생성할 수 없다. = 의존관계에 대한 내용을 외부로 노출 시킴으로써 컴파일 시 오류를 잡을 수 있다.
- final 키워드를 같이 쓸 수 있어 불변성을 보장할 수 있다.
- final 선언 시 선언과 함께 초기화되야하므로 setter 주입 방식에서는 불가하다.
- 자주 등장하는 순환참조 문제는 객체가 생성될 시점에 생성자에 의해 순환참조 사이클이 생성되어 컴파일 오류로 순환참조 현상을 알 수 있다.
public class Main {
public static void main(String[] args) {
ConstructorInjection constructorInjection = new ConstructorInjection(new Pojo());
constructorInjection.getPojo();
}
}
운영체제는 세가지 원칙 하에 임계구역 문제를 해결한다. 상호배재를 위해 아래 세가지 원칙을 지켜야한다.
1. 상호배제
한 프로세스가 임계 구역에 진입했다면 다른 프로세스는 임계 구역에 들어올 수 없다.
2. 진행
임계 구역에 어떤 프로세스도 진입하지 않았다면 임계 구역에 진입하고자 하는 프로세스는 들어갈 수 있어야한다.
3. 유한대기
한 프로세스가 임계 구역에 진입하고 싶다면 그 프로세스는 언제가는 임계 구역에 들어올 수 있어야한다.(임계구역에 들어가기 위해 무한정 대기하면 안된다.)
가상 메모리
운영체제의 메모리 관리 기법인 스와핑, 메모리에 프로세스를 할당하는 방식, 연속 메모리 할당의 부작용
- 연속 메모리 할당
- 프로세스에 연속적인 메모리 공간을 할당하는 방식
- 스와핑
- 메모리에 적재된 프로세스 중 실행되지 않는 프로세스들 중 보조기억장치로 옮기고, 비게된 메모리에 다른 프로세스를 실행하는 방식
- 스왑영역
- 실행되지 않는 프로세스들이 보조기억장치로 가서 차지하는 영역을 뜻한다.
- 스왑아웃
- 실행되지 않은 프로세스가 메모리 -> 스왑영역으로 옮겨지는것
- 스왑 인
- 스왑아웃의 반대
[참고]
https://www.youtube.com/watch?v=yKEwNVbAFC0
https://ko.wikipedia.org/wiki/디자인_패턴
https://teamdable.github.io/techblog/SoC-to-IoC