🌊 ._.sori🪽

< 이전 포스팅 - 변수>

🪽

"틀린 내용이 있을 수 있습니다."

► 인스턴스

• 클래스가 설계도, 인스턴스는 설계도는 보고 만든 물건이다.
• 실체화된 객체를 인스턴스라고 부른다.
• 즉 메모리에 할당되어 생성된 객체를 인스턴스라 부른다.
• 객체 내에 인스턴스라는 개념이 포함되어있다.
• 하지만 객체와 인스턴스를 구분하는 것이 크게 의미있진 않은 것 같다...

Q. 클래스가 설계도며 인스턴스가 설계도를 보고 만든 물건이라는데, 그게 무슨 말인가?

A. 자동차와 관련된 설계도가 있다고 가정하겠다.

// 출처 - jongtachi님

// 자동차를 만들 설계도(클래스)
class Car {
    String brand;
    String model;

    // 설계도를 따라 자동차를 만드는 방법(생성자)
    public Car(String brand, String model) {
        this.brand = brand;
        this.model = model;
    }
}

public class Main {
    public static void main(String[] args) {
    
        // 실제 차를 만드는 과정(인스턴스)
        Car myCar = new Car("Toyota", "Camry");

        System.out.println("브랜드: " + myCar.brand);
        System.out.println("모델: " + myCar.model);
    }
}

► 생성자

• 생성자의 이름은 클래스 이름과 동일해야한다.
• 리턴타입이 없다.
• 매개변수 조건에 따라 여러개 생성 가능하다. (오버로딩)
• 생성자 코드가 없으면 자동으로 기본생성자를 생성하지만, 생성자 코드가 하나라도 있을 시 기본생성자를 생성하지 않는다.

Q. 매개변수 조건에 따라 여러개 생성 가능하다라는 말이 무슨 말일까?

A. 매개변수 조건에 따라 여러개 생성 가능하다라는 말은 생성자 오버로딩을 의미한다. 

아래 예제처럼 생성자의 매개변수(year, model)에 따라 오버로딩이 가능하다.

주의해야할 점은 위의 코드처럼 같은 타입의 매개변수가 있을 경우 오류가 발생하니 타입을 변경하거나 매개변수의 갯수가 달라야한다.

// 출처 - jongtachi님의 코드 수정

class Car {
    int year;
    String model;

    // 년도만 받는 생성자
    public Car(int year) {
        this.year = year;
        this.model = "받지 않음";
    }

    // 모델만 받는 생성자
    public Car(String model) {
        this.year = 0;
        this.model = model;
    }

    // 년도, 모델 받는 생성자
    public Car(int year, String model) {
        this.year = year;
        this.model = model;
    }

    public void resultPrint() {
        System.out.println("Year: " + year + "   " + "Model: " + model);
    }
}

 public class Main {
        public static void main(String[] args) {

            // 년도만 아는 경우
            Car car1 = new Car(2024);
            car1.resultPrint();

            // 모델만 아는 경우
            Car car2 = new Car("Camry");
            car2.resultPrint();

            // 년도와 모델만 아는 경우
            Car car3 = new Car(2024, "Camry");
            car3.resultPrint();


        }
    }

Q. 생성자 코드가 하나라도 있을 시 기본 생성자를 생성하지 않는다는 것은 무슨 말인가?

A.  새로운 인스턴스를 생성했고 어떤 생성자도 없으면 프로그램은 자동으로 기본생성자를 만들어낸다. 

// 자동차를 만들 설계도(클래스)
class Car {
    int year;
    String model;

	// 어떤 생성자도 존재하지 않는다.
    
    public void resultPrint() {
        System.out.println("Brand: " + year + "   " + "Model: " + model);
    }
}

 public class Main {
        public static void main(String[] args) {

            // car1 인스턴스 생성
            Car car1 = new Car();
            car1.resultPrint();


        }
    }

오류가 발생할 것 같지만 결과값은 출력된다.

자동으로 생성자를 만들어낸 것이다.

그런데 생성자를 하나라도 만들게 되면 기본 생성자도 개발자가 직접 만들어야한다.

// 자동차를 만들 설계도(클래스)
class Car {
    int year;
    String model;


    // 기본 생성자
    public Car() {

    }


    // 브랜드, 모델 받는 생성자
    public Car(int year, String model) {
        this.year = year;
        this.model = model;
    }

    public void resultPrint() {
        System.out.println("Brand: " + year + "   " + "Model: " + model);
    }
}

 public class Main {
        public static void main(String[] args) {

            // 기본 생성자를 이용할 인스턴스
            Car car1 = new Car();
            car1.resultPrint();


            Car car2 = new Car(2024, "Camry");
            car2.resultPrint();


        }
    }

만약 안 만들게 되면?

// 자동차를 만들 설계도(클래스)
class Car {
    int year;
    String model;


    // 브랜드, 모델 받는 생성자
    public Car(int year, String model) {
        this.year = year;
        this.model = model;
    }

    public void resultPrint() {
        System.out.println("Brand: " + year + "   " + "Model: " + model);
    }
}

 public class Main {
        public static void main(String[] args) {

            // 기본생성자가 없는 경우
            Car car1 = new Car();
            car1.resultPrint();


            Car car2 = new Car(2024, "Camry");
            car2.resultPrint();


        }
    }

오류가 발생하게 된다.

Q. 생성자는 왜 만드는 것인가?

A. 다양한 이유가 있지만, 객체를 생성할 때 꼭 필요한 값들을 받을 수 있도록 강제할 수 있다. 예시로 대부분 프로그램을 만들면 가장 기본적으로 회원가입 페이지를 만들게 된다. 그럴때 회원님의 성함과 아이디, 비밀번호, 주소 등 내가 만들 프로그램에 꼭 쓰일 정보를 받도록 할 수 있는 것이다. 그 외에도 유지보수면, 일관성 등이 있다.

► 매개변수(Parameter)

• 매개변수는 생성자나 메서드를 정의할 때 어떤 값을 받을지 명시하는 변수이다.

► 인자(Argument)

• 인자는 생성자나 메서드를 호출할 때 실제로 전달되는 값이다.

Q. 그래서 둘이 뭐가 어떻게 다르다는 것인가?

A. 지금까지 봐온 코드에 매개변수, 인자 모두 나타나있다.

    // 브랜드, 모델 받는 생성자
    public Car(int year, String model) {
        this.year = year;
        this.model = model;
    }

여기에서 year과 model은 매개변수이다. 매개변수는 메서드나 생성자를 정의할 때 어떤 값을 받을지 명시하는 변수라고 했고 Car는 생성자로 변수를 year은 정수형으로 model은 문자열로 받겠다고 명시한 것이다.

Car car2 = new Car(2024, "Camry");
car2.resultPrint();

그렇다면 2024와 Camry는 인자가 될 것이다. 인자는 생성자나 메서드를 호출할 때 실제로 전달되는 값이니 2024와 Camry가 된다는 걸 바로 알 수 있다. 

혼자 공부하면서 이해하고 쓴 내용이라 틀린 내용이 있을 수 있습니다.

댓글로 적어두시면 수정하도록 하겠습니다. 🍀

[ 블로그에 쓴 내용들의 출처는 아래에 적어둘테니

들어가서 읽어보시면 더욱 도움이 되실 듯 합니다 ]

< 이후 포스팅 - static과 final>

- 인스턴스 출처

- jongtachi님 예제 출처

- 생성자와 매개변수 출처

- 생성자와 오버로딩 출처

- 매개변수와 인자의 차이 출처

🪽

"틀린 내용이 있을 수 있습니다."

► 변수

변수란, 프로그래밍에서 값을 저장하고 관리하기 위해 사용하는 이름이 붙은 메모리 공간이다.

변수는 변수가 선언된 위치에 따라 변수의 종류를 정한다.

1. 클래스 변수 (전역변수)

클래스 변수의 특징은 크게 네가지가 있다.

• 변수 타입 앞에 static을 붙인다.
• 클래스 변수는 모든 인스턴스가 공유한다.
• 모든 인스턴스가 공통된 값을 공유한다.
• 클래스 이름, 클래스 변수명을 통해 접근할 수 있다.

Q. 모든 인스턴스가 공유된다는 말이 무슨 의미인가?

A. 생성된 인스턴스는 클래스 변수를 참조한다는 것이다. 쉽게 설명하자면 클래스 변수는 마을에 놓인 우체통이고 인스턴스는 집이라고 비유할 수 있다. 집(인스턴스)는 우체통(클래스 변수)에 편지를 꺼낼수도 편지를 넣을 수도 있다. 모든 집이 똑같은 우체통을 쓰기 때문에 어떤 집에서 넣은 편지를 다른 집에서 꺼내 볼 수 있다.

// chat-GPT를 통해 예제를 만들었습니다.

class Counter {

    // static이 붙은 것을 통해 클래스 변수라는 것을 알 수 있다.
    // 클래스 변수를 0으로 초기화했다.
    static int count = 0;  

    // 생성자 Counter를 통해 new Counter()가 있으면 count 변수가 증가하도록 했다.
    Counter() {
        count++;  
    }
 
    // 현재 count가 얼마나 증가했는지 보여주는 메서드를 만들었다.
    void showCount() {
        System.out.println("Count: " + count);
    }
}

public class Main {
    public static void main(String[] args) {
    
    	// 인스턴스 c1과 c2가 생성되었다.
    	// 생성자를 통해 count++가 실행된다.
        // c1과 c2로 count++가 총 두 번 실행되었다.
        Counter c1 = new Counter();  
        Counter c2 = new Counter();  

        // 이 c1과 c2는 showCount 메서드를 통해 결과값이 출력된다.
        // 결과값은 2가 된다.
        // 2가 나오는 이유는 동일한 클래스 변수 count를 출력하기 때문이다.
        c1.showCount();  
        c2.showCount();  
    }
}

