일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Level2
- 프리코스
- Paging
- 레벨2
- 의존성
- 서블릿
- 자바
- 우아한세미나
- Spring Batch
- Docker
- 백준
- MSA
- 스프링 부트
- JUnit5
- REDIS
- 프로그래머스
- 우테코
- AOP
- 코드리뷰
- 우아한테크코스
- 트랜잭션
- 세션
- mock
- JPA
- AWS
- 미션
- HTTP
- yml
- CircuitBreaker
- 스프링부트
- Today
- Total
목록의존성 (3)
늘

평소에 runtimeOnly는 런타임 때 작동하겠지, implementation은 gradle이 돌아갈 때부터 작동하겠지라고 대충 생각하고 넘겨와서 그런지 막상 퀴즈를 받으니 대답을 못하겠다.. 이번 기회에 공부하고 정리해보려고 한다. 일단 gradle에 의존성부터 확인해 보았다. 일단 눈에 띄었던 것은 빨간 박스로 표시한 것처럼 runtimeClasspath에 implementation으로 선언된 의존성 파일들이 들어있었다. 대충 implementation은 시작부터 runtime때까지 의존성이 살아있는구나(?)라고 생각했다. CompileClasspath 에러 없이 컴파일을 하기 위해 필요한 클래스와 jar들의 위치를 나타낸다. compileClasspath만 잘 설정했다고 애플리케이션이 잘 작동하는..
왜 스프링은 싱글톤으로 Bean을 만드는가? 스프링은 was 시작과 동시에 Ioc컨테이너에 빈을 생성하고 관리한다. 따라서 서버의 성능을 좋게 하기 위해서 싱글톤 방식을 취한다. 싱글톤 방식을 사용하지 않는다면 매번 Bean을 생성해야 하므로 성능이 안 좋다. 하지만 싱글톤을 사용하면 한 번에 Bean을 여러 개 만들어서 요청이 들어올 때마다 사용하면 되기 때문에 성능이 좋아진다. 저번 게시물에 디자인 패턴에서 싱글톤 패턴을 학습해서 정리했었다. 그런데 이번 스프링 컨테이너의 싱글톤을 공부하면서 같은 싱글톤이라고 생각했는데 스프링의 싱글톤 레지스트리와 자바의 싱글톤 패턴은 다르다고 한다! 싱글톤 레지스트리는 자바의 싱글톤 패턴의 단점을 보완한 것이라고 한다. 자바의 싱글톤패턴의 단점은 아래와 같다. pr..

연관관계는 객체 참조가 있는 상태이다. A -> B로 영구적으로 갈 수 있는 경로가 있다고 보면 된다. class A{ private B b; } 의존관계는 파라미터의 타입이 나오거나, 리턴 타입에 나오거나, 메서드 안에서 그 인스턴스를 생성하면 인스턴스이다. 일시적으로 관계 맺고 헤어지는 관계 class A{ public B method(B b){ return new B(); } } 1. 양방향 의존성을 피하라 - 성능 이슈 - sync를 맞출 때, 많은 버그를 만날 수 있다. 2. 다중성이 적은 방향을 선택하라 - 즉, One-To-Many보단 Many-To-One방향을 잡는 게 더 좋다 - 성능 이슈, 컬랙션의 관계들을 유지하기 위해 노력하는 게 너무 힘들다. 3. 의존성이 필요 없다면 제거하라 4..