점이 모여 선이 된다

스프링 핵심 원리-기본편 섹션 4.스프링 컨테이너와 스프링 빈

xandxlass — Tue, 26 Mar 2024 10:58:21 +0900

컨테이너에 등록된 모든 빈 조회

빈 이름으로 조회할 경우

@Test
@DisplayName("빈 이름으로 조회")
void findBeanByName() {
    MemberService memberService = ac.getBean("memberService", MemberService.class); //MemberService, 즉 인터페이스로 조회함 그러면 이 인터페이스의 구현체가 대상이 된다
    assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    //isInstanceOf() 연산자:해당 타입의 인스턴스인지를 비교하는 메서드, 객체가 특정클래스나 인터페이스로부터 생성된 것인지를 판별
}

멤버서비스가 멤버 서비스 인플의 인스턴스면 성공

구체 타입으로 조회할 경우

@Test
@DisplayName("구체 타입으로 조회")
void findBeanByName2() {
    MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class); //스프링 컨테이너에 MemberServiceImpl이 등록되어있으면 조회가 됨
    assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
}

@Configuration
public class AppConfig { //나의 애플리케이션 전체에 대해 설정하고 구성하는 공간

    //멤버서비스에 대한 구현을 나의 애플리케이션에서는 멤버서비스 인플을 쓸거야
    @Bean
    public MemberService memberService() { //AppCofig를 쓸때 멤버서비스 씀
        return new MemberServiceImpl(MemberRepository()); //멤버서비스 구현체인 객체가 생성됨
    }

반환타입 MemberService이 아니라 MemberServiceImpl해도 상관없다.

스프링빈에 등록된 인스턴스 타입을 보고 결정하기 때문에 꼭 여기있는 인터페이스( MemberService) 아니어도 된다. MemberServiceImpl 해도 된다.

    /**
     * 구체적인건 좋지 않다
     * 역할과 구현을 구분해야한다. 항상 역할에 의존해야한다.
     * 근데 이건 구현에 의존한게됨
     */

빈 이름으로 조회할 경우

@Test
@DisplayName("빈 이름으로 조회X")
void findBeanNameX() { //항상 성공테스트뿐만 아니라 실패 테스트도 만들어야함
    MemberService xxxx = ac.getBean("xxxxx", MemberService.class);
}

NoSuchBeanDefinitionException : No bean named 'xxxxx' available 에러가 뜬다.

@Test
@DisplayName("빈 이름으로 조회X")
void findBeanNameX() { //항상 성공테스트뿐만 아니라 실패 테스트도 만들어야함
    assertThrows(NoSuchBeanDefinitionException.class,
            () -> ac.getBean("xxxxx", MemberService.class));  //무조건 이 예외가 터져야 성공한다는 뜻  static import : 알트+엔터

}

() -> ac.getBean("xxxxx", MemberService.class)이 실행되면 NoSuchBeanDefinitionException.class 예외가 실행되어야 한다. 이 예외가 터지면 성공, 아니면 실패

동일한 타입이 둘 이상

class ApplicationContextSameBeanFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SameBeanConfig.class);

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByTypeDuplicate() {
        MemberRepository bean = ac.getBean(MemberRepository.class); //타입만 지정한 경우 예외 생김
    }

    @Configuration
    static class SameBeanConfig { //테스트하려고 하는거니까 AppConfig를 손대지 않고 안에서만 쓰기 위해 SameBeanConfig를 만듦
        //클래스 안에서 static을 쓴다는건 이 안에서만 쓰겠다는 뜻
        @Bean //빈의 이름이 다르고 인스턴스 타입이 같을 수 있다
        public MemberRepository memberRepository1() {
            return new MemoryMemberRepository();
        }

        @Bean
        public MemberRepository memberRepository2() {
            return new MemoryMemberRepository();
        }
    }

}

NoUniqueBeanDefinitionException 유니크 하지 않다, 즉 중복이 있다는 예외가 발생함

스프링 빈 조회 - 상속 관계

1.반환타입이 DiscountPolicy 일 경우

@Bean
public DiscountPolicy rateDiscountPoilicy(){
    return new RateDiscountPolicy();
}

2.반환타입이 RateDiscountPolicy 일 경우

@Bean
public RateDiscountPolicy rateDiscountPoilicy(){
    return new RateDiscountPolicy();
}

DiscountPolicy, RateDiscountPolicy 모두 가능하지만 역할과 구현을 나누는 측면에서 1번이 좋다.

반환타입을 보고 역할을 알 수 있다. DI하고 있을때도 활용하기 쉽게 1번이 좋다.

@Test
@DisplayName("부모 타입으로 모두 조회하기")
void findAllBeanByParentType() {
    Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
    assertThat(beansOfType.size()).isEqualTo(2);

    for (String key : beansOfType.keySet()) {
        System.out.println("key = " + key+"value = "+beansOfType.get(key));
    }
}

테스트 할때 println 안하는게 좋다. 자동 통과/실패를 시스템이 결정하도록 해야한다.

테스트 디버깅할때는 괜찮다

