![[Spring 핵심원리 - 고급] 프록시 및 데코레이터 패턴(디자인 패턴)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcRmpu7%2FbtsNi0kOFsx%2FmKjUSwV6cJmufgKmUZ6K41%2Fimg.png)
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.프록시프록시 개념클라이언트와 서버 개념에서 일반적으로 클라이언트가 서버를 직접 호출하고, 처리 결과를 직접 받는다. 이것을 직접 호출이라 한다. 그런데 클라이언트가 요청한 결과를 서버에 직접 요청하는 것이 아니라 어떤 대리자를 통해서 대신 간접적으로 서버에 요청할 수 있다.예를 들어서 내가 직접 마트에서 장을 볼 수도 있지만, 누군가에게 대신 장을 봐달라고 부탁할 수도 있다.여기서 대신 장을 보는 대리자를 영어로 프록시(Proxy)라 한다. 객체에서 프록시가 되려면, 클라이언트는 서버에게 요청을 한 것인지, 프록시에게 요청을 한 것인지 조차 몰라야 한다.쉽게 이야기해서 서버와 프록시는 같은 인터페이스를 사용해야 ..
![[Spring 핵심원리 - 고급] 전략 패턴(디자인 패턴)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FERrD8%2FbtsNeQQ7IYW%2Fx7Nhzp65euU2PcfFMy1ZF0%2Fimg.png)
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.전략 패턴선 조립 후 실행GOF 디자인 패턴에서 정의한 전략 패턴의 의도는 다음과 같다.고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자.전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다. 전략 패턴(Strategy Pattern)이란 행동(알고리즘)을 객체로 분리하여 동적으로 교체할 수 있도록 해주는 디자인 패턴이다.쉽게 말해서, 상황에 따라 알고리즘이나 기능을 바꾸고 싶을 때 유용한 방법이다.행동(전략)을 인터페이스로 정의하고, 그 행동을 구현한 여러 클래스를 만든 다음, 컨텍스트(Context)에서 그 전략 객체를 주입받아 사용하는 방식이다.public..
![[Spring 핵심원리 - 고급] 템플릿 메서드 패턴(디자인 패턴)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2Fbk4XcL%2FbtsNfR1IGrL%2FKfW3KqAZFF2vtgtO95Dk20%2Fimg.png)
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.템플릿 메서드 패턴템플릿 메서드 패턴(Template Method Pattern)은 상위 클래스에서 알고리즘의 뼈대를 정의하고, 일부 세부 처리는 하위 클래스에 위임하는 디자인 패턴이다.즉, 공통된 로직의 흐름(템플릿)은 상위 클래스에서 고정하고, 변하는 부분만 하위 클래스에서 구현하게 만드는 방식이다.변하는 것과 변하지 않는 것을 분리좋은 설계는 변하는 것과 변하지 않는 것을 분리하는 것이다. 이 둘을 분리해서 모듈화해야 한다.템플릿 메서드 패턴(Template Method Pattern)은 이런 문제를 해결하는 디자인 패턴이다. 상위 클래스(추상 클래스)전체 흐름을 정의하는 템플릿 메서드 보유공통 코드 + 추..
![[Spring 핵심원리 - 고급] 쓰레드 로컬(Thread Local)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbrYFzu%2FbtsNfwC8WZm%2FsQKvnhxZIanRKLRAa3zztK%2Fimg.png)
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.동시성 이슈동시성 이슈란, 하나의 자원에 여러 스레드가 동시에 접근하여 값을 수정하거나 조회하는 과정에서, 개발자가 의도한 대로 동작하지 않는 현상을 말한다.스프링에서 빈은 기본적으로 싱글톤 스코프이므로, 여러 요청에서 동일한 인스턴스를 공유하게 된다.이때, 싱글톤 빈 내부에 상태를 저장하는 필드가 있다면, 동시에 여러 요청이 들어올 경우 서로의 요청 데이터가 충돌하면서 동시성 이슈가 발생할 수 있다.이러한 상황에서는 ThreadLocal을 사용하여 각 쓰레드마다 독립적인 저장 공간을 제공함으로써 문제를 해결할 수 있다.import lombok.extern.slf4j.Slf4j;@Slf4jpublic class ..
![[JPA] @Builder.Default](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FCobk0%2FbtsM6iG3kXO%2FSxKFjCenvMLgkUsT81OXq0%2Fimg.png)
@Builder.Default는 Lombok의 @Builder와 함께 사용할 때, 기본값이 무시되지 않도록 유지시켜주는 어노테이션이다.일반적으로 @Builder를 사용하면, 필드에 직접 초기화한 값이 무시된다.@Builderpublic class Product { private String name; private int price = 1000;}위와 같이 price = 1000을 설정했더라도, Product.builder().build()를 실행하면 price는 0이 된다.즉, 기본값 1000이 무시되는 것. 해결 방법@Builderpublic class Product { private String name; @Builder.Default private int price = ..
![[JPA] 엔티티 클래스에서 @Builder 위치](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FDW2Rs%2FbtsM7gHZ67o%2FDIfjTjnmMtzbGUJL7rUeK0%2Fimg.png)
@Builder를 생성자 위에 두는 방식@Getter@NoArgsConstructor(access = AccessLevel.PROTECTED)@Entitypublic class Product extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String productNumber; private String name; private int price; @Builder // 생성자 위에 빌더 public Product(String productNumber, String name, int price) { this.produc..
![[JPA] 엔티티 공통 필드 상속(@MappedSuperclass)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2F7aUcA%2FbtsM6Zmep1n%2F9U0FJGLbH4OAjVISMFOlp0%2Fimg.png)
@MappedSuperclass엔티티마다 생성 날짜와 수정 날짜가 존재한다고 가정하면, 모든 엔티티에 해당 코드를 넣는 것은 비효율적이다.따라서 아래의 코드를 통해서 공통 필드를 상속받게 할 수 있다.@Getter@MappedSuperclass@EntityListeners(AuditingEntityListener.class)public abstract class BaseEntity { @CreatedDate private LocalDateTime createdDateTime; @LastModifiedDate private LocalDateTime modifiedDateTime;}공통 필드(생성일시, 수정일시)를 모든 엔티티에서 자동으로 사용하고 싶을 때이 BaseEntity를 상속받..
![[Spring] 스프링 컨테이너(IoC, DI 컨테이너)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbKs3H1%2FbtsM46zw4cc%2Fq2SAe2XuKijZ8Ou4nTOlik%2Fimg.png)
이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.SRP (Single Responsibility Principle) :하나의 클래스는 오직 하나의 책임만 가져야 한다.OCP (Open/Closed Principle) :소프트웨어 요소는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다.LSP (Liskov Substitution Principle) :자식 클래스는 부모 클래스의 기능을 대체할 수 있어야 한다.ISP (Interface Segregation Principle) :특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.DIP (Dependency Inversion Principle) :구체화가 아닌 추상화에 의존해야 한다. OCP..