devlog

스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); 스프링 컨테이너에는 스프링 빈 저장소가 있는데 여기엔 빈 이름과 빈객체를 테이블로 저장한다. 그 후 인자로 넘어온 AppConfig.class의 구성 정보를 활용한다. AppConfig.class의 Bean으로 설정된 것들을 스프링 빈 저장소에 저장한다. 여기서 빈 이름은 메서드의 이름인데 이를 직접 부여할 수 도 있다. 하지만 이는 잘 사용하지 않는다고 한다. 여기서 빈 이름은 항상 다른 이름을 부여해야 한다. 그 후 스프링 빈 의존관계를 설정 정보를 참고해서 주입한다. 출처 : 인프런 스프링 핵심 원리 - 기..

스프링으로 전환하기 위해서는 어노테이션을 붙여주어야 한다 이제 AppConfig를 이용하여 주입했던 부분을 주석 처리하고 스프링을 이용하자 ApplicationContext는 스프링의 컨테이너이다. AnnotationConfigApplicationContext는 Annotation 기반의 자바 설정 클래스로 스프링 컨테이너를 만든다 @Configuraion이 붙은 설정 정보를 사용한다. 인자로 AppConfig.class를 넘겨주어서 AppConfig를 활용하여 등록한다. 여기에 있는 @Bean이 붙은 함수들의 반환 객체들을 다 등록시킨다. 이때 빈의 이름은 함수의 이름을 사용한다. 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다. getBean 함수를 통해 DI를 해준다. 이때 함수는 두 개의 인..

https://salmon16.tistory.com/75 OCP, DIP 원칙이 위배되는 역할과 구현 분리 역할과 구현을 분리하고 다형성을 이용하여 잘 설계를 해도 OCP, DIP 원칙을 위반할 수 있다 . 아래 예시를 보자 OrderServiceImpl은 DiscountPolicy라는 인터페이스에 의존하면서 DIP를 잘 지킨 것 같지만 salmon16.tistory.com 위 링크 문제를 해결하기 위해 구현 객체를 생성하고 연결하는 AppConfig클래스를 만들자. Appconfig는 구현 객체를 생성하여 return 해 준다. 이렇게 작성을 하고 각 Impl클래스의 생성자를 추가하면 OCP, DIP를 위배하지 않게 만들 수 있다. 예로 MemberServiceImpl 코드를 보면 더 이상 구현에 의존..

역할과 구현을 분리하고 다형성을 이용하여 잘 설계를 해도 OCP, DIP 원칙을 위반할 수 있다 . 아래 예시를 보자 OrderServiceImpl은 DiscountPolicy라는 인터페이스에 의존하면서 DIP를 잘 지킨 것 같지만 구현 클래스(Fix, Rate DiscountPolicy)에도 의존하고 있다 그러므로 FixDiscount에서 RateDiscount로 변경하려면 OberServiceImpl 코드를 변경 해야한다 (FixDiscountPolicy주석 처리하고 RateDiscountPolicy 할당) 기대했던 의존관계는 OrderServiceImpl는 DiscountPolicy인터페이스만 의존하기를 원했다 그렇다고 코드를 아래와 같이 수정을 하면 구현체가 없어서 null point except..

비율에 따른 할인 함수코드를 작성 중 10% 비율로 잘 할인이 되는지 궁금해져서 테스트를 해 보려고 한다 할인 정책에는 VIP 등급인 경우 10% BASIC 등급인 경우에는 할인이 되지 않는다. VIP 등급일 때 과연 10% 할인이 잘 되는지 확인을 하기 위해 윈도우에서 ctrl + shift + t를 누르면 자동으로 테스트 class를 만들어 준다. 테스트 코드를 작성할 때 VIP인 등급만을 테스트를 하는 것이 아닌 반대 경우도 해 주어야 한다. 여기서 코드를 좀 더 간결하기 위해 자바의 static import를 사용하면 좋다. Assertions 코드에 커서를 위치 시키고 윈도우에선 alt + enter를 누르면 된다. 출처 : 인프런 스프링 핵심 원리 - 기본 편 김영한

회원을 가입하고 아이디를 통해 조회할 수 있는 프로그램에서 테스트 코트를 작성해 보자 이렇게 그냥 일반적인 자바 코드를 통해 new member와 findMember가 같은지를 print 된 것을 직접 보며 findMemer 함수가 잘 작동하는지 가입이 잘 되었는지 확인을 할 수 있지만 이는 좀 더 복잡한 테스트 코드를 작성하게 되면 복잡하고 개발자가 직접 print 문을 확인해야 한다는 단점이 있다 인텔리제이에서 테스트를 하고 싶으면 테스트하고 싶은 클래스에서 ctrl + shift+ v를 누르면 쉽게 테스트 코드를 작성할 수 있다. 그래서 JUnit을 활용한 테스트 코드를 작성해 보자 JUint을 활용하기 위해서 import를 해주어야 한다. import org.junit.jupiter.api.Tes..

SRP 단일 책임 원칙 (Single responsibility principle) 한 클래스는 하나의 책임만 가져야 한다. 중요한 기준은 변경이다 . 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이라고 할 수 있다. OCP 개방-폐쇄 원칙(Open/Closed principle) 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다 이 코드에서 MemoryMemberRepository. 에서 jdbcMemberRepository로 변경할 때 클라이언트(MemberService)가 구현 클레스를 직접 선택하는데 이는 ocp 원칙을 지키지 못 한 경우이다. 이를 해결하기 위해 스프링이 도와준다. LSP 리스코프 치환 원칙(Liskov substitution principle..

객체 지향의 특징 중 다형성에 주목하자 다형성을 쉽게 이해하기 위해 무대 공연을 예시로 들어보자 다형성은 역할과 구현을 구분해야 한다. 위 그림에서 로미오 역할은 장동건, 원빈 중 누가 하더라도 상관이 없다 줄리엣도 김태희, 송혜교 중 누가 하더라도 동일하게 줄리엣의 역할을 수행할 수 있다 이것이 다형성이다 역할만 잘 만든다면 장동건으로 로미오를 구현하든 원빈으로 구현하든 로미오의 역할을 수정 없이 구현 부분을 교체할 수 있다는 장점이 있다. 이제 이를 자바에 적용시켜 보자 MemberService라는 클라이언트가 있고 MemberRepository라는 interface와 Memory, jdbc로 각각 구현한 MemberRepository가 있다. MemberService는 MemberRepository..