@Test
@DisplayName("부모타입으로 모두 조회하기 - Object")
void findAllBeanByObjectType() {
    Map<String, Object> beansOfType = ac.getBeansOfType(Object.class);
    for (String key : beansOfType.keySet()) {
        System.out.println("key = " + key+"value = "+beansOfType.get(key));
    }
}

스프링 여러가지 빈들이 등록 된게 다 나온다. 왜냐하면 Java 객체는 모든게 Object 타입이기 때문이다

실제로 getBean을 쓸 일은 없지만 기본기능이고 순수한 Java 어플리케이션에서 스프링컨테이너를 생성해서 써야할 일이 있다.

BeanFactory와 ApplicationContext

환경변수: 로컬, 개발, 운영 등을 구분해서 처리

로컬 환경:처음 내 PC에서 개발한 환경

개발 환경:여러 시스템을 엮어서 실제 테스트 서버에 띄워두고 테스트할 수 있는 테스트 서버

운영 환경: 실제 프로덕션에 나가는 운영환경

스테이징 환경:운영과 가장 비슷한 밀접한 환경

각 환경별로 어떤 데이터베이스에 연결해야할 지, 그런 환경변수와 관련된 정보를 처리해주는 기능을 제공함

편리한 리소스 조회: 파일을 읽어서 내부에서 쓸 때 추상화해서 편리하게 쓸 수 있는 기능 제공

스프링 빈 설정 메타 정보 - BeanDefinition

BeanDefinition에 빈의 메타정보를 담는다

appConfig를 가지고 BeanDefinition 설정정보를 만든다 bin 당 하나의 설정정보다

public class BeanDefinitionTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 설정 메타정보 확인")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames(); //이름 가져오기
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                System.out.println("beanDefinition = " + beanDefinition +
                        "beanDefinition = "+ beanDefinition);
            }
        }
    }
}

출력 결과가 에서 scope 가 할당이 안되어 있으면 싱글톤

abstract, lazy : 보통 스프링 빈들이 스프링 컨테이너가 뜰 때 다 등록이 되는데 그게 아니라 실제 사용하는 시점에 나중에 실제 사용하는 시점에 스프링빈을 초기화해 라는 정보

factoryBeanName=appConfig; factoryMethodName=memberService;

appConfig에 있는 memberService를 호출해서 실제 빈을 생성할 수 있구나 라는 뜻

이런 정보들이 있다는 정도만 이해

이런 메타정보를 기반으로 인스턴스를 생성함

스프링 빈을 만들때는 1. 직접적으로 스프링 빈을 등록하는 방법 2. 팩토리 빈으로 등록하는 방식(Java config)

스프링 핵심 원리-기본편 섹션 3. 스프링 핵심 원리 이해2 정리

xandxlass — Fri, 22 Mar 2024 15:47:30 +0900

관심사 분리

MemberApp 변경전

public class MemberApp {
    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("findMember = " + member.getName());
        System.out.println("findMember = " + findMember.getName());

    }
}

변경코드

