프록시 팩토리 스프링은 유사한 구체적인 기술들이 있을 때, 그것들을 통합해서 일관성 있게 접근할 수 있고 편리하게 사용할 수 있도록 추상화된 기술을 제공한다. 동적 프록시를 통합해서 프록시 팩토리라는 기능을 제공하는데, 프록시 팩토리는 인터페이스가 있으면 JDK 프록시를 사용하고, 구체 클래스가 있다면 CGLIB를 사용한다. 이 내용은 설정을 통해 변경할 수도 있다. Advice Advice는 프록시에 적용하는 부가 기능 로직이다. JDK 동적 프록시가 제공하는 InvocationHandler와 CGLIB가 제공하는 MethodInterceptor의 개념과 유사한데, 이 둘을 추상화 한 것이다. 프록시 팩토리를 사용한다면 이 둘 대신에 Advice를 사용하면 된다. Advice를 만드는 방법은 다양하지만..
리플렉션 리플렉션은 클래스나 메서드의 메타정보를 동적으로 획득하고, 코드도 동적으로 호출할 수 있도록 하는 API이다. 리플렉션 적용 전 @Slf4j public class ReflectionTest { @Test void reflection0() { Hello target = new Hello(); // 공통 로직1 시작 log.info("start"); String result1 = target.callA(); // 호출하는 메서드가 다름, 동적 처리 필요 log.info("result={}", result1); // 공통 로직1 종료 // 공통 로직2 시작 log.info("start"); String result2 = target.callB(); // 호출하는 메서드가 다름, 동적 처리 필요 lo..
템플릿 콜백 패턴 프로그래밍에서 콜백(callback) 또는 콜애프터 함수(call-after function)는 다른 코드의 인수로서 넘겨주는 실행 가능한 코드를 말한다. 콜백을 넘겨받는 코드는 이 콜백을 필요에 따라 즉시 실행할 수도 있고, 아니면 나중에 실행할 수도 있다. 좀 더 풀어서 얘기하면, callback은 코드가 호출(call)은 되는데 코드를 넘겨준 곳의 뒤(back)에서 실행된다는 것이다. 템플릿 콜백 패턴은 GOF 패턴은 아니고, JdbcTemplate, RestTemplate, TransactionTemplate, RedisTemplate과 같이 스프링 내부에서 자주 사용된다. 이전에 살펴본 전략 패턴에서 템플릿과 콜백 부분이 강조된 패턴이라 생각하면 된다. 이번에도 역시 요리사들의..
전략 패턴 GOF에서는 전략 패턴을 "알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다"고 말한다. 이전에 템플릿 메서드 패턴은 부모 클래스에 변하지 않는 템플릿을 두고, 변하는 부분을 자식 클래스에 두어서 상속을 사용해서 문제를 해결했다. 전략 패턴은 변하지 않는 부분을 Context라는 곳에 두고, 변하는 부분을 Strategy라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다. 상속이 아니라 위임으로 문제를 해결하는 것이다. 이번에도 이해를 돕기 위해 요리사들의 요리 시작부터 완성하기까지의 시간을 측정해야 한다고 가정해보고, 전략 패턴을 적용하여 구현해보자. 전략 패턴..
템플릿 메서드 패턴 GOF에서는 템플릿 메서드 패턴을 "작업에서 알고리즘의 골격을 정의하고 일부 단계를 하위 클래스로 연기한다. 템플릿 메서드를 사용하면 하위 클래스가 알고리즘의 구조를 변경하지 않고도 알고리즘의 특정 단계를 재정의할 수 있다"고 말한다. 이 말은 부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다. 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있어 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다. 이해를 돕기 위해 요리사들의 요리 시작부터 완성하기까지의 시간을 측정해야 한다고 가정해보고, 템플릿 메서드 패턴을 적용하여 구현해보자. 먼저 템플릿 메서드 패턴을 적용하기 전의 코드다...
동시성 문제 스프링은 기본적으로 싱글톤 빈을 등록한다. 지역변수는 쓰레드마다 각각의 다른 메모리 영역이 할당되기 때문에 동시성 문제가 발생하지 않지만, 싱글톤으로 등록된 인스턴스의 필드를 여러 쓰레드가 동시에 접근하는 경우 문제가 발생한다. 또한 동시성 문제는 값을 읽기만 해선 발생하지 않고, 어디선가 값을 변경하기 때문에 발생한다. 아래와 같은 경우는 동시성 문제가 발생하는 코드이다. 코드를 살펴보며 문제를 확인해보자. FieldService 클래스 @Slf4j public class FieldService { private String nameStore; public String logic(String name) { log.info("저장 name={} nameStore={}", name, nameS..
트랜잭션 트랜잭션은 ACID라 하는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장해야 한다. 원자성 : 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공 하거나 모두 실패해야 한다. 일관성 : 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다. 격리성 : 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록 해야 한다. 격리성은 동시성과 관련된 성능 이슈로 인해 트랜잭션 격리 수준(Isolation level) 을 선택할 수 있다. 지속성 : 트랜잭션을 성공..
JDBC가 등장하게 된 이유 클라이언트가 애플리케이션 서버를 통해 데이터를 저장 또는 수정하면, 애플리케이션 서버는 아래와 같은 순서로 데이터베이스를 사용한다. 커넥션 연결 : 주로 TCP/IP를 사용해서 커넥션을 연결한다. SQL 전달 : 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다. 결과 응답 : DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다. 과거에는 각 벤더사마다 커넥션을 연결하고, SQL을 전달 및 결과를 응답 받는 방법이 모두 다르기 때문에, 데이터베이스를 다른 벤더사로 변경하면 애플리케이션 코드도 그에 맞게 수정해줘야 하는 단점이 존재하였다. 또한 각 벤더사에 따라 커넥션 연결방법, SQL 전달방법,..
Config 기반 Bean 설정 @Configuration public class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(memberRepository()); } @Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); } @Bean public OrderService orderService() { return new OrderServiceImpl(memberRepository(), discountpolicy()); } @Bean public DiscountPolicy discountpolic..
@Entity @Entity가 붙은 클래스는 JPA가 관리하게 된다. JPA를 사용해서 테이블과 매핑할 클래스는 @Entity를 필수로 선언해야 한다. 하이버네이트는 프록시 DB 연산 결과를 상속한 클래스의 기본 생성자를 호출하여 매핑한다. 이때, 알맞게 결과 값을 넣어주기 위해서는 public 또는 protected 레벨의 기본 생성자가 필요하다. @Entity public class Member{ @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; public Member(){ } public Member(final Long id, final String name){ this.id = ..
- Total
- Today
- Yesterday
- 문자열
- 자료구조
- 릿코드
- webflux
- 노마드코더
- mysql 8.0
- spring boot
- leetcode
- 김영한
- MySQL
- 코틀린
- 구현
- 노마드
- 백준
- 리팩토링
- 알고리즘
- Algorithm
- kotlin
- 파이썬
- 스프링 부트
- 인프런
- Real MySQL
- 북클럽
- Spring
- 스프링
- 데이터베이스
- 그리디
- 정렬
- 코테
- 스프링부트
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |