Kim-Baek 개발자 이야기

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에는 컨테이너에 등록된 모든 빈을 조회해보았다. 이번에는 하나의 빈을 조회하는 방법들에 대해서 기본적으로 사용되는 방식들에 대해서 알아볼 수 있도록 하겠다. 먼저 이전과 동일하게 스프링 컨테이너인 ApplicationContext의 구현체를 만들어서 빈을 가져오게 된다. 줄여서 ac 라고 사용할 수 있도록 하겠다. ac 에서 빈을 가져오는 메소드에 대해서 알아보겠다. ac.getBean ( 빈이름, 타입 ) ac.getBean ( 타입 ) 위의 두 가지 방식으로 빈을 가져올 수 있는데, 상황에 맞게 본인이 필요한 것을 쓰면 되겠다. 그런데 조회 대상의 스프링 빈이 없으면 어떻게 될까? NoSuchBeanDefin..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 스프링을 사용해서 빈을 어떻게 등록하는지 알게되었습니다. 실제로 등록이 되었다고는 하는데, 정말 등록이 된게 맞는지 직접 확인을 해볼 필요가 있습니다. 그래서 컨테이너에 등록된 빈을 한번 조회해보도록 하겠습니다. package core.order.beanfind; import core.order.AppConfig; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.config.BeanDefinition; import org.springframework..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이전에 AppConfig를 스프링으로 전환하는 과정을 진행했다. 스프링 컨테이너가 이제 그 역할을 해주는 것이라고 설명을 하였는데, 이번에는 스프링 컨테이너가 생성되는 과정을 한번 살펴보고자 한다. ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext 를 우리는 스프링 컨테이너라고 한다. ApplicationContext 는 인터페이스이다. 그 말은 여러가지 구현체를 사용할 수 있다는 뜻이다. 스프링 컨테이너는 XML을 기반으로 할 수도 있고, 애노테이션 기반의 자바..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 강의의 내용은 순수하게 자바만 사용해서 하는 것이였다. 그렇다면 스프링을 사용하면 어떤 좋은 점이 있는지를 알아야 하지 않을까? 이번부터 지금까지 생성한 내용을 스프링으로 변경하면서 진행을 하게 된다. 먼저 AppConfig를 스프링 기반으로 변경한다. package core.order; import core.order.discount.DiscountPolicy; import core.order.discount.RateDiscountPolicy; import core.order.member.MemberRepository; import core.order.member.MemberService; import co..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이번에는 IoC와 DI, 컨테이너에 대해서 설명을 한다. 스프링을 하는 사람들은 다들 많이 들어본 내용일텐데, IoC, DI, AOP까지 해서 스프링 관련된 중요한 개념이라고 생각된다. 어려운 내용은 아니고 지금까지 우리가 강의를 통해서 해왔던 내용들이 다 여기에 담겨있어서 어떤 내용들과 매칭되는지 다시한번 기억을 되살려서 살펴보도록 하자. 제어의 역전 IoC ( Inversion of Control ) 우선 제어의 역전을 알아보기 전에 기존 프로그램의 동작과정을 살펴보도록 하자 클라이언트가 필요한 서버 구현 객체를 생성하고, 연결하고 실행했다. 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 일반적으로 이게 개..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 만들어오면서 적용한 객체 지향 설계의 원칙에 대해서 살펴보고자 한다. 객체 지향 설계의 5가지 원칙은 이전에 작성한 글에도 잘 정리가 되어있으니 생각이 나지 않는다면 해당 내용을 다시한번 보는 것을 권장한다. 1. SRP ( 단일 책임 원칙 ) - 한 클래스는 하나의 책임만 가져야 한다는 원칙이다. 우리가 처음에 만들었던 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고 실행까지 하는 다양한 첵임을 가지고 있었다. SRP 원칙에 따라서 관심사를 분리하게 된다. 더 이상 클라이언트는 구현 객체를 생성하거나 연결하지 않고, AppConfig 가 해당 역할을 담당하게 된다 클라이언트 객체는 실행하는 책임만 담..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이제는 이전에 해보려고 했었던 할인 정책을 변경을 해보고자 한다. 기존에는 정액 할인 정책을 사용하여 어떤 주문이 들어오더라도 1000원만큼만 할인이 이루어졌다. 바꾸려고 하는 것은 정률 할인 정책으로 주문가격의 10%를 할인해주는 정책이다. FixDiscountPolicy -> RateDiscountPolicy 로 변경을 하게 되는데 이제 어떤 부분을 바꿔주면 되는지 살펴보자. 우리는 AppConfig를 만들게 되면서 애플리케이션이 실제 로직이 수행되는 사용 영역과 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 현재 애플리케이션의 구조는 이와 같은 상태라고 할 수 있다. 그렇다면 할인정책은..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 AppConfig를 만들어서 관심사를 분리해서, 각자 역할들이 본인들의 역할의 수행에만 집중할 수 있는 코드를 완성했다. 그런데 다시한번 보면 AppConfig가 중복이 있고, 역할에 따른 구현이 잘 안보이는 문제가 있다. 우리가 원하는 그림은 이런 것 일 것이다. 역할이 있고 구현 객체들이 어떤 것인지 명확하게 보이는 그림이다. package core.order; import core.order.discount.FixDiscountPolicy; import core.order.member.MemberService; import core.order.member.MemberServiceImpl; import c..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 다시 처음으로 돌아가서 한번 생각을 해보자. 공연에서 각각 인터페이스는 배역이라고 할 수 있다. 그렇다면 이 배역을 연기하는 배우는 누가 선택을 하게 되는게 맞을까? 현재까지 작성한 코드는 로미오와 줄리엣이라는 공연에서, 로미오 역할을 하는 배우인 레오나르도 디카프리오 ( 구현체, 배우 ) 가 줄리엣 역할을 하는 여자 주인공 ( 구현체, 배우 )를 직접 캐스팅하는 것과 마찬가지인 내용이다. 디카프리오는 직접 공연도 하고, 여자 주인공도 캐스팅하는 다양한 역할을 하고 있는 셈이다. 관심사의 분리 - 배우는 자신이 맡은 배역을 수행하는 역할만 수행하는 데 집중하는 것이 맞다. - 디카프리오는 상대 여자 주인공이 어떤 사람..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 새로운 할인 정책을 만들어서 테스트까지 했으니 이제 실제 코드에 적용을 해보는 시간이다. public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } FixDicountPolicy를 RateDiscountPolicy 를 위와같이 적용하면 된다. 이 코드는 어떤 상태라고 생각이 될까? 역할과 구현을 분리한 것은 ..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 할인 정책은 얼마를 주문하던 1000원을 할인해주는 정액 할인 정책이였다. 하지만 맨 처음 기획을 보면 이 정책은 언제든지 바뀔 수 있는 것이였다. 기획자가 이제 1000원이 아니라 주문 금액의 10%를 할인해주는 정률 할인 정책으로 변경해달라는 요구가 들어왔다. 그렇다면 개발자인 우리는 이것을 변경해서 적용해볼 수 있도록 하자 . 기획자는 애자일 소프트웨어 개발 선언에 따라서 계획을 따르기보다는 변화에 대응하라는 말을 한다. 열받는 말이지만 우리도 이 말에 맞게 대응을 해볼 수 있도로 한다. package core.order.discount; import core.order.member.Grade; impo..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 주문과 할인 도메인을 만들었으니 이제 제대로 동작하는지 테스트를 해볼 차례이다. package core.order; import core.order.member.*; import core.order.member.MemberService; import core.order.member.MemberServiceImpl; import core.order.order.Order; import core.order.order.OrderService; import core.order.order.OrderServiceImpl; public class OrderApp { public static void main(String[] args..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 주문과 할인 도메인에 대한 설계를 끝냈으니, 개발을 진행해보도록 하겠다. 이전과 마찬가지로 깃헙에 브랜치를 새로 따서 매 단계마다 올리고 있으니, 필요하신 분은 아래에 링크를 둘테니 확인하면 된다. package core.order.discount; import core.order.member.Member; public interface DiscountPolicy { /** * * @return 할인 대상 금액 */ int discount(Member member, int price); } 먼저 할인 정책 인터페이스이다. 할인 대상 금액을 리턴해주는 메소드 하나만 가진다. package core.order.discou..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이전에 작성한 내용까지 해서 회원 도메인에 대한 개발이 완료되었다. 하지만 회원만 있다고 서비스가 만들어지는 것은 아니고, 다른 도메인이 필요하다. 그래서 이번에는 주문과 할인 도메인에 대해서 설계를 해보겠다. 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. 할인 정책은 모든 VIP는 1000원을 할인해주는 고정 금액 할인을 적용해달라. (나중에 변경 될 수 있다.) 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책을 아직 정하지 못했고, 오픈 직전까지 고민을 미루고 싶다. 최악의 경우 할인을 적용하지 않을 수 도 있다. (미확정) 주문과 할인 정책의 요구사항은..