public static void main(String[] args) {
    AppConfig appConfig = new AppConfig(); //이거 무조건 만들어야댐
    MemberService memberService = appConfig.memberService();

이하 동일

변경 전 코드는 멤버서비스 인플에서 메모리 멤버 리파지토리를 만드는데

변경 후 코드는 appConfig에서 다 결정한다. appConfig가 멤버서비스 인플을 반환을 하니까 memberService에는 멤버서비스 인플이 들어가있다.

OrderApp

public static void main(String[] args) {
    AppConfig appConfig = new AppConfig();
    MemberService memberService = appConfig.memberService();
    OrderService orderService = appConfig.orderService();

AppConfig

public OrderService orderService() {
    return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy()); //AppConfig에서 구현객체를 생성함
}

OrderApp의 orderService를 보자

AppConfig에서 OrderServiceImpl 객체가 생성되고 MemoryMemberRepository와 FixDiscountPolicy가 생성자로 넘어간다 OrderServiceImpl이 MemoryMemberRepository와 FixDiscountPolicy객체를 참조하도록 하고 완성된 OrderServiceImpl 객체를 반환한다.

MemberServiceTest 변경 전

public class MemberServiceTest {
    MemberService memberService = new MemberServiceImpl();

변경 후

public class MemberServiceTest {
    MemberService memberService;

    @BeforeEach
    public void beforeEach() { //테스트 실행하기 전에 수행됨
        AppConfig appConfig = new AppConfig();
        memberService = appConfig.memberService();
    }

팁 컨트롤 + E + 엔터 : 이전에 했던 파일로 돌아감

AppConfig 리팩터링

역할에 따른 어떤 구현을 하는지가 한눈에 보여야한다

팁:컨트롤 + 알트 + M : 리팩토링할때 중복제거

public class AppConfig { //나의 애플리케이션 전체에 대해 설정하고 구성하는 공간
    public MemberService memberService() { //AppCofig를 쓸때 멤버서비스 씀
        return new MemberServiceImpl(MemberRepository()); //멤버서비스 구현체인 객체가 생성됨
    }

    private MemoryMemberRepository MemberRepository() {
        return new MemoryMemberRepository();
    }

    public OrderService orderService() {
        return new OrderServiceImpl(MemberRepository(), discountPolicy()); //AppConfig에서 구현객체를 생성함
    }

    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

리팩토링을 통해 MemberService 역할, MemoryMemberRepository 역할, OrderService 역할, discountPolicy 역할이 드러나게 된다. OrderService 에서 discountPolicy()를 둠으로써 FixDiscountPolicy()를 콜하도록 한다.

이점:메소드명만 봐도 역할이 잘 드러나게 된다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다

새로운 구조와 할인 정책 적용

AppCofing:구체적인거에 대해서 잘 아는 책임

너무 중요한 그림!

사용영역에 있는 코드는 전혀 손대지 않고 구성 영역의 코드만 바꿀 수 있다

IoC, DI, 그리고 컨테이너

정적인 클래스 의존관계는 클래스 코드만 봐도 알 수 있는데 실제 어떤 객체가 OrderServiceImpl에 주입될지는 알 수 없다

메모리 리포지토리에 메모리멤버리포지토리가 들어올지 db메모리리포지토리가 들어올지, 할인정책에 정률 정책이 들어올지 정액 정책이 들어올지 알 수 없다

동적인 객체 인스턴스 의존관계

객체다이어그램은 애플리케이션이 실행할때마다 동시에 바뀐다

정적인 그림은 하나도 손댈 필요없이 동적인 그림만 바꾸면 된다. 정적인 그림에 손을 대지 않는다는 것은 의존관계에 손대지 않는다는 말 =>DI의 장점

스프링으로 전환하기

@Configuration
public class AppConfig { //나의 애플리케이션 전체에 대해 설정하고 구성하는 공간

    //멤버서비스에 대한 구현을 나의 애플리케이션에서는 멤버서비스 인플을 쓸거야
    @Bean
    public MemberService memberService() { //AppCofig를 쓸때 멤버서비스 씀
        return new MemberServiceImpl(MemberRepository()); //멤버서비스 구현체인 객체가 생성됨
    }

    //나의 애플리케이션에서는 멤버 리포지토리는 메모리멤버리포지토리로 할거야 -> 나중에 jdbc 리포지토리로 바껴도 이 코드만 바꾸면 된다.
    @Bean
    public MemoryMemberRepository MemberRepository() {
        return new MemoryMemberRepository();
    }

    //오더서비스에 대한 구현을 나의 애플리케이션에서는 오더서비스 인플을 쓸건데 멤버리포지토리는 메모리멤버리포지토리, 디스카운트폴리시는 픽스디스카운트 폴리시 쓸거야
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(MemberRepository(), discountPolicy()); //AppConfig에서 구현객체를 생성함
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        //return new FixDiscountPolicy();
        //할인클래스를 구체 객체로 바꾸기
        return new RateDiscountPolicy();
    }
}

@Configuration 하면 애플리케이션의 설정정보를 나타냄

각메소드에 @Bean을 달면 메소드명으로 스프링 컨테이너에 등록하게 됨

ApplicationContext : 스프링컨테이너 @Bean 달은 애들을 다 관리

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

AppConfig.class 에 있는 환경 설정 정보를 가지고 스프링이 @Bean 달린 애들을 넣어 관리해줌

변경 전(자바)

public class MemberApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig(); //이거 무조건 만들어야댐
//        MemberService memberService = appConfig.memberService();

변경 후(스프링)

public class MemberApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig(); //이거 무조건 만들어야댐
//        MemberService memberService = appConfig.memberService();
        //MemberService memberService = new MemberServiceImpl();

        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

변경전에는 직접 찾아왔다면 변경후에는 스프링컨테이너를 통해 찾아온다

AppConfig에서 @Bean이 달린 메소드가 스프링컨테이너에 등록될때 메소드명으로 등록되는데 이걸 getBean 첫번째 파라미터에 적으면 '이 이름으로 이 객체를 찾을거야'라는 뜻이 된다. 두번째는 반환타입이다.

public class OrderApp {
    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
//        OrderService orderService = appConfig.orderService();
        //MemberService memberService = new MemberServiceImpl();
        //OrderService orderService = new OrderServiceIml();

        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);

orderService 꺼내보면

AppConfig의 orderService에서 리턴한 OrderServiceIml이 나온다

@Bean
public OrderService orderService() {
    return new OrderServiceImpl(MemberRepository(), discountPolicy()); //AppConfig에서 구현객체를 생성함
}

백준 JAVA 1021 분해합 리뷰

xandxlass — Wed, 20 Mar 2024 20:47:39 +0900

풀이

시간복잡도는 원소 삽입 O(N), indexOf 메서드 사용할때 O(N), 큐 회전 O(N)

시간 복잡도 O(N^3) N이 최대 50이니까 50*50*50=125000 이다

코드

/** 3주차
 * 1.BOJ 1021
 * 2.덱
 * 3.양방향으로 원소를 추가/삭제한다는 점, 끝에 있는 원소들만 추가/삭제하지 중간에 있는 원소들은 건드리지 않는다는점,
 * 덱을 이용했지만 덱의 내장함수로 인덱스를 구할 방법이 없는 것 같아서 링크드리스트 사용함
 * 4.O(N^3)
 */

/** 배운점
 * 1.덱을 STL로 구할거면 Deque<Integer> deque = new LinkedList<>() 만 생각했는데 이번에 내장함수 사용을 위해
 * LinkedList를 사용해서 문제를 푸니 고정된 사고를 벗어날 수 있었다.
 * 2.인덱스를 활용해서 푸는 문제로, 유동적인 부분을 잘 설정했어야했는데 유동적으로 변하는 인덱스, 배열 사이즈에 대한 고려가 좀 부족했다.
 * 유동적으로 변하는 LinkedList의 특징을 기억하면서 변수 설정을 잘 해야겠다.
 */

import java.util.*;
import java.io.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());
        LinkedList<Integer> deque = new LinkedList<Integer>();

        for(int i=1; i<=n; i++){
            deque.add(i);
        }

        int count=0;
        st = new StringTokenizer(br.readLine());

        for(int i=0; i<m; i++){
            int target = Integer.parseInt(st.nextToken());

            while(true) {
                if (deque.getFirst() == target) {
                    deque.removeFirst();
                    break;
                }

                int target_index = deque.indexOf(target);
                int mid = 0;
                if (deque.size() % 2 == 1) { //홀수
                    mid = deque.size() / 2;
                }
                if (deque.size() % 2 == 0) { //짝수
                    mid = (deque.size() / 2)-1;
                }

                if (mid - target_index >= 0) { //mid값보다 왼쪽에 있음 - 2번 실행
                    deque.addLast(deque.removeFirst());
                    count++;
                }

                if (mid - target_index < 0) { //mid값보다 오른쪽에 있음 - 3번 실행
                    deque.addFirst(deque.removeLast());
                    count++;
                }
            }
        }

        System.out.println(count);

    }
}

