일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 |
- 기술공부
- 코테준비
- JPA예제
- JPA스터디
- Kafka
- querydsl
- Flutter
- nestjs스터디
- 자료구조공부
- 스프링 공부
- JPA공부
- 기술면접공부
- 플러터 개발
- 스프링부트공부
- DDD
- 스프링
- 카프카
- JPA 공부
- Axon framework
- 자바공부
- 플러터 공부
- 코테공부
- 알고리즘공부
- 프로그래머스
- 스프링부트
- JPA
- 스프링공부
- nestjs
- nestjs공부
- K8S
- Today
- Total
목록분류 전체보기 (715)
DevBoi
저번 포스팅에서 DI에 대한 작업은 Spring. 에서 DI 컨테이너가 지원해준다고 했다. 좀 더 상세히, 그리고 내가 구현해서 한번 어떻게 동작하는 지 살펴보자 우선 Program이란 클래스가 있다. 해당 클래스에서는 Exam,ExamConsole이라는 인터페이스를 구현하고 있는 구현체를 사용하여, 간략하게 테스트 코드를 작성한다. 이런식으로 사용한다. ExamConsole은 두가지의 구현체를 가진다. 인라인과 그리드 물론 둘다 출력은 잘 된다. ExamConsole exam이라는 녀석에 대한 사용을 중간에 exam = Grid 로 바꿔도 잘 동작한다. 그러면 결국은 이 구현체를 바꿀때마다 소스코드 작업이 이뤄져야 한다는 것이다. 예를 들면 어떤 소스던 어떤 로직이던 특정 부분에서 구현체에 대한 변경을..
스프링에서는 여러가지 부품들에 대한 명세를 개발자가 하고 이를 구현하고 제어를 하는 IOC 컨테이너가 있다. IOC에서는 부품들끼리(class)의 DI 작업을 진행해주고 각 class에 대한 생성 과 삭제 등을 제어한다.(생명주기 관리) IOC는 제어의 역전 즉 이 컨테이너가 각 객체에 대한 생명주기 관리 및 결합을 진행해주기 때문에, 개발자 입장에서는 굉장히 편리하게 개발을 도와주는 프레임 워크라고 느낄수 있는 강력한 요소 중에 하나이다. 결국 이 IOC 컨테이너에서 Spring DI 작업도 진행을 하게 된다. 간단히 개념만 하는 포스팅이라 ㅋ.
DI : 의존성 주입, 종속성 주입 해당 케이스에서는 B는 A의 부품이라고 얘기를 한다.(B는 A에 종속된다.) 해당 DI작업은 부품을 injection하는 작업이 번거롭다는 단점이 있다.(하지만 이 Injection 작업은 스프링이 해준다. 별도 간단하게 명시만 하면 스프링이 알아서 결과물을 알려준다.) DI를 하는이유) Store에서 pencil을 정의 하여, 사용한다. 만약에 Store에서 pencil이 아니라 지우개나 다른 상품을 사고싶다고 하면? 그렇게 되는 경우, pencil을 바꿔야한다. Store의 변경은, 해당 판매 상품을 바꾸고자 할때마다 발생하게 된다. 이러한 경우를 유연성이 떨어지고, 결합도가 높은 관계를 가진다고 이해하면된다. 이러한 문제를 해결하기 위해서는 다형성이라는 개념으로 ..
특정 서비스에 대한 수정이 발생한다고 생각해보자 소스코드에서 가장 큰 고려사항은, 결합력에 관련된 내용인데, 결합력이 어떤 것이냐.... 결합도가 높은 소스코드의 경우 A.class, B.class라고 예를 들어보겠다. A.class가 변경이 발생되면, B.class도 무조건 수정이 되어야 한다. 하지만 결합도가 낮은경우, A.class가 변경이 발생했다고 한들, B.class에 영향도 없고 변경도 필요없다. 이러한 개념에서 나온것이 인터페이스라는 것이다. 결합도가 높은 시스템 A a = new A(); a.setX(); 결합도가 낮은 시스템 X x = 외부파일.class x.setX(); X는 특정 공통 소스들을 구현하기 위한 인터페이스이고, A는 그냥 객체라고 생각하면 된다. 결합도가 높을 경우, A..
HttpSessiondms Java 인터페이스 이며, 이를 사용하여, 세션을 제어할수 있다. Session은 쿠키의 트래픽 이슈와 cookie변경으로 인한 보안 issue를 해결하기 위해 등장했다. 세션의 개념 1.session은 사전적 의미로 서버와 클라이언트 간의 반 영구적으로 상호작용하는 정보 교환이다. 2.session은 server로 요청 하는 client를 구별하기 위해 server에 저장되는 정보입니다. - session은 client에 저장되는 쿠키와 다르게 server에 저장되므로 관리가 용이하고 효율적이며 보안에 강합니다. 3. server는 client request에 session-id를 생성하여 server와 client 브라우저 메모리에 쿠키로 저장한다. -위 쿠키는 일반적인 쿠..
스프링 시큐리티는 각각의 역할에 맞는 작업을 처리하는 여러개의 필터들이 체인형태로 구성되어, 순서에 따라 순차적으로 수행된다. 스프링 시큐리티의 특징 및 장점 -보안과 관련하여 체계 적으로 많은 옵션을 제공하여 편리하게 사용할 수 있다. -Filter 기반으로 동작하여, MVC와 분리하여 동작이 가능하다. -어노테이션을 통한 간단한 설정이 가능하다. -스프링 시큐리티는 기본적으로 쿠키 + 세션으로 동작한다. 스프링 시큐리티의 기본 필터 종류이다. -SecurityContextPersistenceFilter : SecurityContextRepository에서, 해당 SecurityContext를 저장하고 로드하는 역할을 한다. -LogoutFilter : Logout 으로 지정된 가상의 url 이 있어,..
컴포넌트 스캔 : 빈으로 등록될 준비가 된 클래스들을 스캔하여, 빈으로 등록해주는 과정이다. (@Controller, @Service, @Component, @Repository 등을 빈으로 등록해주는 것이다.) 우선 ComponentScan이 어디에 사용되고있는지를 보자 우선 기본 SpringbootApplication 어노테이션을 보면, ComponentScan을 사용해서 해당 컴포넌트들을 스캔한다. 이때, 특정 경로를 제외할수도있고 필터에 포함할수도있다. 해당 기본으로 basePackages 하위 패키지의 것들은 다 스캔한다. 하지만 별도로 경로 패턴을 지정하여, 스캔할수도있다. 컨트롤러는 Component를 선언한 별도의 스테레오타입의 어노테이션이다. 해당 컴포넌트 스캔의 경로는 자바파일로도, x..
제네릭은 이전에 공부 했듯이, 특별히 어떤 클래스를 사용할떄, 타입에 대한 제약을 걸어두지 않는 것이다. 그런데, 이렇게 제약조건 없이 사용하게 된다면, String 변수에 Integer가 들어가도런타임시에 발견할수 없다. 그래서 제네릭에서는 제약조건을 와일드 카드라는 개념으로 걸어둘수 있다. 간단한 예를 보면서 이해해보자 FuncUtil 이라는 클래스는 utilList라는 녀석을 넣을때, Test1의 하위로 제약을 둔다면, 실제 메인에서 Test2라는 클래스로 걸때 오류가 발생하면서 런타임시에 발견할수 있게 된다. 만약에 Test2가 Test1을 상속 받게된다면, 해당 오류는 사라지게 된다. 자 , 그러면 와일드 카드에 대한 정확한 이해를 해보도록 하자 제네릭에서 만약에 특정 제약조건을 무조건 받지 않..
자바 자료형에는 기본형과 참조 타입이 있다. Primitvie Type 과 Wrapper Type 이라고도 얘기한다. 1) Primitive Type byte, short,int,long 등이 있다. null이 올수없고 단순 자료형이다. 값의 비교 연산을 위해서는 ==을 사용한다. 단순 값비교가 가능하다. 2) wrapper Class Byte, Short,Integer등이 온다. 해당 Wrapper Class는 Primitive Type을 객체화 한것이다. Null 이 올수 있고, 값에 대한 일치 비교를 위해서는, ==을 사용하면 hashcode가 비교대상으로 잡히기 때문에 equals를 사용해야한다. Boxing : 기본형 타입을 참조형 타입으로 변경하는 것 Unboxing : 그반대 일반적으로 사용..
페이징 교체 알고리즘은 페이징기법으로, 메모리를 관리하는 운영체제에서 페이지의 부재가 발생하여 새로운 페이지를 기존의 어떤 페이지와 교체할 것인가? 를 결정 하기 위해 필요한 알고리즘이다. FIFO 알고리즘 : 페이지가 적재된 시간을 기준으로 교체되는 알고리즘 (First in First out 관련 알고리즘 이다. ) - 가장 오래된 페이지가 교체되나, 중요한 페이지가 오래되었다는 이유로 교체될 수 있기 때문에 불합리 하다. LFU 알고리즘 : 가장 적게 사용된 페이지를 교체하는 알고리즘, 참조될 가능성이 많은데 가장 적게 사용되었다는 이유로 최근에 사용되었지만 교체될 가능성이 있다. 참조된 횟수를 증가 시키기 때문에 오버헤드를 발생시킨다. LRU 알고리즘 : 가장 오랫동안 참조되지 않은 페이지를 교체..