2. 인스턴스 변수 (전역변수)

인스턴스 변수의 특징은 크게 세가지가 있다.

• 인스턴스가 생성되어야 변수가 생성된다.
• 클래스 객체와 다르게 공유되지 않는다.
• 인스턴스마다 고유한 다른 값을 가질 수 있다.

인스턴스 변수와 클래스 변수의 차이를 알아보는 예제를 찾았다.

// 출처 - sujinhope님
public class Main {

    public static class StaticTest {

	// 클래스 변수
        static int classVar = 10;
        //인스턴스 변수
        int instanceVar = 28;

    }


    public static void main(String[] args) {

	// staticTest1과 staticTest2인 인스턴스가 생성했다.
        StaticTest staticTest1 = new StaticTest();
        StaticTest staticTest2 = new StaticTest();
        
        // 실행 값은 1번과 2번 모두 10과 28이 된다.
        System.out.println("1번 " + staticTest1.classVar + ", " + staticTest1.instanceVar);
        System.out.println("2번 " + staticTest2.classVar + ", " + staticTest2.instanceVar);

	// 클래스 변수 staticTest1의 값을 12로 변경했다.
        staticTest1.classVar = 12;
        // 인스턴스 변수 staticTest1의 값을 400으로 변경했다.
        staticTest1.instanceVar = 400;

        System.out.println();
        // 1번의 출력값은 12와 400이 된다.
        // 2번의 출력값은 12와 28이 된다.
        System.out.println("1번 " + staticTest1.classVar + ", " + staticTest1.instanceVar);
        System.out.println("2번 " + staticTest2.classVar + ", " + staticTest2.instanceVar);;
    }
}

클래스 변수는 인스턴스의 모든 값을 공유하기 때문에 하나의 인스턴스 값이 바뀌면 모든 인스턴스가 값을 변경된다. 
인스턴스 변수는 인스턴스의 값을 공유하지 않기 때문에 인스턴스가 개별적으로 값을 유지하는 것이 가능하다.

Q. 클래스, 인스턴스, 클래스 변수, 인스턴스 변수가 무엇인가?

A. 비유로 예를 들어보겠다. [ 클래스는 빵틀  ,  인스턴스는 빵틀로 찍어낸 빵  ,  클래스 변수는 빵에 표식을 남기는 빵집의 시그니처(?)  ,  인스턴스 변수는 빵 안에 들어가는 잼 ]으로 생각할 수 있다.

3. 지역변수

• 메서드 내에서 선언된다.
• 메서드가 실행될 때 메모리를 할당받는다.
• 메서드가 종료되면 소멸되어 사라진다.

// 출처 - sujinhope님
public class Main {

    public static class StaticTest {

	// 전역변수 중 하나인 클래스 변수이다.
        static int classVar = 10;
        // 전역변수 중 하나인 인스턴스 변수이다.
        int instanceVar = 28;

	// 메서드인 method를 만들었다.
        public void method() {
            // 지역변수 localVar
            int localVar = -100;
            System.out.println("지역 변수 값 : " + localVar);
        }

    }


    public static void main(String[] args) {

	// localTest 인스턴스를 만들었다.
        StaticTest localTest = new StaticTest();
	// 인스턴스를 통해 method 실행한다.
        localTest.method();
    }
}

혼자 공부하면서 이해하고 쓴 내용이라 틀린 내용이 있을 수 있습니다.

댓글로 적어두시면 수정하도록 하겠습니다. 🍀

[ 블로그에 쓴 내용들의 출처는 아래에 적어둘테니

들어가서 읽어보시면 더욱 도움이 되실 듯 합니다 ]

< 이후 포스팅 - 인스턴스, 생성자, 매개변수와 인자의 차이>

- 변수의 개념 정리 출처

- sujinhope님의 예제 출처

- 전역변수와 지역변수의 개념 정리 출처

- chatGPT의 도움도 받았습니다.

🪽

"틀린 내용이 있을 수 있으며, 김영한 선생님의 스프링 기본편을 위주로 공부했습니다."

► 인터페이스 (기본 설계도)

public interface MemberRepository {

    void save(Member member);

    Member findById(Long memberId);

}
// 출처: 1)김영한의 스프링 기본편

• public interface라고 선언하면 그것이 인터페이스가 된다.
• 인터페이스는 추상화 클래스로 일반적인 메서드, 멤버 변수 구성원(아래 코드처럼)을 가질 수 없다.
• 인터페이스는 추상메서드(만들다 만 것 같은 메서드)와 상수(final을 이용하여 변하지 않는 어떤 값을 만드는 것)만 가진다.
• 추상메서드는 public abstruct - 로 시작하지만, 위의 코드처럼 생략해도 무관하다.
• 상수는 public static final -로 시작하지만, 생략가능하다. 
• 쉽게 말해 불완전하므로 사용하기 위해 다른 놈이 필요하다!

• 한 클래스 혹은 한 인터페이스에 인터페이스를 다중 상속이 가능하다.

public interface Dog extends Animal, Pet {
    void bark();
}

class Cat implements Animal, Pet {

    public void cry() {
        System.out.println("냐옹냐옹!");
    }

    public void play() {
        System.out.println("쥐 잡기 놀이하자~!");
    }
// 출처: 3)TCP School

► 구현체 (구체적인 설계도)

@Component
public class MemoryMemberRepository implements MemberRepository{

    private static Map<Long, Member> store = new HashMap<>();

    @Override
    public void save(Member member) {
        store.put(member.getId(), member);
    }

    @Override
    public Member findById(Long memberId) {
        return store.get(memberId);
    }

• implements를 통해 인터페이스 상속을 받는다.
• 구체적인 메서드를 작성한다.
• 같은 클래스 내에서 인터페이스와 구현체를 한 번에 넣을 수도 있다. 

Q. 인터페이스를 만든 이유는?

A. 여러 이유가 있는데, 가장 큰 것은 의존성 문제이다. 클래스는 서로 얽혀있다. 한 클래스에 한 기능을 담당하기 때문에 회원정보를 넣고 빼는 클래스, 회원 정보를 저장하는 클래스, 주문을 처리하는 클래스 등 어떤 프로젝트를 할 때 여러 클래스들이 서로 얽혀있게 된다. 

 예시로 평소에는 10만원 이상 구매시 10퍼센트 할인하는 정책이었는데, 추석맞이 이벤트로 10만원 이상 구매시 30퍼센트로 할인하는 정책을 새롭게 넣는 것을 들어보자. 그러면 30퍼센트 할인하는 클래스를 만들 것이다. 인터페이스가 없다면  주문을 처리하는 클래스에 가서 코드를 직접 수정해야한다. 10퍼센트 할인 클래스를 선언해놨겠지만, 30퍼센트 할인 클래스로 변경해야한다. 그리고 할인 정책을 사용하고 있는 클래스에 들어가 직접 수정을 해줘야하는 번거로움이 생긴다. 또 그로인한 오류도 발생하게된다.

 그런 오류를 줄이기 위해 인터페이스를 중간에 껴두는 것이다. A 클래스 - 인터페이스 - B 클래스로 만들어 B 클래스가 다른 클래스로 대체하더라도 A 클래스 코드에 직접적인 수정이 없도록 만드는 것이다.

 물론 인프런에 김영한 선생님의 스프링기본편을 듣게된다면 자바 스프링의 의존성 문제를 어떤식으로 해결하는지 더 자세하게 알 수 있다.

Q. 그렇다면 인터페이스 내부에 추상메서드를 두는 이유가 무엇인가?

A. 첫번째는 인터페이스에 정의된 메서드들을 구체클래스에 가서 반드시 구현하게 하기 위함이다. 만일 인터페이스에 정의된 메서드들을 구현체에서 실행하지 않으면 컴파일러 오류를 발생시킨다.

 두번째는 애매모호하게 메서드를 정의하여 유연성을 제공한다. 아까 위의 질문에서 서술했듯, 할인 정책이 변경될 시 인터페이스가 구체적인 메서드로 정의되어있다면 인터페이스의 코드도 수정해야한다. 추상메서드로 둬 메서드의 이름만 맞춰 구체클래스를 작성하게 되면 감쪽같이 바뀌게 된다. (이 경우 인터페이스와 구현부를 이어주는 클래스가 따로 존재해야한다.)

Q. 클래스는 클래스에게 다중 상속이 안되지만 인터페이스는 가능하다. 왜 그런것일까?

A. 다이아몬드 문제를 유발하기 때문이다. 한 클래스가 다른 두 클래스에게 상속을 받았다고 가정하자. 두 클래스에 같은 메서드 시그니처 (동일한 이름, 동일한 매개변수)가 있다면 하위(상속을 받은) 클래스는 혼동하게 된다. 어떤 상위 클래스에서 메서드를 받아올지 말이다. 그렇기에 클래스는 구체적으로 메서드를 정의하기 때문에 다중상속이 안된다.

 하지만 인터페이스는 추상적인 메서드를 정의하기 때문에 메서드 시그니처가 같아도 무관하다. 

1)  김영한의 스프링 기본편 출처

2) 인터페이스 총정리 출처

3) TCPSchool 출처

4) 다중 상속 출처

8월 전에 다 끝내기로 한 계획,,,! 강의는 모두 들었지만 왜인지 블로그 작성은 미뤄졌다. 그래도 영상 다 들은게 어디냐며 약간의 위로와 함께 블로그 작성을 해보려한다. 코로나로 인해 체력이 박살난건지, 그냥 이미 박살난걸 내가 몰랐던 건지 알 수 없지만 위경련 터지며 길바닥에 주저앉는 인생이어도 오늘도 화이팅!! 모두들 화이팅!