바킹독 정답 코드 보고 개선한 코드

import java.util.*;
import java.io.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());
        LinkedList<Integer> deque = new LinkedList<Integer>();

        for(int i=1; i<=n; i++){
            deque.add(i);
        }

        int count=0;
        st = new StringTokenizer(br.readLine());

        for(int i=0; i<m; i++){
            int target = Integer.parseInt(st.nextToken());

            while(deque.getFirst() != target) {
                int target_index = deque.indexOf(target);

                if(target_index<deque.size()-target_index){
                    deque.addLast(deque.removeFirst());

                }else{
                    deque.addFirst(deque.removeLast());

                }
                count++;
            }
            deque.removeFirst();
        }

        System.out.println(count);

    }
}

참고1

참고2

참고3

[자바/자료구조] 덱 개념 정리

xandxlass — Mon, 18 Mar 2024 16:10:19 +0900

바킹독 개념 정리

덱 정의

덱은 양쪽 끝에서 삽입과 삭제가 전부 가능하다

어떤 쪽으로 입력하고 어떤 쪽으로 출력하느냐에 따라서 스택(Stack)으로 사용할 수도 있고, 큐(Queue)로도 사용할 수 있다.

덱의 성질

덱의 구현

덱은 배열로 구현하는게 쉽다.

head는 가장 앞에 있는 원소의 인덱스이고 tail을 가장 뒤에 있는 원소의 인덱스 + 1이다

덱은 양쪽에서 모두 삽입 가능하기 때문에 양쪽으로 확장해야한다. 시작지점을 0으로 잡으면 왼쪽으로 확장할 수 없게 된다. 시작 지점을 배열의 중간으로 둬야한다.

그래서 배열의 크기는 2*MX+1이고 head와 tail의 초기값은 MX이다

여기까지가 배열로 덱을 구현하는 방법이었고 STL로 구현하는 방법을 알아보겠다.

JAVA의 덱

자바에서의 덱은 인터페이스로 구현되었다.
덱 자료구조의 여러 연산들을 정의한 Deque 인터페이스가 있고 이를 구현한 ArrayDeque, LinkedBlockingDeque, ConcurrentLinkedDeque, LinkedList 등의 클래스가 있다.

Deque<String> deque1 = new ArrayDeque<>();
Deque<String> deque2 = new LinkedBlockingDeque<>();
Deque<String> deque3 = new ConcurrentLinkedDeque<>();
Deque<String> linkedList = new LinkedList<>();

Deque 인터페이스의 메소드

<삽입>

addFirst()

덱의 앞쪽에 엘리먼트를 삽입한다. 용량 제한이 있는 덱의 경우, 용량을 초과하면 예외(Exception)가 발생한다

offerFirst()

덱의 앞쪽에 엘리먼트를 삽입한다. 정상적으로 엘리먼트가 삽입된 경우 true가 리턴되며, 용량 제한에 걸리는 경우 false를 리턴한다.

addLast()

덱의 마지막 쪽에 엘리먼트를 삽입한다. 용량 제한이 있는 덱의 경우, 용량 초과시 예외가 발생한다

add()

addLast()와 동일

offerLast()

덱의 마지막 쪽에 엘리먼트를 삽입한다. 정상적으로 엘리먼트가 삽입된 경우 true가 리턴되며, 용량 제한에 걸리는 경우 false를 리턴한다.

<삭제>

removeFirst()

덱의 앞쪽에서 엘리먼트 하나를 뽑아서 제거한 다음 해당 엘리먼트를 리턴한다. 덱이 비어있으면 예외가 발생한다.

pollFirst()

덱의 앞쪽에서 엘리먼트 하나를 뽑아서 제거한 다음 해당 엘리먼트를 리턴한다. 덱이 비어있으면 null 이 리턴된다.

removeLast()

덱의 마지막 쪽에서 엘리먼트 하나를 뽑아서 제거한 다음 해당 엘리먼트를 리턴한다. 덱이 비어있으면 예외가 발생한다.

pollLast()

덱의 마지막 쪽에서 엘리먼트 하나를 뽑아서 제거한 다음 해당 엘리먼트를 리턴한다. 덱이 비어있으면 null 이 리턴된다.

remove()

removeFirst()와 동일

poll()

pollFirst()와 동일

<값 추출>

getFirst()

덱의 앞쪽 엘리먼트 하나를 제거하지 않은채 리턴한다. 덱이 비어있으면 예외가 발생한다

peekFirst()

덱의 앞쪽 엘리먼트 하나를 제거하지 않은채 리턴한다. 덱이 비어있으면 null이 리턴된다.

getLast()

덱의 마지막쪽 엘리먼트 하나를 제거하지 않은채 리턴한다. 덱이 비어있으면 예외가 발생한다.

peekLast()

덱의 마지막 엘리먼트 하나를 제거하지 않은 채 리턴한다. 덱이 비어있으면 null이 리턴된다.

peek()

peekFirst()와 동일

<그 외>

removeFirstOccurrence(Object o)

덱의 앞쪽에서부터 탐색하여 입력한 Object o와 동일한 첫 엘리먼트를 제거한다. Object o 와 같은 엘리먼트가 없으면 덱에 변경이 발생하지 않는다.

removeLastOccurrence(Object o)

덱의 뒤쪽에서부터 탐색하여 입력한 Object o와 동일한 첫 엘리먼트를 제거한다. Object o 와 같은 엘리먼트가 없으면 덱에 변경이 발생하지 않는다.

element()

removeFirst()와 동일

push()

addFirst()와 동일. 덱을 스택으로 사용할 때 쓰임

pop()

removeFirst()와 동일. 덱을 스택으로 사용할 때 쓰임

remove(Object o)

removeFirstOccurrence(Object o)와 동일

contain(Object o)

덱에 Object o와 동일한 엘리먼트가 포함되어 있는지 확인

size()

Deque에 들어있는 엘리먼트의 개수

스프링 핵심 원리-기본편 섹션 2. 스프링 핵심 원리 이해1 정리

xandxlass — Fri, 15 Mar 2024 22:33:56 +0900

비지니스 요구사항과 설계

회원 도메인 협력 관계 : 기획자들도 볼 수 있다.

회원클래스다이어그램 (정적): 회원 도메인 협력 관계를 분석해서 만든것

회원 클래스 다이어그램은 서버를 실행하지 않고 클래스들만 분석해서 볼 수 있는 그림

db 구현체를 넣을지 외부 구현체를 넣을지 결정하는건 동적으로 결정하기 때문에 클래스다이어그램으로 판단하기 어려움

그래서 객체 다이어그램(동적)을 만든다

빌드하면 main에 대한 코드만 나가고 test 코드는 빌드될때 빠진다.

회원 도메인 실행과 테스트

순수 자바 코드로 테스트하기

public class MemberApp {
    public static void main(String[] args) {
        MemberService memberService = new MemberServiceImpl();
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("findMember = " + member.getName());
        System.out.println("findMember = " + findMember.getName());

    }
}

MemberServiceTest Junit으로 테스트

public class MemberServiceTest {
    MemberService memberService = new MemberServiceImpl();
    @Test
    void join() {
        //given : 이런 환경이 주어졌을때
        Member member = new Member(1L, "memberA", Grade.VIP);

        //when : 이렇게 했을때
        memberService.join(member);
        Member findMember = memberService.findMember(1L);

        //then : 이렇게 된다
        Assertions.assertThat(member).isEqualTo(findMember);
    }
}

public class MemberServiceImpl implements MemberService{
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    }

이 코드의 문제는 멤버서비스가 멤버리포지토리(인터페이스)에도 의존하고 메모리멤버리포지토리(구현체)에도 의존하고 있다. DIP 위반

주문과 할인 도메인 설계

회원을 메모리에서 조회하고, 정액 할인 정책(고정 금액)을 지원해도 주문 서비스를 변경하지 않아도 된다. 역할들의 협력 관계를 그대로 재사용 할 수 있다.

즉 메모리회원 저장소를 db멤버리포지토리로 바꿔도, 정액 할인정책을 정률할인정책으로 바꿔도 주문 서비스 구현체가 바뀌지 않는다

주문과 할인 도메인 개발

public class OrderServiceIml implements OrderService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);
        
        return new Order(memberId, itemName, itemPrice, discountPrice); //최종 생성된 주문 반환
    }
}