🧸 

🧸 구조파악 레츠꼬우- 🧸

 • scope

ㄴ class :  SingletonTest, SingletonWithPrototypeTest1, PrototypeTest

 • web

ㄴ class :  LogDemoController, LogDemoService

• common

ㄴ class :  MyLogger

Q. 빈 스코프란?

A. 빈이 사용되어지는 범위이다.

✔️  SingletonTest

►  결과

지금까지 우리가 배운 것은 싱글톤 빈 스코프다. 싱글톤 빈 스코프는 싱글톤 빈이 시작되어 끝날때까지 유지된다. 또 같은 요청에 대해 같은 인스턴스 빈으로 반환한다.

✔️  PrototypeTest

@Scope("prototype")
static class PrototypeBean {

}

@Scope("prototype")

: 빈의 스코프를 프로토타입으로 설정한다. 

►  결과

프로토타입 빈의 인스턴스가 다르게 요청된 것을 볼 수 있다. 싱글톤 빈 스코프는 처음부터 끝까지 유지되지만 프로토타입은 의존관계 주입과 초기화(Prototype.init 2번 요청된 것을 보면)까지만 관여한다. 그렇기에 Predestroy 메서드는 실행되지 않는다. (현재 실행 결과에서 Prototype.destroy가 있지만, 따로 코드에 prototypeBean1.destroy();를 적어서 그런것이다.)

✔️  SingletonWithPrototypeTest1

►  프로토타입과 싱글톤을 함께 쓸 경우 생기는 문제점

    @Scope("singleton")
    static class ClientBean {

	private final PrototypeBean prototypeBean;
        
        @Autowired
        public ClientBean(PrototypeBean prototypeBean) {
        	this.prototypeBean = prototypeBean;
        }

        public int logic() {
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }
    }

코드를 살펴보면 싱글톤 클래스인 ClientBean 내부에 프로토타입 빈이 선언되었다. 모두가 알다시피 싱글톤 빈은 생성시점 딱 한 번 생성되고 그 생성된 것을 중복하여 사용하는 방식이다.(이미 할당된 인스턴스를 같은 빈을 사용할 때 마다 같은 인스턴스 할당) 그러니 그 내부에 함께하는 프로토타입도 본래의 특성이 아닌 싱글톤 빈을 따라가게 되는 것이다.

Q. 만약 같은 인스턴스가 계속 호출되는 프로토타입은 더이상 프로토타입이 아니고 싱글톤이라고 할 수 있나?

A. 맞다. 그 특성이 싱글톤이 되었으니, 더이상 프로토타입이 아니다.

►  주입 시점 차이

static class ClientBean {
 
         @Autowired
         private ApplicationContext ac;
         
         public int logic() {
             PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
             prototypeBean.addCount();
             int count = prototypeBean.getCount();
             return count;
	}
}

전 코드는 싱글톤 빈 내부에 프로토타입이 선언되었다. 현재 코드는 ApplicationContext를 이용해 프로토타입 빈을 따로 관리하고 있음을 알 수 있다. logic 메서드가 호출되면 ac(ApplicationContext)를 통해 프로토타입 빈을 매번 요청하게 된다. 

►  ObjectFactory

static class ClientBean {

	@Autowired
	private ObjectProvider<PrototypeBean> prototypeBeanProvider;
 
	public int logic() {
		PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
		prototypeBean.addCount();
		int count = prototypeBean.getCount();
		return count;
	}
}

ObjectProbvider

: 지정한 빈을 찾아 컨테이너에서 대신 찾아주는 DL 서비스를 제공한다. / 스프링에 의존적이다.

- ObjectProvider 출처

- ObjectFactory 출처

►  JSR-330 Provider

static class ClientBean {

    @Autowired
    private Provider<PrototypeBean> prototypeBeanProvider;

    public int logic() {
        PrototypeBean prototypeBean = prototypeBeanProvider.get();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

Provider< >

:  < > 안의 인스턴스를 제공하고 지연, 옵션, 의존적인 경우인 순환참조문제에 쓴다.

- Provider 출처

✔️  MyLogger

가짜 프록시를 이용하여 로그 요청을 위한 클래스

@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {

value

: 웹 스코프의 종류를 의미하며, 현재는 Http 요청 하나가 들어가고 나갈때 가지 유지되는 request로 되어있다.

ProxyMode

: GoF 다자인 패턴으로 해당 객체의 생성이나 초기화를 지연하거나, 접근을 제어할 때, 성능 최적화가 필요한 경우 사용한다.

ScopedProxyMode의 종류

- DEFAULT : 프록싱 없음
- NO : 프록싱 없음 (DEFAULT와 같음)
- INTERFACE : 인터페이스 기반으로 동적 프록싱 생성
- TARGET_CLASS : 대상 클래스 기반으로 CGLIB 프록시 생성
- SCOPED_PROXY INTERFACES : INTERFACE 혹은 TARGET_CLASS 중 하나를 나타내는 특별한 단축형 값이다.

고객이 서비스를 언제 요청할지 모른다. 거기다 

- ProxyMode  출처

••• 이어서 다른 코드 부분 •••

public void setRequestURL(String requestURL) {
    this.requestURL = requestURL;
}

public void log(String message) {
    System.out.println("[" + uuid + "]" + "[" + requestURL + "]" + message);
}

@PostConstruct
public void init() {
    uuid = UUID.randomUUID().toString();
    System.out.println("[" + uuid + "] request scope bean create:" + this);
}

setter를 통해 requestURL을 받는다. 그리고 처음 Http 요청이 오면 @PostConstruct를 통해 uuid를 random으로 만들어 log로 보낸다.

Q. requestURL은 빈이 생성되는 시점을 알 수 없기 때문에 setter로 받는데 왜 생성시점을 모를까?

A. 현재 MyLogger의 코드를 살펴보면, requestURL을 생성하는 코드는 존재하지 않는다. 즉, 다른 클래스에서 받아온다는 것이다. 거기다 MyLogger은 request 스코프로 정의되어있다. 그렇다는건 Http의 요청이 들어오면 새로운 인스턴스가 생성되고, 그 후에 requestURL 값이 결정된다는 것이다. 이러한 이유로 requestURL 빈은 생성시점은 알 수 없다. 일단 요청이 있어야하는데 요청이 언제 올지 모르며 다른 클래스(서비스나 컨트롤러)에 requestURL을 생성하는 코드가 있기 때문이다.

✔️  LogDemoController

로거가 잘 작동되는지 테스트용 컨트롤러

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final MyLogger myLogger;

@ReqiredArgsConstructor (Lombok)

: 초기화 되지않은 final 필드나, @NonNull이 붙은 필드에 대해 생성자를 생성하며, @Autowired를 사용하지 않고 의존성을 주입한다.

LogDemoService와 MyLogger 의존관계를 주입해준다. private와 final로 선언한 이유는 읽거나 수정을 못하게 하기 위함이다. 외부에서 수정될 경우 코드에 문제가 생길 수 있기 때문이다.

- @ReqiredArgsConstructor 출처

••• 이어서 다른 코드 부분 •••

@RequestMapping("log-demo")
@ResponseBody
public String longDemo(HttpServletRequest request) {
    String requestURL = request.getRequestURI().toString();
    myLogger.setRequestURL(requestURL);

@RequestMapping( )

: 들어온 요청을 특정 메서드와 매핑하기 위해 사용한다.

현재 코드에서는 @RequestMapping에 대해 괄호 안에 어떤 value값이나 method값을 작성하지 않았다. 그렇다는건 요청방식에 관계없이 url이 일치하는 요청을 처리한다. 그러면 ("log-demo")라고 적혀있으니, log-demo 경로로 들어온 Http 요청을 이 메서드가 처리한다는 의미가 된다.

@ResponseBody

: Http 응답을 처리할 때 사용하는 어노테이션, 응답 바디를 JSON, XML, 문자열 등으로 변환하여 클라이언트에게 반환할 때 사용된다.

getRequestURL

: 요청에 사용된 URL로 부터 URL 값을 리턴한다.

toString( )

: 문자열 그대로 반환한다.

HttpServletRequest는 클라이언트가 보낸 Http 요청을 담고 있다. 그렇다면 MyLogger에서 가짜 프록시를 만들도록 했으니, Http 요청이 들어오면 logDemo에서 HttpServletRequest에 가짜 프록시를 넣고 시작하게 된다. 그 후에 클라이언트가 요청한 URL 값을 가져와 문자열 그대로 반환하도록 한다. 그렇게되면 myLogger.set- 코드를 통해 MyLogger에서 URL 값이 출력된다.

- @RequestMapping 출처

- @ResponseBody 출처

- getrequestURL 출처

••• 이어서 다른 코드 부분 •••

myLogger.log("controller test");
logDemoService.logic("testId");
return"OK";

"controller test"라는 메세지와 함께 myLogger에 있는 log를 메서드를 호출한다. 그 밑에 줄은 logDemoService에 logic에 "testId"라는 메세지와 함께 logic 메서드를 호출한다. retuen "OK"는 클라이언트에게 OK라는 응답을 반환한다.

✔️  LogDemoService

주어진 id와 함께 로그를 남기는 서비스 로직을 처리

private final MyLogger myLogger;

public void logic(String id) {
    myLogger.log("service id = " + id);
}

아까 LogDemoController에  코드 쪽에 logDemoService.logic("testId");가 있었다. testId를 logic 메서드에 보내라는 의미이다. 그러면 받은 메세지를 가지고 logic 메서드는 MyLogger에 있는 log메서드에 id를 보내게 된다. 그러면 log 메서드에 필요한 uuid와 URL 그리고 id가 모두 잘 출력되게 된다.

✔️  총정리

 이번에 배운 것은 프로토타입 스코프와 웹 스코프에 관한 것이었다. 프로토타입 스코프는 싱글톤 스코프와 다르게 인스턴스를 필요할 때 마다 새롭게 받아 쓴다는 점이 있었는데, 주로 싱글톤과 함께 쓰일 프로토타입 스코프엔 큰 문제접이 있었다. 싱글톤 내부에 프로토타입 스코프를 선언하게 되면 싱글톤 스코프의 처음부터 끝가지 유지되는 특성을 그대로 가져가 새로운 인스턴스를 가져오지 못하게 된다는 것이다. 그렇기에 그 부분을 주입시점을 다르게하거나, ObjectProvider를 사용하거나, JSR-330 Provider를 사용하는 방법을 배웠다. (하지만 사실상 쓸 일이 많이 없다는 것) 

 아마 웹스코프는 웹개발을 하며 실무적으로 필요한 내용일 듯 하다. 웹스코프를 개발하면서 문제점은 request 스코프 빈이 실제 고객의 요청이 없기 때문에 오류가 발생시킨다는 점이었다. 그렇기에 가짜 프록시를 사용하여 일단 있는 척을 한 뒤, 나중에 필요한 부분에서 실제 스코프 빈이 있는 곳을 향해 생성되도록 하는 것이었다. 

 마지막 장 정리가 생각보다 오래걸렸다. 막판에 코로나 + 위경련 + 추석 등 여러 일로 인해 천천히 정리하다 결국 내용을 까먹어 다시 강의를 들어 복습하며 정리하게 되었다. 2024년 9월 22일 아직 앞에 정리했던 강의들은 다시 정리하진 않았지만, 빠르게 복습하며 앞에 정리해둔 블로그들도 다시금 손을 볼 예정이다. 

 모두들 건강하길 바라며...🎃 

코로나 휴유증으로 기력없음과 조금만 움직여도 온몸이 아픔을 겪고 있지만, 앉아서 공부하는 건 큰 기력이 들지 않아 어찌저찌 하고 있다. 오늘은 노트북 존이 있는 스터디카페에서 공부를 했는데 아주 쾌적하고 좋다. 어느 한켠엔 벌레가 있는지 삐리릭- 하고 울어 자연친화적인 느낌이 물씬난다. 피곤에 쩔어 다크서클이 코까지 내려왔지만 오늘도 화이팅!!

🧸 

🧸 구조파악 레츠꼬우- 🧸

 • lifecycle

ㄴ class : NetworkClient, beanLifeCycleTest

✔️  결과값 null

►  BeanLifeCycleTest

@Configuration
static class LifeCycleConfig {
         @Bean
         public NetworkClient networkClient() {
             NetworkClient networkClient = new NetworkClient();
             networkClient.setUrl("http://hello-spring.dev");
             return networkClient;
         }
}

- @Configuration 출처

- @bean 출처

►  NetworkClient

public NetworkClient() {
	System.out.println("생성자 호출, url = " + url); 
	connect();
	call("초기화 연결 메시지");
}

가장 첫번째 코드로 생성자 부분에서 connect( );를 수행한다. 아직 url을 setter로 받아오기전 connect( );를 수행하기 때문에 당연하게도 null 값이 나올 수 밖에 없다.

Q. 초기화 콜백을 하는 이유는?

A. 스프링 라이프 사이클을 제대로 지켜 오류 발생을 방지하기 위함이다.

✔️  초기화 콜백

►  스프링 빈의 이벤트 라이프 사이클

스프링 컨테이너 생성 - 스프링 빈 생성 - 의존관계 주입 - 초기화 콜백 - 사용 - 소멸전 콜백

: 스프링 빈이 생성된 후 의존관계 주입이 이뤄져야한다. 그런데 위의 코드처럼 주입이 모두 이뤄지고 url을 받아오지않고, 빈이 주입이 되기 전 connect( )하고자 했다. 결과값은 null로 나오며 의도대로 동작하지 못했다. 그런 부분을 줄이기 위해 초기화 콜백을 사용하는 것이다.  초기화 콜백을 코드에 넣어 의존관계가 모두 주입되고나서 그 후에 다른 부분의 동작을 수행하도록 하는 것이다.

►  초기화 콜백의 장점

1. 라이프 사이클을 따라 매번 빈이 일관된 상태에서 동작할 수 있도록 해준다.  

2. 빈이 파괴되기 전 리소스를 정리할 시간을 준다.

3. 초기화 로직을 한 곳에 모아둬서 유지보수하기 좋다.

✔️ 인터페이스 InitializingBean, DisposableBean

►  NetworkClient

    @Override
    public void afterPropertiesSet() throws Exception {
    	connect();
	call("초기화 연결 메시지");
    }

afterPropertiesSet( )

:  인터페이스 InitializingBean을 상속받으면 그 안에 정의된 afterPropertiesSet 메서드로 의존관계 주입이 끝나면 초기화를 지원한다.

    @Override
    public void destroy() throws Exception {
        disConnect();
    }

destroy( )

:  인터페이스 DisposableBean을 상속받으면 그 안에 정의된 destroy 메서드로 빈이 파괴될 때 불러온다.

결론 : 상속된 인터페이스에 정의되어있는 메서드를 가져와 쓰기 때문에 이름을 변경할 수 없다. 또한 스프링에 특화되어있는 인터페이스라서 스프링이 사용되지 않는 외부라이브러리에는 사용할 수 없다.

- InitializingBean 출처

- DisposableBean 출처

✔️  빈 등록에 초기화, 소멸 메서드 지정

►  BeanLifeCycleTest

일반적으로 사용하는 것을 추천하지 않는다.

@Bean(initMethod = "init", destroyMethod = "close")
public NetworkClient networkClient() {
    NetworkClient networkClient = new NetworkClient();
    networkClient.setUrl("http://hello-spring.dev");
    return networkClient;
}

initMethod

: 초기화 중에 빈 인스터스에서 호출할 메서드의 선택적 이름이다. 

destroyMethod

: 어플리케이션 컨텍스트를 닫을 때 빈 인스턴스에서 호출한 메서드의 선택적 이름이다. 빈 메서드에서 반환되는 객체에 대해 destroy가 있는지 유추하며 close( ), shutdown( ) 이라는 이름의 인수 없는 공개 메서드만 감지하여 자동적으로 실행한다.

- initMethod와 destroyMethod 출처

►  NetworkClient

public void init() { 
	System.out.println("NetworkClient.init"); 
	connect();
	call("초기화 연결 메시지");
}

public void close() {
         System.out.println("NetworkClient.close");
         disConnect();
}

init( )

:  initMethod를 호출할 선택적 이름이 되겠다.

close( )

: destroyMethod를 호출할 선택적 이름이 되겠다.

외부 라이브러리에 사용할 수 있다. 그 이유는 스프링 코드에 의존하는 것이 아닌, 설정 정보에 의존하기 때문이다. 하지만 스프링에서 권고하는 방식은 아니다. 더 나은 방법이 있기 때문도 있지만 이름을 명시하는 것에서 이름이 달라질 경우 컴파일 오류를 찾는 것이 어렵기 때문이다. (유지보수 측면에서도)

✔️  애노테이션 @PostConstruct, @PreDestroy

►  NetworkClient

스프링에서 가장 권장하는 방식이다.

	@PostConstruct
	public void init() {
		System.out.println("NetworkClient.init"); connect();
		call("초기화 연결 메시지");
	}
    
	@PreDestroy
	public void close() {
		System.out.println("NetworkClient.close");
		disConnect();
	}

@PostConstruct

:  의존성 주입이 완료된 후 실행되는 메서드에 사용하며 주석이 달린 메서드는 하나만 가능하다. 

@PreDestroy

:  인스턴스가 제거되고 있음을 알리는 콜백 알림이며 주석이 달린 메서드는 보유하고 있던 리소스를 해제하는데 사용한다.

- @PostConstruct 출처

- @PreDestroy 출처

코로나에 걸려 일주일은 누워있다 살아났다. 먹고 자고만 반복하니 나태함의 끝판왕이 되어버렸는데... 이렇게 다시 공부를 하려니 배로 힘든 것 같다. 8월엔 꼭 강의를 다 듣겠다고 다짐했었는데,,, 얼마 남지 않은 시간 다른 공부 제처두고 8월 안에 끝내볼까 한다. (과연 할 수 있으려나?) 아무튼 모두들 화이팅!!!!

🧸 

🧸 구조파악 레츠꼬우- 🧸

 • order

ㄴ class : OrderServiceImpl

 • annotation

ㄴ interface : MainDiscountPolicy

 • HelloLombok

 • AllBeanTest

ㄴ class : AllBeanTest

 • AutoWiredTest

ㄴ class : AutoWiredTest

✔️  OrderServiceImpl

►  생성자 주입

지금까지 사용한 방법이 되겠다.

private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;

final

: 초기화되면 변경할 수 없게 된다. 

final을 통해 생성자에 값이 제대로 설정되지 않으면 컴파일 오류를 발생시킬 수 있다. 컴파일 오류를 통해 생성자에 값을 빼먹은 걸 빠르게 알아차릴 수 있다. 그렇기에 생성자 주입 방법을 추천한다.

Q. final을 안쓰게 된다면 어떻게 되나?

A. 코드 개발이 한사람으로 이뤄지는게 아니기 때문에, 다른 개발자가 코드를 수정하게되면 오류가 발생할 수 있다. 거기다 생성자를 만들지 않으면 테스트가 돌아가지 않기 때문에 오류 수정에 용이하다. 생성자 주입에서 final을 붙여야만 코드가 돌아가는 것은 아니다. (근데 그렇데되면 생성자 코드라고 부르기 어렵지 않을까..?)

••• 이어서 다른 코드 부분 •••

@Autowired
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

@Autowired

: 의존관계를 주입해주는데, 생성자가 하나인 경우는 사용하지 않아도 자동적으로 주입이 된다.

OrderServiceImpl은 클래스  MemberRepository와 DiscountPolicy에 있는 memberRepository와 discountPolicy를 필요로 한다. 그렇기에 생성자(객체를 초기화하는 특별한 메서드)를 만들어 그 생성자가 다른 클래스의 객체를 할당받을 수 있도록 의존관계 주입이 이뤄지게 된다.

예를 들어보면, 계산을 해야하는 메서드가 있다고 가정해보자. 계산 메서드에는 회원 정보와 현재 할인 정책에 대한 정보를 필요로 한다. 그 두가지의 정보를 가져오기 위해 회원 정보와 할인 정책 정보를 가지고 있는 클래스가 필요한 것이다. 그래서 의존관계 주입을 통해 현재 클래스와 다른 두 클래스의 정보를 가져오도록 하는 것이다.

(이렇게 이해하긴 했다...)

►  수정자 주입

setter로 통해 의존관계 주입, 의존관계를 누락해도 실행은 된다.

private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;

    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }

setter는 @Autowired를 사용하여 의존관계를 받게된다. 그러면 각 클래스인 MemberRepository와 DiscountPolicy에서 memberRepository와 discountPolicy에 대한 의존관계를 받는 것이다. 그렇게 객체를 final 없이 선언할 때 객체의 상태 변경을 할 수 있게 된다.

생성자 주입에서는 final을 통해 값을 변경할 수 없도록 했지만 setter는 final이 없기 때문에 객체의 상태에 변경이 가능하다. setter는 설정하려는 필드와 동일한 타입의 매개변수를 받아야하며, 자바빈 프로퍼티 규약을 통해 set---라고 메서드를 통해 정보를 수정하는 규칙이 생겼다. 

- setter를 통해 객체 상태 바꾸기 출처

Q. 생성자는 매개변수를 여러개 받을 수 있었다. setter는 하나의 매개변수만 받았다. 왜 그런것인가?

A. 생성자는 객체를 생성할 때 필요한 모든 필드에 대해 값을 주입하는 역할을 한다. ( 값을 받아서 객체를 사용하는 필드에 넣어준다는 것 같다.) 그런데 setter는 객체 상태에 수정이 들어가니 주로 하나의 매개변수만 사용한다. 꼭 setter를 사용할 때 하나의 매개변수만 사용가능한 것은 아니지만 나중에 유지보수를 생각해서 하나씩 사용한다고 한다. 실제로 setter는 사용을 지양하는 추세라고 한다. 이건 전에도 다룬적이 있던 것 같은데, 객체의 상태를 test 코드 혹은 현재 setter 코드 등에서 값을 변경할 수 있기 때문에 오류가 발생할 확률이 높기 때문이다.  

►  필드 주입

필드에 바로 의존관계 주입 (사용하지말자)

    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;

OrderServiceImpl에 각 클래스 MemberRepository와 DiscountPolicy에 관한 의존관계 주입이 바로 이뤄진다.

✔️  AutowiredTest

@Test
void AutoWiredOption() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
}

AnnotationConfigApplicationContext

:  스프링 컨테이너를 생성하며, 빈을 관리하고 의존성 주입을 처리한다.

••• 이어서 다른 코드 부분 •••

static class TestBean {

    @Autowired(required = false)
    public void setNoBean1(Member noBean1) {
        System.out.println("noBean1 = " + noBean1);
    }

    @Autowired
    public void setNoBean2(@Nullable Member noBean2) {
        System.out.println("noBean2 = " + noBean2);
    }

    @Autowired
    public void setBean3(Optional<Member> nobean3) {
        System.out.println("nobean3 = " + nobean3);
    }


}

@Autowired(required = false)

: 자동 주입할 대상이 없으면 수정자 메서드가 없으면 호출 자체가 안된다.

@Nullable

: 자동 주입할 대상이 없어도 호출은 되지만 null값이 된다.

Optional< >

: 스프링 빈이 없으면 Optional empty로 들어온다.

현재 Member 클래스에는 nobean1, nobean2, nobean3과 관련된 bean이 등록되어있지 않기에 오류가 발생할 수 있다. 하지만 각 코드를 추가하여 오류가 발생하는 것을 방지한다. nobean1의 required = true로 하게되면 오류가 발생하게된다. 

Q. AnnotationConfigApplicationContext를 선언을 따로하는 이유는 무엇일까?

A. AnnotationConfigApplicationContext가 무엇을 하는지 이해해야한다. AnnotationConfigApplicationContext은 스프링 컨테이너를 생성하는 역할을 하고 있다. 그리고 생성 후에 bean을 관리하고 의존성을 주입하게 된다. static class TestBean은 스프링 컨테이너에 의해 관리되는 빈이 된다. 만일 따로 선언하지 않고 static class TestBean에 선언하게 되면 주기가 꼬일 수 있게된다. 스프링에 의해 관리되어야할 빈이 그 안에서 스프링을 관리할 수 있도록 선언하고 있으니 주기가 꼬여 제대로 실행되지 못할 수 있다.

Q.  롬복(LomBok) 이란?

A. 코드 반복 작성을 줄여주는 코드 다이어트 라이브러리

✔️  OrderServiceImpl (LomBok)

 @Component
 @RequiredArgsConstructor
 public class OrderServiceImpl implements OrderService {
     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;
}

 @RequiredArgsConstructor

: 초기화 되지않은 final 필드나, @NonNull이 붙은 필드에 대해 생성자를 생성하며, @Autowired를 사용하지 않고 의존성 주입한다.

- @RequiredArgsConstructor 출처

- 롬복 사용 예시 출처

✔️  Autowired 필드 명 매치

<기존 코드>

@Autowired
 private DiscountPolicy discountPolicy

필드가 두 개 (rateDiscountPolicy, fixDiscountPolicy)가 존재한다며 오류가 발생했다.

<변경 후 코드>

 @Autowired
 private DiscountPolicy rateDiscountPolicy

@Autowired는 DiscountPolicy를 타입의 빈을 주입하기 위해 DiscountPolicy를 찾아나서게 된다. 그런데 DiscountPolicy 타입에는 rateDiscounPolicy와 fixDiscountPolicy인 동일 타입의 빈이 두 개가 있음을 알게된다. 그렇기에 오류가 발생하고 코드를 변경하여 타입 기반에서 이름 기반 코드로 수정시켜준 것이다. rateDiscountPolicy 빈이 제대로 등록되어있다면 해당 빈으로 주입한다.

✔️  @Qualifier 사용

 @Component
 @Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

public OrderServiceImpl(MemberRepository memberRepository
		,@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {

 @Component
 @Primary
 public class RateDiscountPolicy implements DiscountPolicy {}

@Primary를 붙여서 DiscountPolicy의 타입에서 RateDiscountPolicy 빈이 가장 우선적으로 의존성 주입되도록 하는 방식이다. 메인 데이터베이스의 커넥션 획득이 필요한 경우 @Primary를 사용하고 서브 데이터베이스 커넥션 획득이 필요한 경우 @Qualify를 사용하는 것이 용이하다.

✔️  MainDiscountPolicy

애노테이션 직접 만들기

 @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
 ElementType.TYPE, ElementType.ANNOTATION_TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 @Qualifier("mainDiscountPolicy")

@Target

: 애노테이션 적용 대상

@Retention

: 애노테이션 지속 시간 결정

@Documented

: 애노테이션 정보를 javadoc으로 작성한 문서에 포함

@Qualifier("mainDiscountPolicy")` 이렇게 문자를 적으면 컴파일시 타입 체크가 안되기 때문에 애노테이션을 직접 만들주었다. 

- 애노테이션 출처

@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy { } 

이렇게 사용이 가능해진다. 생성자 주입이나 수정자 주입에도 마찬가지로 사용가능하다.

✔️  AllBeanTest

해당 타입의 모든 빈이 필요한 경우 Map과 List를 사용한다.

►  findAllBean( )

   ApplicationContext ac
     = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);

	DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");

- getBean 출처

►  DiscountService

public DiscountService(Map<String, DiscountPolicy> policyMap,List<DiscountPolicy> policies){
            this.policyMap = policyMap;
            this.policies = policies;
}

생성자를 만들었다. 생성자는 DiscountPolicy 타입을 <빈이름, 빈> 쌍으로 받는 Map이 있고, 모든 DiscountPolicy 빈을 리스트 형태로 받는 List로 만들었다. 

••• 이어서 다른 코드 부분 •••

 public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode); 
            return discountPolicy.discount(member, price);
}

이 메서드가 할인 정책을 적용하게 한다. discountCode는 Test 코드에서 fixDiscountPolicy로 받았다. 그러면 policyMap을 통해 fixDiscountPolicy 빈을 찾아 discountPolicy라는 이름으로 받는다. 그러면 discountPolicy는 fixDiscountPolicy가 되는거고 fixDiscountPolicy의 정책인 'Vip는 얼마를 구매하든 1000원을 할인해주는 것'에 맞춰 할인이 진행된다. 그렇다면 member는 vip이며 10000원을 구매했다는 test 코드에 맞춰 1000원을 할인해주면 되는 것이다.

Map과 List를 사용하여 타입에 맞는 모든 빈을 가져온 후, 고객 혹은 테스트에 맞는 빈을 찾아 메서드를 수행하는 방식이다.

Q. 모든 빈을 가져올 때 꼭 Map과 List 둘 다 써야하는걸까?

A. 하나만 사용한다고 해서 어떤 문제가 생기는 것은 아니다. Map은 <키 혹은 이름>을 가지고 빈을 빠르게 찾는 것이고, List는 순서에 따라 모든 빈을 처리할 수 있는 특성을 가지고 있다. 현재는 적은 빈으로 테스트를 진행하고 있지만 실무는 훨씬 많은 빈으로 테스트 혹은 프로그램을 돌리기 때문에 두 특성을 모두 가지고 있어야 유연하게 적용할 수 있다.

컴포넌트 스캔까지 어찌저찌 왔다. 사실 블로그 정리만 아니었어도 강의는 한달 안에 끝냈을 듯... 그래도 블로그 정리하면서 평소 그냥 넘겼을 질문들 몽땅 찾아보는 중이다. 시간이 오래 걸리지만 그만큼 내 머리의 지식도 하나 둘 채워지고 있음을 느낀다. (사실 블로그 정리에 오랜 시간이 걸려 현타와서 주절주절 적어본다) 이번 섹션 6은 강의가 짧아서 빨리 끝날지도 모른다는 기대감이 있다. 우리집 에어컨 고장나서 안나오지만,,,🥲 더위 이겨내고! 모두들 화이팅!!!

🧸 

🧸 구조파악 레츠꼬우- 🧸

• main
  ㄴ class : AutoAppConfig
  
• test - scan
  ㄴ class : AutoAppConfigTest
  
  
• test - scan - filter
  ㄴ class : BeanA, BeanB, ComponentFilterAppConfigTest
  ㄴ Annotation : MyExcludeComponent, MyIncludeComponent

Q.  컴포넌트 스캔이란?

A. 설정정보가 없어도 자동으로 스프링 빈을 등록한다.

✔️  AutoAppConfig

컴포넌트 스캔 설정

@ComponentScan(
        basePackages = "hello.core.member",
        basePackageClasses = AutoAppConfig.class,
        excludeFilters = @ComponentScan.Filter
			(type = FilterType.ANNOTATION, classes = Configuration.class)
)

@ComponentScan

: @Component어노테이션 및 streotype(@Service, @Repository, @Controller.)어노테이션이 부여된 클래스들을 자동으로 Scan하여 Bean으로 등록해주는 역할을 하는 어노테이션이다.

basePackages

:  String으로 입력된 패캐지의 경로를 스캔하는 방법으로 직접 스캔할 위치를 지정한다.

basePackageClasses

:  적힌 클래스가(패키지 안) 위치한 곳부터 모든 어노테이션을 부여된 클래스를 bean으로 등록해준다. 

excludeFilters 

:  객체를 제외한다. (AppConfig에 수동으로 등록한 것들은 빼준다)

includeFilters

: @Component 어노테이션이 사용된 객체를 불러오고 싶으면,  includeFilters 설정을 사용한다. 특정 조건을 만족하는 클래스만을 스캔하도록 지정한다. 

- @ComponentScan 출처

- @ComponentScan 출처

Q. basePackages보다 basePackagesClasses를 쓰는걸 권장한다. 왜 그런 것일까?

A. 컴포넌트 스캔이 어떻게 동작하는지 이해해야한다. 컨포넌트 스캔을 하려면 @SpringBootApplication을 살펴봐야한다. @SpringBootApplication에는 @ComponentScan을 가지고 있고 @ComponentScan을 가지고 있는 어노테이션이 시작지점이다. @ComponentScan을 붙이고 있는 그 클래스부터 컴포넌트 스캔을 시작한다. 설정해 놓은 패키지들 중에서, 해당 패키지와 하위 패키지에 대해서 @Component 같은 스테레오 타입 어노테이션이 붙은 클래스를 모두 찾아서 빈으로 등록한다. 그러니까 이런식으로 가는게 spring에서 제공하는 기본적인 경로인 것 같다. 그런데 basePackages는 내가 직접 경로를 적는 것으로 springboot에서 제공되는 최상위 패키지부터 시작하지 않게된다는 것이다. springboot에서 제공하는 기본값을 사용하는 것이 더 효율적이고 향후 프로젝트가 커짐에 따라 복잡성을 줄여준다.

- basePackage를 권장하지 않는 이유 출처

- ComponentScan 동작 출처

••• 이어서 다른 코드 부분 •••

public class AutoAppConfig {

}

현재 AutoAppConfig 클래스의 역할은 컴포넌트 스캔을 설정하는 것이기 때문에 메서드나 다른 코드는 적지 않는다.

✔️  OrderServiceImpl

의존관계자동주입

@Component
public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    
    ...
}

@Component

:  @Component 어노테이션을 이용하면 Bean Configuration 파일에 Bean을 따로 등록하지 않아도 사용할 수 있다. 

@Autowired

:  생성자에서 여러 의존관계도 한번에 주입받을 수 있다.

• @Component
: Bean 객체를 가져올 수 있으며(컴포넌트 스캔에 사용), IoC컨테이너 객체를 생성할 때 자동으로 객체 생성되면 Sigleton이다. 

• @Controller
: 스프링 MVC 컨트롤러에 사용하며, Dispatcher(HTTP프로토콜로 들어온 요청을 받아 적합한 컨트롤러에게 위임)은 @Controller가 있는 클래스들을 확인해서 @RequestMapping이 있는 메서드들을 확인합하여 요청을 처리한다.

• @Service
: 비지니스 로직에 있으며 저장소 계층을 사용한다.

• @Repository
: 데이터 엑세스 계층에서 사용한다. 주로 컴포너는 스캔 대상이 되기 위해 사용하지만, 스프링부트와 JPA를 사용할 경우 예외 변환기를 자동으로 등록해서 @Repository를 적용한 빈을 프록시로 변환한다.

• @Configuration
:  설정파일을 만들기 위한, Bean을 등록하기 위한 애노테이션이다. 싱글톤을 유지하도록 추가적으로 처리한다.

- @Controller, @Service 출처

- @Repository 출처

- @Configuration 출처

✔️  AutoAppConfigTest

컴포넌트 스캔이 잘 작동되는지 확인

 @Test
    void basicScan() {
        AnnotationConfigApplicationContext ac 
				 = new AnnotationConfigApplicationContext(AutoAppConfig.class);

AnnotationConfigApplicationContext는 AutoAppConfig의 인자를 받아 스프링 설정 클래스로 인식한다. AutoAppConfig에 @Configuration을 적어놓았으니 인식이 되는 것이다. AutoAppConfig에는 아까 @Componentscan에 대한 정보들을 적어놓았다. 그럼 그걸 기반으로 컴포넌트를 스캔해 빈으로 등록하고 의존성을 주입한다. 모든 준비가 완료되면AnnotationConfigApplicationContext는 완전히 초기화되며 기능을 수행하게 된다.

••• 이어서 다른 코드 부분 •••

        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberService.class);
    }

스프링 컨테이너에서 MemberService 타입의 빈을 조회한다. 조회된 빈이 MemberService타입인지 검증하여 설정이 올바르게 작동하는지 확인한다.

assertThat(A).isInstanceOf(B);

: isInstanceOf() 는 해당 타입의 인스턴스인지를 비교하는 메서드다. 

✔️  MyExcludeComponent

컴포넌트 스캔 대상에서 제외할 애노테이션

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {

}

@interface 

: 자바에서 제공하는 어노테이션 외에, 사용자가 커스텀할 수 있는 어노테이션이다. @interface는 클래스나 변수를 특정 값으로 지정하여 관리할 수 있다.

@Target

:  사용자가 만든 annotation이 부착될 수 있는 타입을 지정한다. 

@Target({ElementType.TYPE})은 클래스, 인터페이서, Enum 또는 Record에 붙일 수 있다는 의미이다.

@Retention

: 해당 어노테이션을 언제까지 유지할건지 지정한다.

@Retention(RetentionPolicy.RUNTIME)은 Java로 작성한 코드가 돌아가는 동안 유지한다는 의미이다.

@Documented

:  어노테이션에 대한 정보가 javadoc으로 작성한 문서에 포함되도록 하는 어노테이션이다.

Q. Docummented를 써서 문서에 포함되도로 하는 이유가 무엇인가?

A. 다른 개발자가 개발된 코드를 보았을 때 어떤 코드인지 쉽게 파악할 수 있도록 해준다. 어노테이션을 왜 썼는지 등 설명을 포함시킬 수 있기 때문에 @Documented를 함께 적어 다른 개발자의 이해를 돕는다. 특히 라이브러리나 프레임워크 개발할 때 유용하다.

- @Target @Retention 출처

- @Docummented 출처

✔️  BeanB

컴포넌트 스캔에서 제외할 클래스

@MyExcludeComponent
public class BeanB {

}

아직까진 제외를 할 수 있는 어떤 기능이 실행된 것은 아니다. @MyExcludeComponent를 적어주어 아까 만들었던 애노테이션과 연결했다.

Q. 왜 애노테이션을 만드는가?

A. 애노테이션을 만드는 이유는 사용자가 원하는대로 설정 정보를 커스텀할 수 있기 때문이다. 꼭 컴포너트 스캔에 어떤 클래스를 포함하고 제외시키기 위함은 아니다. (제외는 다른 클래스에서 부여함) 아까 런타임 시간을 지정하는 것과 같이 개발자가 필요한 설정정보를 만들어 다른 클래스에 편리하게 부여할 수 있다.

✔️ ComponentFilterAppConfigTest

BeanA beanA = ac.getBean("beanA", BeanA.class);
Assertions.assertThat(beanA).isNotNull();

getBean

: ac(스프링 애플리케이션 컨텍스트)에서 beanA 이름으로 BeanA라는 타입으로 가져오는 것을 뜻한다.

Assertions.assertThat(A).isNotNull( )

: A가 Null인지 확인한다.

- Assertions.assertThat().isNotNull() 출처

assertThrows(
        NoSuchBeanDefinitionException.class,
        () -> ac.getBean("beanB", BeanB.class));
}

NoSuchBeanDefinitionException

: BeanFactory정의를 찾을 수 없는 빈 인스턴스를 요청했을 때 예외가 발생한다.

NoSuchBeanDefinitionException.class, () -> ac.getBean("beanB", BeanB.class)은 BeanB를 beanB라는 이름으로 가지고 왔는데 그게 정의를 찾을 수 없는 빈 인스턴스여야 테스트가 성공하는 것이다.

- NoSuchBeanDefinitionException  출처

••• 이어서 다른 코드 부분 •••

@ComponentScan(
            includeFilters = @Filter(classes = MyIncludeComponent.class),
            excludeFilters = @Filter(classes = MyExcludeComponent.class)
    )

@Filter

: 필터는 주로 요청에 대한 인증, 권한 체크 등에  쓴다. 구체적으로 들어온 요청이 DispatcherServlet에 전달되기 전, 헤더를 검사해 인증 토큰이 있는지 없는지, 올바른지, 옳지 않은지 등을 검사한다.

- Filter 출처

excludeFilters

:  속성을 사용하여 특정 대상을 스캔에서 제외시킨다.

Q. 그럼 다시 포함시키고 싶으면 어떻게 해야하나?

A. includeFilters = @Filter(classes = MyExcludeComponent.class)로 바꿔주면 된다.

- excludeFilters 출처

@ComponentScan을 통해 속성을 살펴본다. 속성엔 MyExcludeComponent를 excludeFilters하라고 적혀있다. 그러면 MyExcludeComponent를 제외시키도록 되어있으니 @MyExcludeComponent가 붙어있으면 제외시키도록 한다. 그런데 BeanB에는 @MyExcludeComponent가 붙어있으니 제외가 되었다.

🌷

컴포넌트 스캔이 필요한 경우 @ComponentScan을 쓰고 { } 안에 원하는 특성을 넣을 수 있음을 알아봤다.

그리고 컴포넌트 스캔에 대한 요구를 설정하고 싶은 겨우 @interface와 클래스를 연결시킬 수 있다.

📚 책 소개하기

내가 사용한 자바완전정복 책 링크!
ㄴ 김동형 지음, 이지스퍼블리싱

이 책을 고르게 된 이유는 친구의 추천이었다. 굉장히 꼼꼼하게 적혀있어 이해하기 쉽다는 이유로 친구는 이 책을 골랐다고 했다. 나도 그래서 그냥 따라샀다. 실제로 책을 살펴보니 굉장히 꼼꼼하게 정리되어있다. 다른 책은 본 적이 없어 비교가 불가하지만, 내 생각으론 처음 자바를 공부한다면 이 책을 가지고 충분히 따라갈 수 있을 듯 하다. 모두들 화이팅!!

🐰

✔️  1차원 배열_ 151p

동일한 자료형을 묶어 저장하는 참조 자료형

• 참조자료형

: 실제 값을 갖는것이 아닌 데이터가 저장된 메모리의 “주소 값”을 가지는 자료형이며, 해당 값은 객체를 참조하는 변수 타입을 의미한다.

- 참조자료형 출처

• 자바의 메모리 구조

: 클래스-정적-상수- 메서드 영역 , 스택 영역(모든 지역 변수 위치), 힙 영역(객체가 위치하는 공간)

Q. 전역변수와 지역변수란?

A. 전역변수는 프로그램의 모든 영역에서 접근할 수 있는 변수로, 함수 외부, 특히 모듈의 최상위 레벨에서 선언한다. 그렇다면 지역변수는 한정된 영역인 블록, 함수, 메서드 내부에서 사용되는 변수를 말한다.

Class example {

	int globalVar = 1; // 전역변수
    
    void method() {
    	int localVat = 2;  // 지역변수
    }
}​

- 전역변수와 지역변수 예제 출처

• 기본 배열과 객체 대입 배열

// 기본적인 배열 형태
new int[3];

// 배열 자료형 변수에 객체 대입하기
int[] a = new int[3];

// 값 입력하기
a[1] = 3;
a[2] = 2;
a[3] = 1;

1.  int는 배열 자료형이다.
2.  a는 참조 변수다.
3.  new는 힙 메모리에 넣어라를 뜻한다.
4.  int[3]은 int 자료형 3개를 저장할 수 있는 공간이다.

a는 참조변수로 실제 데이터 값을 저장하는 것이 아니다. 실제 데이터값의 '위치값'을 저장하는 것이다.  스택 영역엔 주소값을 그리고 이 주소값을 가지고 힙 영역에 접근한다. 즉 힙 영역에 배열이 저장되어있다. 

• 1차원 배열의 다양함

// 생성 후 값 대입
int[] a = new int[3]; // 강제초기화
a[0] = 3;
a[1] = 4;
a[2] = 5;


// 생성과 함께 값 대입
int[] a = new int[]{3, 4, 5} // 강제초기화 생략


// 대입할 값만 입력 (분리 불가능)
int[] a = {3, 4, 5}


// 선언과 객체 분리 가능
int[] a;
a = new int[]{3, 4, 5}

Q. 배열을 어떻게 선언하는지에 따라 사소한 기능적인 차이가 있는가?

A. 두 배열을 어떻게 선언하는지에 따른 기능적 차이점은 없다. 코드의 가독성, 유연성, 명확성을 높이기 위해 다른 형태의 배열이 존재한다. 

• 참조 변수와 배열 객체의 값 초기화

: 모든 변수는 초기화 이후에 출력 가능하다.

int a;
int[]b;

System.out.println(a);
System.out.println(b);

각 값을 초기화하지 않았기에 출력이 불가능하다. (오류 발생)

int a  = 0;
int[ ]b = null;

 

기본 자료형의 초깃값으로는 '값', 참조 자료형의 초깃값으로는 'null' 을 사용한다. 

기본자료형의 기본값
- boolean : false
- 정수 : 0
- 실수 : 0.0

참조자료형의 기본값
- 클래스, 배열 등 : null

✔️  참조자료형 배열의 특징_ 151p

참조자료형은 기본자료형과 다르게 복사 값을 수정하면 본래 값도 변경된다.

• 참조자료형 변수 복사

int[] a = {3, 4, 5}
int[] b = a;
b[0] = 7;

System.out.println(a[0]);
System.out.println(b[0]);

결과값은 a[0]과 b[0]이 7로 동일하다. 

Q. 왜 복사값을 변경하면 본래값도 변경되는걸까?

A. 참조 자료형 변수를 복사하면 실제 데이터가 복사되는 것이 아니라, 실제 데이터의 위치값을 복사(스택 메모리에 있는)하기 떄문이다. 그렇기에 하나의 참조 변수를 이용해 데이터를 수정하면 다른 참조 변수가 가리키는 데이터도 변하게 되는 것이다.

Q. 기본자료형은?

A. 스택 메모리에 실제 데이터값을 저장하기 때문에 기본 자료형 변수를 복사하면 실제 데이터값 1개가 복사된다. 그렇기에 아무리 변경해도 원본 값은 영향을 받지 않는다.

int a = 3;
int b = a;
b = 7;

a는 여전히 3이 나오고 b는 7이 된다.

✔️  반복문을 이용해 배열 데이터 읽기_ 165p

포인트 연산자를 이용

• 포인트연산자

int[] a = new int[100]

a[0] = 1, a[1] = 2, ... , a[99] = 100;

for(int i = 0; i < a.length; i++) {
	System.out.println(a[i]);
}

포인트연산자는 '해당 참조 변수가 가리키는 곳으로 가라'는 의미이다.
배열참조변수.length는 '배열 참조 변수가 가리키는 곳에 가면 배열 객체가 있는데, 그 배열의 방의 개수를 가져오라'는 의미이다.

• for-each문

int[] a = new int[100];
a[0] = 1, a[1] = 2, ... , a[99] = 100;

for(int k: a) {
	System.out.println(k);
}

for-each문은 배열이나 컬렉션의 모든 요소를 순회하는데 사용되는 간결한 반목문이다.
for(int k: a)는 for(원소 자료형 변수명: 집합객체)로 배열이나 컬렉션 객체를 통해 자동으로 인덱스를 처리하고, 요소를 순차적으로 가져와 변수에 할당한다.

- for each 구문 출처

✔️  2차원 정방 행렬 배열_ 169p

• 1차원 배열과 다른점

: 메모리는 2차원 데이터를 바로 저장할 수 없다. 왜냐하면 메모리가 연속적인 주소 공간으로 구성된 1차원 배열이기 때문이다. 그렇기에 1차원 데이터들로 나눠 2차원 배열을 저장하며 2차원 배열은 1차원 배열을 원소로 포함하고 있는 1차언 배열이라고 생각할 수 있다.

Q. 그렇다면 3차원 배열은?

A. 3차원 배열은 2차원 배열을 원소로 포함하는 1차원 배열이다. 행과 열 그리고 면을 포함하여 3차원을 완성한다.

• 2차원 배열의 메모리 구조

// 배열 객체를 생성하고 값 대입
int[][] a = new int[2][3];
a[0][0] = 1; a[0][1] = 2; a[0][2] = 3;
a[1][0] = 4; a[1][1] = 5; a[1][2] = 6;

a.length은 2이다. a인 100번지가 가리키는 곳에 200과 300이 있으니 2가 출력된다.
a[0]은 200번지이며 200번지가 가리키는 곳으로 가니 1과 2, 3이 있다. 그렇기에 a[0].length는 3이 출력된다.

각 주소값이 가리키는 곳의 갯수를 새면 된다.

• 행 성분부터 생성하고 열 성분 생성

// 행 성분부터 생성하고 열 성분 생성
int[][] a = new int[2][]

a[0] = new int[]{1,2,3};
a[1] = new int[]{4,5,6};

행을 먼저 생성하여 100번지에 있을 행의 갯수를 미리 정해주는 것이다. 열의 개수는 어차피 1차원 배열로 이어지기 때문에 미리 정해주지 않아도 된다.

• 배열의 자료형과 함께 대입할 값 입력

: 대괄호 안은 반드시 크기를 지정하지 않는다.

int[][] a = new int[][] {{1, 2, 3}, {4, 5, 6}}

• 대입할 값만 입력하기

// 대입할 값만 입력
int[][] a = {{1,2,3} , {4,5,6}};

✔️  2차원 비정방 행렬 배열_ 178p

행마다 열의 길이가 다른 2차원 배열

• 이중 for문을 이용한 2차원 배열 원소 출력

int[][] a = {{1, 2}, {3, 4, 5}}

for(int i = 0; i < a.length; i++) {
	for(int j = 0; j < a[i].length; j++) {
    		System.out.println(a[i][j]);
    }
}

열의 길이가 다르니 열을 출력할 때  j < a[i].length;를 써준다.

• 이중 for-each문을 이용한 2차원 배열 원소 출력

int[][] a = {{1, 2, 3}, {4, 5, 6}};

for(int[] m: a) {
	for(int n: m) {
    		System.out.println(n);
     }
}

m은 배열 a의 각 행을 참조하는 1차원 배열이 된다. ( a[0]과 a[1] )
n은 각 행 안에 있는 원소들이 된다. a[0]의 있는 1,2,3이 각 n이 된다.

📚 책 소개하기

내가 사용한 자바완전정복 책 링크!
ㄴ 김동형 지음, 이지스퍼블리싱

이 책을 고르게 된 이유는 친구의 추천이었다. 굉장히 꼼꼼하게 적혀있어 이해하기 쉽다는 이유로 친구는 이 책을 골랐다고 했다. 나도 그래서 그냥 따라샀다. 실제로 책을 살펴보니 굉장히 꼼꼼하게 정리되어있다. 다른 책은 본 적이 없어 비교가 불가하지만, 내 생각으론 처음 자바를 공부한다면 이 책을 가지고 충분히 따라갈 수 있을 듯 하다. 모두들 화이팅!!

🐰

✔️  switch 선택 제어문_ 119p

점프 위치 변숫값에 따라 특정 위치(case)로 이동해 구문을 실행하는 선택 제어문

• 일반 switch( )

int a = 2;

switch(a) {
case 1:
	System.out.println("A");
case 2:
	System.out.println("B");
case 3:
	System.out.println("C");
default:
	System.out.println("D");
}

1)  switch(a)에서 a 안에 들어가는 숫자는 2이다.
2)  case 2로 이동하여 B를 출력시킨다.
3)  break 문이 없으므로 case3과 default도 실행된다.

• break가 있는 switch( )

int a = 8;

switch(a) {
case 10:
case 9:
case 8:
case 7:
	System.out.println("Pass");
    	break;
default:
	System.out.println("Fail");

1)  7점 이상은 Pass, 그 이하는 Fail을 주는 코드로 간결하게 작성했다.
2)  switch(a)의 a에 들어갈 숫자는 8로 case 8에 해당한다.
3)  하지만 case 8에 별다른 조건이 없으므로 case 7로 이동한다.
4)  Pass를 결과로 출력시킨다.
5)  break; 문을 통해 빠져나간다.

Q. if 선택 제어문과 switch 선택 제어문의 차이점은 무엇인가?

A. if 문은 어떤 값을 출력하느냐에 따라 조건식을 몇 개 비교할 것인지 달라져 값에 따라 속도가 달라진다. 반면 switch문은 동일하게 한 번의 점프만을 수행한 후 실행되므로 모든 출력 속도가 동일하다.

✔️  while 반복 제어문_ 129p

소괄호 안의 조건식이 true인 동안 반복은 지속된다. (횟수가 아닌 특정 조건까지 반복)

• 기본 while

int a = 0;

while(a < 10) {
	System.out.println(a);
    a++;
}

1)  int a = 0은 초기식이다.
2)  while(조건식)이다.
3)  System.out.println(a);는 실행구문이다.
4)  a++;는 증감식이다.

✔️  do - while 반복 제어문_ 134p

while문과 비슷한 반복 제어문, 반복 실행의 순서에만 차이가 있다.

• 기본 do - while

a = 0;

do {
	System.out.print(a + " ");
    	a++;
} while (a < 0);

1)  a = 0;은 초기값이 된다.
2)  do 괄호 안에는 실행구문과 증감식이 있다.
3)  그 후 while (조건식);이 있다.

Q. while문과 do-while문의 차이점은?

A. while문은 조건식이 먼저 나타나있다. 조건이 false이면 괄호 안으로 들어가지 않고 끝나기 때문에 한 번도 실행되지 않는다. 그런데 do - while문은 조건식이 마지막에 있다.  그렇기에 한 번은 실행된다. 

Q. do-while문을 쓰는 경우는 언제인가?

A. 조건이 만족하지 않아도 무조건 한 번은 돌아야하는 경우 do-while문을 쓴다. 예시로 메뉴로 사용자가 유효한 선택을 할 때까지 떠야하는 경우 혹은 게임이 한 번은 무조건 실행되고 그 후 사용자가 선택시 다시 실행되는 경우에도 속한다. 

✔️  break 제어 키워드_ 139p

if문을 제외한 가장 가까운 중괄호를 탈출하는 제어키워드

• 간단한 break 

for (int i = 0; i <10; i++) {
	System.out.println(i);
  	break;
}

1)  i =0 일 때 실행된다.
2)  System.out.println(i);에 0이 출력된다.
3)  증감되지 않고 바로 아래줄에 있는 break;를 괄호 밖으로  나간다. 

• if문 안에 있는 break

for(int i = 0; i < 10; i++) {
	if(i == 5) {
    	break;
    }
    System.out.println(i);
}

1)  if( i == 5)에 맞춰 i가 5가 될 때까지 i는 증가한다.
2)  i가 5가 되면 반복문에서 빠져나온다.
3)  system.out.println(i);가 실행된다. 
4)  if문 자체가 break를 실행할 조건문이 되는 것이다.

• 레이블을 이용한 break

out:
for(int i = 0; i < 10; i++) {
	for(int j = 0; j <10; j++) {
    		if(j == 3)
        		break out;
        	 System.out.println(i + "," + j);
     }
}

1)  이중 for문으로 들어간다.
2)  if문의 조건에 맞춰 3이 되면 break가 실행된다.
3)  for문을 완전히 벗어나게 된다.

✔️  continue 제어 키워드_ 143p

닫힌 중괄호 역할을 하는 제어키워드

• if 문과 함께 사용된 continue

for(int i = 0; i < 10; i++) {
	if(i == 5) {
    	continue;
    }
    System.out.println(i);
}

1)  if문의 조건에 맞춰 i가 5가 되었다.
2)  countinue에 맞춰 i == 5에 대한 출력값은 넘어가게 된다.
3)  i의 출력값으로는 0,1,2,3,4,6,7,8,9 까지 나오게 될 것이다.

만일 결과값이 강의와 다르게 나온다면,

AppConfig의 MemberRepository 앞에 static이 붙어있는지 확인하라!

Q. 왜 static을 쓰면 인스턴스 값이 다르게 할당될까?

A. static을 붙이게 되면 spring의 bean 라이프 사이클 관리가 정상적으로 이루어지지 않기 때문에 같은 타입의 bean이 여러 인스턴스로 생성되게 된다.

👁️‍🗨️  static 이란?

1. 클래스 레벨의 변수나 메소드에 사용되며, 이를 통해 객체 생성 없이 해당 변수나 메소드에 접근할 수 있습니다.

2. static 멤버는 클래스가 메모리에 로드될 때 단 한 번만 생성되며, 모든 인스턴스가 공유하는 공통의 자원이 됩니다.

3. 클래스 단위로 관리되어 메모리 사용량을 줄이고, 객체 생성 오버헤드 없이 접근할 수 있다.

- Static 출처

👁️‍🗨️  static이 spring의 라이프 사이클을 어떻게 꼬는 것인가?

(정확하게 이해한 건 아닙니다🥲)

1. 원래 spring의 라이프 사이클은 @Configuration 클래스의 인스턴스를 생성하고 @bean 메서드를 호출해야한다.

2. 그런데 static을 bean 메서드에 정의하게 되면, static의 특성인 객체 생성 없이 해당 변수나 메소드에 접근하기 때문에  1번의 사이클을 따라가지 않게 된다. 

3. 그렇기에 메서드가 클래스 레벨에서 호출되어(static의 특징) @Configuration의 인스턴스 생성 없이도 메서드를 호출하게 되고 spring의 라이프 사이클을 깨게 만들어 싱글톤 보장을 해주지 못하게 된다.

👁️‍🗨️  static과 spring bean의 차이점은 무엇인가?

- static과 bean의 공통점과 차이점 출처