createOrder를 보면 멤버 가져오고 나서 discountPolicy 한테 멤버랑 아이템 가격 보낼테니 알아서 하고 결과만 던져달라고 하는 코드인데 단일책임원칙을 잘 지킨 코드다.

스프링 핵심 원리-기본편 섹션 1. 객체 지향 설계와 스프링 정리

xandxlass — Fri, 15 Mar 2024 21:14:32 +0900

좋은 객체지향 설계의 5가지 원칙(SOLID)

SRP 단일 책임 원칙

한 클래스는 하나의 책임만 가져야한다

중요한건 변경이다. 변경이 있을때 파급효과가 적으면 단일 책임 원칙을 잘 따른것

OCP 개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야한다 => 다형성 활용

인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현

아래는 멤버서비스에서 메모리멤버리포지토리를 Jdbc 멤버리포지토리로 갈아끼우려고 하는 상황이다.

두번째 코드를 보면 다형성만 사용하면 OCP 원칙을 지킬 수 없다.

구현 객체를 변경하려면 클라이언트 코드를 변경해야하는 문제가 생긴다.

LSP 리스코프 치환 원칙

차를 만든다고 했을때 인터페이스에서 엑셀 기능을 속도를 올리는 것으로 규정을 했다면 구현체에서 엑셀을 속도 마이너스 10 이런식으로 구현할 수 없다.

ISP 인터페이스 분리 원칙

적절하게 인터페이스를 나누는 것이 좋다

DIP 의존관계 역전 원칙

멤버서비스가 메모리 리포지토리 인터페이스만 바라보고 메모리멤버 리포지토리나 JDBC 멤버 리포지토리에 대해서는 몰라야한다

그림으로 설명하자면 운전자가 자동차 역할에 대해 알고 있어야지 K3에 대해 잘 알고 있으면 안된다

역할과 구현을 철저하게 분리하고 시스템을 언제든지 갈아끼울 수 있게 설계

위의 코드 문제점: 멤버서비스 new 를 보면 메모리 멤버 리포지토리에도 의존하고 있다. 의존한다는건 저 코드를 안다는 뜻

즉 멤버서비스는 메모리리포지토리와 메모리멤버리포지토리를 안다는 뜻이다. 그래서 메모리 멤버리포지토리를 변경하려고 할 때 아래와 같이 코드를 변경해야하는 문제가 발생한다 (DIP 위반)

객체 지향 설계와 스프링

인페이스를 모두 도입하면 좋지만 추상화라는 비용이 발생한다. 코드를 인터페이스를 열고 구현체들도 열고 이래야하는 단점이 있음

미래에 기능을 확장할 가능성이 있다 : 처음부터 인터페이스 만들기

미래에 기능을 확장할 가능성이 없다 : 구체 클래스를 직접 사용하고 향후 꼭 필요할때 리팩터링해서 인터페이스 도입

큐 개념 정리 JAVA

xandxlass — Fri, 15 Mar 2024 10:51:22 +0900

바킹독강의

큐 정의

한쪽 끝에서 원소를 넣고 한쪽 끝에서 원소를 뺄 수 있는 자료구조

먼저 들어온 원소가 먼저 나오게 된다 FIFO

큐 성질

4번은 원칙적으로 불가능하지만 배열로 만들면 구현은 가능하다

큐는 배열로 구현하면 쉽다.

구현

원소를 넣으면 tail이 한 칸 올라감

55 원소를 뺀다고 하면 head를 한 칸 올리면 된다. 굳이 0번지에 있는 55를 덮을 필요 없다

배열에서 dat[head]부터 dat[tail-1]번지가 바로 큐의 원소들이 들어있는 자리

큐의 크기는 tail - head

push 하면 tail이 증가하고 pop하면 head가 증가된다

큐를 삽입 삭제하게 되면 점점 오른쪽으로 밀려나가게 된다. 그러면 배열이니 앞의 공간을 못쓰게 된다

해결방법:원형으로 만들기(원형 큐)

head나 tail에 1이 더해질때 0번지로 다시 오도록 하면 된다.

다른 방법: 배열의 크기를 push의 최대수로 하면 된다

push 함수

void push(int x){
	 dat[tail++]=x
}

pop함수

void pop(){
	 head++;
}

front함수/back 함수

맨 처음 원소, 맨 뒤의 원소 확인하는 함수

int front(){
	return dat[head];
}

int back(){
	return dat[tail-1];
}

큐가 비어있을때 front/back, pop을 호출하면 런타임에러가 발생할 수 있다

자바 Stack 스택 개념 정리

xandxlass — Tue, 12 Mar 2024 20:42:20 +0900

바킹독 스택 개념을 보고 정리한 글입니다

스택

스택은 먼저 들어간 애가 나중에 나오는 구조다 FILO 구조

스택의 성질

1.원소의 추가가 O(1)

2.원소의 제거가 O(1)

3.제일 상단의 원소 확인이 O(1)

4.제일 상단이 아닌 나머지 원소들의 확인/변경이 원칙적으로 불가

스택 구현

배열, 연결리스트로 구현 가능

스택을 배열로 구현할 때는 원소를 담은 큰 배열 한 개와 인덱스를 저장할 변수 한 개만 필요하다.

pos 값이 스택의 길이, 즉 스택 내의 원소의 수를 의미함

push 함수

pos 값 +1 증가

pop 함수

pos값만 1 줄이면 된다. 나중에 원소를 넣는다면 arr[pos]에 원소가 들어가면서 알아서 값이 바뀐다

top 함수

제일 위의 원소를 확인하는 top 함수다

STL stack을 쓸 수 있으면 쓰는 것이 좋다.

런타임 에러 발생 -> 스택이 비어있는데 top이나 pop을 하진 않았는지 의심해볼 것

스택 기본 선언

Stack<Integer> stack = new Stack<>();

스택 메서드 정리

push(T t)

데이터를 스택에 추가하고, 해당 값을 반환

peek()

스택의 마지막 요소를 반환, 스택에는 영향 X

스택이 비어있는데 peek() 메서드 호출시 NoSuchElementException 예외가 발생

pop()

스택의 마지막 요소를 제거함과 동시에 해당 값 반환

empty()

스택이 비어있는지의 여부를 반환, 비어있을 경우 true, 비어있지 않을 경우 false 반환

출처

김영한 스프링 입문 섹션 7. AOP 정리

xandxlass — Sun, 10 Mar 2024 14:02:09 +0900

AOP가 필요한 상황

모든 메소드의 호출 시간을 측정하고 싶다고 해서 메소드에 다 추가해버리면 다음과 같은 문제 생긴다.

1.핵심 관심사항이 아니다

2.공통 관심사항이다.

3.시간 측정 로직과 비지니스 로직이 섞여 유지보수가 어렵다.

4.시간을 측정하는 로직을 별도의 공통 로직으로 만들기 어렵다.

해결 방법 : AOP 적용하기

공통 관심 사항과 핵심 관심사항을 분리하고 원하는 곳에 공통 관심사항을 적용하면 된다.

기존 의존 관계

가짜 멤버 서비스를 만들어서 시간 측정을 하고 joinPoint.proceed()를 통해서 실제 멤버 서비스를 실행한다.

AOP 적용 후 전체 그림은 이렇게 된다.

실제로 Proxy가 주입되는지 콘솔에 출력해보면 아래처럼 가짜 멤버서비스가 만들어짐을 알 수 있다.

AOP를 스프링빈에 등록할 때 컴포넌트 스캔과 SpringConfig에 직접 등록하는 방법이 있는 데 실무에서는 후자를 선호한다.

@Aspect
@Component
public class TimeTraceAop {
}

이렇게 컴포넌트 스캔을 해도 되지만 선호하는 방법은 아래와 같다.

@Configuration
public class SpringConfig {
	@Bean
    public TimeTraceAop timeTraceAop(){
        return new TimeTraceAop();
    }
}

@Service @Repository 같은건 정형화되어있는데 AOP의 경우 정형화되어있기보단 이거 AOP네 딱 하고 인지하는게 더 좋기 때문에 직접 등록한다. SpringConfig 보고 AOP 존재를 알아채도록 하는게 좋다

김영한 스프링 입문 섹션 6.스프링 DB 접근 기술 정리

xandxlass — Sat, 9 Mar 2024 20:58:58 +0900

H2 데이터베이스 설치

sql문

generated by default as identity

null 값이 들어오면 자동으로 id 세팅해줌

팁:sql ddl을 sql 파일을 만들어 관리한다.

순수 JDBC

자바가 DB랑 붙으려면 JDBC가 꼭 있어야한다

이번 강의에서는 과거에 사용하던 방식으로 구현을 했다.

JdbcMemberRepository

public class JdbcMemberRepository implements MemberRepository {

    private final DataSource dataSource;

    public JdbcMemberRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }

스프링부트가 데이터소스(접속정보)를 만들고 데이터소스를 주입받는다.
진짜 데이터베이스랑 연결된 정보를 얻을 수 있다.

이번 강의에서 제일 중요한 점은 JdbcMemberRepository 코드가 아니다.

SpringConfig 가 핵심이었다.

SpringConfig

@Configuration
public class SpringConfig {
    //JdbcMemberRepository는 dataSource가 필요하다 이건 스프링이 제공해준다
    //스프링부트가 프로퍼티즈 보고 자체적으로 dataSource 만들고 DI 해준다.
    private final DataSource dataSource;

    @Autowired
    public SpringConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Bean //스프링빈 등록할거야
    public MemberService memberService(){
        return new MemberService(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository(){

        //return new MemoryMemberRepository(); //인터페이스는 new 안됨
        return new JdbcMemberRepository(dataSource);
    }
}

강의 초반에 비지니스 요구사항에서 DB가 정해지지 않아서 인터페이스와 구현체를 만들고 나중에 다른 리포지토리로 바꾸려고 계획을 했었다. 이를 가능하게 만드는 것이 스프링의 장점이다.

JdbcMemberRepository 와 SpringConfig 파일을 제외하고 어떤 코드도 손대지 않았다. 이 두 파일만 손대니 구현체를 바꿔끼울 수 있었다.

가장 중요한 개방 폐쇄 원칙(OCP) (확장에는 열려있고 수정, 변경에는 닫혀있다)를 지킬 수 있다.

스프링의 DI를 사용하면 기존 코드를 전혀 손대지 않고 설정만으로 구현클래스를 변경할 수 있다.

스프링 통합 테스트

@SpringBootTest
class MemberServiceIntegrationTest {
    //스프링한테 멤버서비스, 멤버리포지토리 내놔 해야됨
    //어떻게? DI 하기 근데 테스트는 끝단에 있는거라 편한 방법 사용함 @Autowired 사용
    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository; //구현체는 SpringConfig에서 올라올거임

    @Test
    void 회원가입() { //테스트는 한글로 해도 상관무
        //given
        Member member = new Member();
        member.setName("spring1");

        //when 
        Long saveId = memberService.join(member);

        //then
        Member findMember=memberService.findOne(saveId).get();
        assertThat(member.getName()).isEqualTo(findMember.getName());
    }

@Autowired MemberService memberService;
@Autowired MemberRepository memberRepository; //구현체는 SpringConfig에서 올라올거임

스프링한테 멤버서비스, 멤버리포지토리 내놔 해야됨
어떻게? DI 하기 근데 테스트는 끝단에 있는거라 편한 방법 사용함 @Autowired 사용

구현체는 SpringConfig에서 올라오니까 인터페이스를 연결

이 상태로 테스트를 하면 에러가 난다. DB에 앞서 했던 데이터들이 저장되어있기 때문에 이미 존재하는 회원이라는 에러가 뜬다.

이미 존재하는 회원이라는 에러->db 삭제
실제로는 운영 db를 지우는게 아니라 테스트 디비 or 로컬 pc 디비를 돌려서 확인함

다시 실행하면 테스트는 통과되지만 다시 또 하면 에러가 난다. DB에 저장되어있기 때문

테스트는 여러번 계속 반복할 수 있어야한다! => @Transactional 사용

해결방법

DB는 트랜잭션이라는 개념이 있다. 커밋을 해야 DB에 반영이 된다. 커밋 하기 전까지는 반영이 안된다.

테스트 끝난 후에 롤백하면 DB 데이터가 다 날라간다 그래서 롤백해주는 어노테이션을 달면 해결이 된다.

@Transactional 을 달면 트랜잭션 후에 DB 쿼리를 다 하고 테스트 끝나면 롤백을 해준다. 그러면 DB 데이터가 반영이 안된다. 이 기능은 테스트에서만 적용됨

순수한 자바로만 하는 테스트:단위테스트

스프링컨테이너+DB까지 불러서 하는 테스트 :통합테스트

단위테스트가 훨씬 좋은 테스트다 계속 연습하는 게 중요

스프링 JdbcTemplate

람다식 변경 단축키 알트+엔터

마지막으로 실행했던 걸 다시 실행 단축키: 컨트롤+R

JdbcTemplate는 JDBC API에서 본 반복 코드를 대부분 제거해준다. 하지만 SQL은 직접 작성해야한다.

JdbcMemberRepository의 코드와 JdbcTemplate를 활용해 만든 JdbcTemplateMemberRepository 파일을 비교해보면 JdbcTemplateMemberRepository 가 코드 단축이 엄청 됐다는 것을 알 수 있다.

이번 강의에서는 JdbcTemplate를 활용해서 코드 단축을 하고 SpringConfig에 구현체를JdbcTemplateMemberRepository 로 바꾸는 실습을 했다.

JPA

@Entity
public class Member {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

DB 쿼리에 insert into values~ 할때 name을 넣지, id는 넣지 않는다. id를 넣지 않아도 DB에서 자동으로 생성 해주는데 이러한 것을 IDENTITY 전략이라고 한다

spring.jpa.show-sql=true //Jpa가 날리는 sql을 볼 수 있다
spring.jpa.hibernate.ddl-auto=none //jpa가 객체를 보고 테이블을 만들어줌 근데 우린 이미 만들었으니까 끔

@Override
public List<Member> findAll() {
    List<Member> result = em.createQuery("select m from Member m", Member.class)
            .getResultList();
    return result;
}

result 로 받고 result를 return 함 똑같으면 인라인 해주면 좋다

단축키:컨트롤+알트+N

@Override
public List<Member> findAll() {
    return em.createQuery("select m from Member m", Member.class)
            .getResultList();
}

select m from Member m 이 JPQL 쿼리문이다. 객체를 대상으로 쿼리를 날리는 것이다.

select m 객체 자체를 select 한게 포인트

PK 기반이 아닌 것들은 JPQL을 써야한다

JPA를 쓰려면 항상 트랜잭션이 있어야한다

JPA는 트랜잭션 안에서 다 실행되어야 한다

스프링 데이터 JPA

public interface SpringDataJpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {
    @Override
    Optional<Member> findByName(String name);
}

스프링데이터 JPA가 JpaRepository가 있으면 구현체를 자동으로 만들고 등록해준다. 그걸 그대로 가져다쓴다

스프링 데이터 JPA 제공 기능

1.인터페이스를 통한 기본적인 CRUD

2.findByName(), findByEmail() 처럼 메서드 이름 만으로 조회 기능 제공

3. 페이징 기능 자동 제공