Hello world;

SpringBoot는 프레임 워크이고 프레임 워크란 정해진 규칙이 있는것이다.

규칙 1. MVC 패턴을 사용한다

규칙2. 계층간 데이터를 이동할때 다른 계층을 사용하지 않는다. 

이때 MVC계층이란

1. Model : 핵심적인 비즈니스 로직(연산, 데이터 정제, 데이터베이스의 통신) 계층, 즉 View에 적용할 정보들

2. View : 화면을 보여주기 위한 계층(동적 HTML 파일)

3. Controller : 유저의 요청을 수신하는 계층(Client 의 요청을 Model 로 받아 처리)

 

MVC는 Model, View, Controller의 약자이며, 각 레이어 간 기능을 구분하는데 중점을 둔 개발 방법론 중 하나입니다. Model은 데이터 관리 및 비즈니스 로직을 처리하는 부분이며, View는 비즈니스 로직의 처리 결과를 통해 유저 인터페이스가 표현되는 구간입니다. Controller는 사용자의 요청을 처리하고 Model과 View를 중개하는 역할을 합니다. Model과 View는 서로 연결되어 있지 않기 때문에 Controller가 사이에서 통신 매체가 되어줍니다.( 데이터와 비즈니스 로직 사이의 상호작용을 관리)

1. 모델(Model): 모델은 애플리케이션의 비즈니스 로직 및 데이터를 관리합니다. 이는 데이터베이스와의 상호 작용, 쿼리 수행, 데이터 조작 등을 수행하며, 애플리케이션의 '상태'를 나타냅니다.
2. 뷰(View): 뷰는 사용자에게 보여지는 부분으로, 사용자 인터페이스(UI)와 데이터의 시각적 표현을 담당합니다. 일반적으로 HTML, CSS, JavaScript 등을 사용하여 웹 페이지를 생성하거나 업데이트합니다.
3. 컨트롤러(Controller): 컨트롤러는 모델과 뷰 사이의 인터페이스로 작동하며, 사용자의 입력을 처리하고 적절한 응답을 생성하는 역할을 합니다. 사용자의 요청을 받아 이를 모델에 전달하여 상태를 변경하거나, 모델에서 데이터를 가져와 뷰를 업데이트합니다.

**스프링 MVC 동작원리

1. Client → DispatcherServlet
   • 가장 앞 단에서 요청을 받아 FrontController 라고도 불림
2. DispatcherServlet → Controller
   • API 를 처리해 줄 Controller 를 찾아 요청을 전달
   • Handler mapping 에는 API path 와 Controller 함수가 매칭되어 있음
3. Controller → DispathcerServlet
   • Controller 가 Client 으로 받은 API 요청을 처리
   • 'Model' 정보와 'View' 정보를 DispatcherServlet 으로 전달
4. DispatcherServlet → Client
   • ViewResolver 통해 View 에 Model 을 적용
   • View 를 Client 에게 응답으로 전달

** Template engine : View 에 Model 을 적용 → 동적 웹페이지 생성

1. 예) 로그인 성공 시, "로그인된 사용자의 id" 를 페이지에 추가
2. Template engine 종류: 타임리프 (Thymeleaf), Groovy, FreeMarker, Jade 등 (스프링에서 JSP 이용은 추천하지 않고 있음)

* MVC 패턴이란 무엇이며, 그 장점은 무엇인가요?

MVC(Model-View-Controller)는 소프트웨어 디자인 패턴 중 하나로, 특히 웹 개발에서 널리 사용됩니다. 이 패턴은 애플리케이션을 세 가지 역할로 분리합니다:

1. 모델(Model): 모델은 데이터와 비즈니스 로직을 관리하는 컴포넌트입니다. 이는 데이터베이스와 상호작용하고, 애플리케이션의 상태를 유지합니다.
2. 뷰(View): 뷰는 사용자에게 보여지는 부분으로 사용자 인터페이스를 관리합니다. 사용자가 볼 수 있는 데이터의 표현을 담당하며, 일반적으로 웹 페이지나 화면을 구성하는 역할을 합니다.
3. 컨트롤러(Controller): 컨트롤러는 사용자의 입력을 받아 모델과 뷰에 전달하는 역할을 합니다. 사용자의 요청을 해석하고 그에 따라 모델의 상태를 변경하거나, 모델의 상태에 따라 뷰를 업데이트합니다.

MVC 패턴의 주요 장점은 다음과 같습니다:

1. 모듈화와 재사용성: MVC 패턴은 코드의 모듈화를 촉진하며, 이로 인해 각 컴포넌트를 독립적으로 개발하고 테스트할 수 있습니다. 이는 코드의 재사용성을 증가시킵니다.
2. 유지보수성: 각 컴포넌트가 독립적인 역할을 가지므로, 한 컴포넌트의 수정이 다른 컴포넌트에 미치는 영향을 최소화합니다. 이는 유지보수를 용이하게 합니다.
3. 동시 개발 가능: 서로 다른 개발 팀이 모델, 뷰, 컨트롤러를 독립적으로 개발할 수 있으므로, 개발 시간을 단축시킬 수 있습니다.
4. 높은 확장성: 새로운 기능이 필요할 때 모델, 뷰, 컨트롤러 중 필요한 컴포넌트만 추가하거나 변경하면 됩니다. 이는 애플리케이션의 확장성을 증가시킵니다.
5. 유연성: MVC 패턴은 프레젠테이션 레이어와 비즈니스 로직 레이어를 분리함으로써 유연성을 제공합니다. 예를 들어, 사용자 인터페이스를 변경하고 싶을 때 뷰만 수정하면 되고, 데이터 처리 방식을 변경하고 싶을 때는 모델만 수정하면 됩니다.
6. 효율적인 코드 관리: MVC 패턴은 애플리케이션의 코드 구조를 논리적으로 구성함으로써 코드의 관리를 용이하게 합니다. 코드의 논리적인 구성은 코드의 가독성과 이해를 쉽게 만듭니다.
7. 다중 뷰 지원: 하나의 모델에 대해 여러 뷰를 가질 수 있습니다. 예를 들어, 웹 애플리케이션의 데이터를 다양한 방식으로 표시할 수 있습니다.
   더보기

   다중 뷰 지원은 MVC 디자인 패턴의 특징 중 하나로, 이는 한 모델에 여러 개의 뷰를 연결할 수 있음을 의미합니다. 즉, 동일한 데이터를 다른 방식으로 표시할 수 있다는 것입니다. 이것은 사용자 인터페이스의 유연성을 높이며, 사용자에게 다양한 시각적 경험을 제공할 수 있습니다.

   예를 들어, 온라인 쇼핑 웹 사이트를 생각해봅시다. 이 사이트의 제품 데이터는 모델에 저장되어 있을 것입니다. 하지만 이 데이터는 여러 다른 뷰를 통해 표현될 수 있습니다.

   • 리스트 뷰: 제품들이 한 줄로 나열된 형태로 보여집니다. 각 제품에 대한 간단한 정보만 표시될 수 있습니다.
   • 그리드 뷰: 제품들이 격자 형태로 표시됩니다. 이 뷰는 이미지 중심으로, 각 제품에 대한 자세한 정보를 보여줄 수 있습니다.
   • 상세 뷰: 한 제품에 대한 모든 정보를 표시하는 뷰입니다. 제품 사진, 가격, 상세 설명, 리뷰 등을 볼 수 있습니다.

   이 모든 뷰는 동일한 제품 데이터 (모델)를 사용하지만, 사용자에게 보여지는 방식 (뷰)는 다릅니다. 사용자는 원하는 뷰를 선택하여 제품 데이터를 탐색할 수 있습니다.

   이와 같이, MVC 패턴의 다중 뷰 지원은 동일한 데이터를 다양하게 표현할 수 있어 사용자 경험을 향상시키는데 중요한 역할을 합니다.

이런 장점들로 인해, MVC는 웹 애플리케이션, 모바일 애플리케이션, 그리고 데스크톱 애플리케이션 개발 등 다양한 영역에서 널리 사용되는 디자인 패턴입니다. 하지만 모든 상황에서 MVC가 가장 적합한 선택이라는 것은 아닙니다. 예를 들어, 매우 간단한 소프트웨어나 크고 복잡한 시스템에는 MVC 패턴이 적합하지 않을 수 있습니다. 따라서 개발자는 프로젝트의 요구 사항과 복잡성을 고려하여 적절한 디자인 패턴을 선택해야 합니다.

* MVC 패턴에서 컨트롤러의 역할을 설명해주세요.

MVC 패턴에서 컨트롤러(Controller)는 매우 중요한 역할을 합니다. 컨트롤러는 사용자의 입력을 처리하고, 그에 따라 모델(Model)과 뷰(View)를 업데이트합니다. 다시 말해, 컨트롤러는 모델과 뷰 사이의 '다리' 역할을 하며, 이들 사이의 상호작용을 관리합니다.

사용자의 요청에 따라, 컨트롤러는 다음과 같은 작업을 수행합니다:

1. 사용자 입력 처리: 사용자의 요청을 받아 이를 적절한 형식으로 변환하거나 검증합니다.
2. 모델 업데이트: 사용자의 요청을 통해 필요한 작업을 결정하고, 이에 따라 모델을 업데이트합니다. 예를 들어, 데이터를 추가, 수정, 삭제하는 등의 작업을 수행할 수 있습니다.
3. 뷰 업데이트: 모델의 상태가 변경되면, 이를 반영하여 뷰를 업데이트합니다. 이는 사용자에게 최신 정보를 제공하기 위함입니다.

따라서, 컨트롤러는 애플리케이션의 비즈니스 로직을 처리하고, 모델과 뷰 사이의 상호작용을 조정하는 핵심적인 역할을 합니다. 이를 통해, 애플리케이션의 코드 구조가 명확해지고, 각 컴포넌트의 역할이 분명해집니다.

* MVC와 비슷한 다른 디자인 패턴을 사용해 본 경험이 있나요? 그렇다면, 그 경험에 대해 설명해주세요.

MVVM(Model-View-ViewModel)과 MVP(Model-View-Presenter)는 MVC와 비슷한 패턴으로 애플리케이션을 구조화하는 데 사용됩니다.

1. MVVM(Model-View-ViewModel): MVVM은 Microsoft에 의해 개발되었으며 주로 WPF, Silverlight, nW.js 같은 XAML 기반 애플리케이션에 사용됩니다. 또한, 최근에는 AngularJS, Vue.js와 같은 프론트엔드 프레임워크에서도 널리 적용되고 있습니다. MVVM은 View와 Model 사이에 ViewModel이라는 새로운 개념을 도입하여 View와 Model의 의존성을 더욱 낮추는 것을 목표로 합니다. ViewModel은 Model의 데이터를 View가 사용하기 적합한 형태로 변환하며, 반대로 View의 입력을 Model이 이해할 수 있는 형태로 변환합니다.
2. MVP(Model-View-Presenter): MVP 패턴은 원래 Taligent에 의해 개발되었으며 주로 Android 개발에서 인기가 있습니다. MVP는 Model, View, Presenter 세 가지 요소로 구성되며, 이 패턴에서 Presenter는 MVC의 Controller와 유사한 역할을 하지만, View와 Model 사이에 더 강력한 중재자 역할을 합니다. Presenter는 View와 Model 사이의 모든 상호작용을 관리하며, View와 Model이 직접 통신하지 않도록 합니다. 이로 인해 View와 Model 사이의 의존성이 거의 없어져 코드의 재사용성과 테스트 용이성이 향상됩니다.

* MVC 패턴을 사용하면서 겪었던 어려움은 무엇이었나요? 그리고 그 문제를 어떻게 해결했나요? 

1. 복잡성: MVC 패턴을 적용하면 프로그램의 전체 구조가 복잡해질 수 있습니다. 각 컴포넌트(Model, View, Controller)를 정확하게 분리하려고 하면 코드의 양이 증가하고, 개발과 디버깅 과정이 복잡해질 수 있습니다. 이러한 문제를 해결하기 위해, 각 컴포넌트의 역할과 책임을 명확히 정의하고, 팀 내에서 이에 대한 공통된 이해를 공유하는 것이 중요합니다.
2. 테스트의 어려움: Controller는 사용자 입력과 모델의 상태 변화를 중재하는 역할을 하기 때문에, 복잡한 애플리케이션에서 Controller의 코드가 매우 복잡해질 수 있습니다. 이로 인해 Controller의 테스트가 어려워질 수 있습니다. 이 문제는 단위 테스트와 모의 객체(Mocking)를 사용하여 해결할 수 있습니다.

오버라이드(Override)와 오버로드(Overload)는 프로그래밍에서 주로 사용되는 개념으로,  클래스 내에서 메서드의 이름을 재사용하면서도 다양한 기능을 제공할 수 있게 해주는 중요한 객체지향 프로그래밍의 특징입니다.

1. 오버라이딩(Override) : 오버라이딩은 상속 관계에 있는 두 클래스 사이에서 발생합니다. 부모 클래스에서 정의한 메서드가 자식 클래스에서 다시 정의되는 경우를 오버라이딩이라고 합니다. 이 때, 메서드의 이름, 매개변수의 수와 타입, 반환 타입은 동일해야 합니다. 오버라이딩은 자식 클래스가 부모 클래스의 특정 메서드의 동작을 변경하거나 확장하려 할 때 사용됩니다.

예를 들어, "Animal" 클래스에 "move"라는 메서드가 정의되어 있고, "Bird" 클래스(Animal 클래스를 상속받는)에서 "move" 메서드를 다시 정의하여 "fly"라는 행동을 하도록 할 수 있습니다.

class Animal {
    void move() {
        System.out.println("Animals can move");
    }
}

class Dog extends Animal {
    @Override
    void move() {
        System.out.println("Dogs can walk and run");
    }
}

public class Main {
    public static void main(String args[]) {
        Animal a = new Animal(); // Animal reference and object
        Animal b = new Dog(); // Animal reference but Dog object

        a.move(); // runs the method in Animal class
        b.move(); // runs the method in Dog class
    }
}

2. 오버로딩(Overload) : 오버로딩은 같은 클래스 내에서 발생합니다. 같은 이름의 메서드를 여러 개 정의하되, 매개변수의 수나 타입, 또는 둘 다를 변경하여 같은 이름의 메서드를 여러 번 정의하는 것을 오버로딩이라고 합니다. 반환 타입만 다른 경우는 오버로딩이라고 할 수 없습니다.

예를 들어, "add"라는 메서드가 있을 때, 하나는 두 개의 int 타입 매개변수를 받아 그 합을 반환하는 "add(int a, int b)" 메서드, 다른 하나는 두 개의 double 타입 매개변수를 받아 그 합을 반환하는 "add(double a, double b)" 메서드를 정의할 수 있습니다. 이런 식으로 동일한 이름의 메서드가 다른 매개변수를 받는 경우를 오버로딩이라고 합니다.

class DisplayOverloading {
    void disp(char c) {
        System.out.println(c);
    }

    void disp(char c, int num) {
        System.out.println(c + " " + num);
    }
}

public class Main {
    public static void main(String args[]) {
        DisplayOverloading obj = new DisplayOverloading();
        obj.disp('a');
        obj.disp('a', 10);
    }
}

오버로딩(Overload)은 메소드의 이름은 같고 매개변수의 개수나 타입이 다른 함수를 정의하는 것을 의미하며 여러개의 서브프로그램 생성을 가능하게 합니다. 오버라이딩(Overriding)은 상위 클래스의 메소드를 하위 클래스가 재정의 하는 것을 의미하며 메소드 이름의 절약과 예상을 가능하게 합니다. 두 기능으로 JAVA에서 다형성을 구현하고, SOLID - OCP, LSP 원칙을 지킬 수 있습니다.

Override와 Overload는 메소드(기능)의 재정의 또는 확장을 위한 개념입니다. Override는 부모 클래스의 상속을 받은 자식 클래스에서 확장하는 개념입니다. 메소드의 이름이 일치해야 하고 매개변수의 개수, 순서, 데이터의 타입이 일치해야 하며 return 타입이 일치해야 합니다. 그리고 Overload는 같은 클래스 내부에서 확장하는 개념입니다. 메소드의 이름이 일치해야 한다는 점은 Override와 같지만 Overload는 매개변수의 개수 또는 타입이 달라야 하며 return 타입도 달라야 합니다. 따라서 이 둘은 공통적으로 메소드(기능)의 재정의 또는 확장을 위한 개념입니다. Override는 메소드 하나로 여러 객체를 다루고 객체마다 다른 기능을 사용할 수 있다는 점이 다릅니다.

* Override와 Overload :

객체 지향 프로그래밍(Object-Oriented Programming, OOP)의 핵심적인 특징인 다형성(Polymorphism)을 구현하는데 사용됩니다. 이 두 개념은 서로 다른 목적과 사용 방식을 가지고 있습니다.

1. Override:
   Override는 상속 관계에 있는 상위 클래스(base class)의 메소드를 하위 클래스(derived class)에서 재정의하는 것입니다. 이를 통해 상위 클래스의 동작을 하위 클래스가 자신의 필요에 맞게 변경하거나 확장할 수 있습니다. 이를 통해 코드 재사용성을 높이고 코드의 유지 보수를 쉽게 합니다.
   예를 들어, Animal 클래스가 sound() 메소드를 가지고 있고 이를 Dog 클래스와 Cat 클래스가 상속받는다고 가정해 봅시다. Dog 클래스는 sound()를 "Bark"로, Cat 클래스는 "Meow"로 Override할 수 있습니다. 이렇게 하면 같은 sound() 메소드를 호출하더라도 각 동물의 특성에 따른 다른 결과를 얻을 수 있습니다.
2. Overload:
   Overload는 같은 클래스 내에서 같은 이름의 메소드를 여러 개 가지되, 매개변수의 타입이나 개수가 다른 것을 의미합니다. 이를 통해 같은 기능을 하는 메소드에 대해 서로 다른 타입의 매개변수를 받을 수 있습니다. 즉, Overload는 메소드의 사용자가 같은 동작을 수행하도록 하는 동시에 다양한 입력을 제공할 수 있도록 합니다.
   예를 들어, 두 개의 숫자를 더하는 add() 메소드를 가진 클래스가 있다고 가정해 봅시다. 이 메소드를 Overload하여 정수 두 개를 더하는 메소드와 실수 두 개를 더하는 메소드를 만들 수 있습니다. 이런 방식으로 Overload를 사용하면 코드의 가독성을 향상시키고 사용의 편리성을 높일 수 있습니다.

이렇게 보면, Override와 Overload는 코드의 재사용성을 높이고, 유지 보수를 용이하게 하며, 사용자에게 일관된 사용성을 제공하는데 매우 중요한 도구라는 것을 알 수 있습니다.

* Method Overriding(오버라이딩) 을 사용할 때 주의해야 할 점은 무엇인가요?

1. 같은 메소드 시그니처: 오버라이딩 메소드는 원본 메소드와 동일한 메소드 시그니처를 가져야 합니다. 이는 메소드 이름과 매개변수의 순서, 타입, 개수가 동일함을 의미합니다.
2. 접근 제어자: 오버라이딩 메소드의 접근 제어자는 원본 메소드보다 더 좁은 범위를 가질 수 없습니다. 예를 들어, protected 메소드를 private으로 오버라이드 할 수 없습니다. 하지만, 반대로 더 넓은 범위로 변경하는 것은 가능합니다.
3. 반환 타입: Java 5 이후부터는 공변 반환 타입(covariant return type)을 지원합니다. 이는 오버라이딩 메소드가 원본 메소드와 동일한 타입 또는 그 하위 타입을 반환하도록 허용한다는 것을 의미합니다.
4. 예외: 오버라이딩 메소드는 원본 메소드에서 선언된 예외와 동일하거나 그 하위 클래스의 예외만을 던질 수 있습니다. 즉, 새로운 예외를 추가하거나, 상위 클래스의 예외를 던질 수 없습니다.
5. @Override 어노테이션 사용: @Override 어노테이션은 오버라이딩 메소드에 대한 컴파일러의 검사를 요청하는 역할을 합니다. 만약 메소드가 정확하게 오버라이드되지 않았다면 컴파일 에러를 발생시킵니다.
6. final, static, private 메소드 오버라이딩 불가: final 메소드는 변경될 수 없으므로 오버라이딩할 수 없습니다. static 메소드는 클래스 수준에서 작동하므로 오버라이딩할 수 없습니다. private 메소드는 해당 클래스에서만 접근 가능하므로 오버라이딩할 수 없습니다.

* Method Overloading(오버로딩) 이 프로그래밍에 어떤 이점을 가져다주나요?

메소드 오버로딩 (Method Overloading)은 여러 가지 방식으로 동일한 메소드 이름을 사용하는 객체 지향 프로그래밍의 기능이며, 다음과 같은 주요 이점들이 있습니다:

1. 코드의 재사용성 증가: 메소드 오버로딩을 사용하면 동일한 기능을 수행하지만 매개변수 유형이나 개수가 다른 경우, 동일한 이름의 메소드를 여러 번 정의하여 코드의 재사용성을 향상시킬 수 있습니다.
2. 코드의 가독성 개선: 모든 메소드가 동일한 이름을 가지므로 코드의 가독성이 향상됩니다. 프로그래머는 동일한 기능을 가진 메소드를 다양한 매개변수를 사용하여 호출할 수 있으므로 코드 이해가 더 쉬워집니다.
3. 컴파일 시간 다형성 제공: 메소드 오버로딩은 컴파일 시간 다형성 또는 정적 다형성을 제공합니다. 이는 매개변수의 유형에 따라 컴파일러가 알맞은 메소드를 결정하고 호출하게 됩니다.
4. 메소드의 유연성 증가: 메소드 오버로딩을 사용하면 메소드의 유연성이 증가합니다. 같은 메소드를 다양한 타입과 개수의 매개변수로 호출할 수 있습니다.

예를 들어, add()라는 메소드가 있다고 할 때, 정수 두 개를 더하는 함수와 실수 두 개를 더하는 함수 모두 add라는 이름을 가질 수 있으며, 이렇게 하면 코드의 가독성과 유연성이 증가하게 됩니다.

* Method Overloading과 Constructor Overloading의 차이점에 대해 설명해주세요.

메소드 오버로딩(Method Overloading)과 생성자 오버로딩(Constructor Overloading) 모두 Java에서 다형성(polymorphism)의 형태를 제공하며, 둘 다 이름이 같은 두 개 이상의 메소드나 생성자를 동일한 클래스 내에 정의할 수 있게 합니다. 그러나 두 오버로딩 간에는 몇 가지 중요한 차이점이 있습니다:

1. 이름: 메소드 오버로딩에서는 메소드가 클래스에 정의된 대로 이름을 가집니다. 그러나 생성자 오버로딩에서 생성자는 항상 클래스 이름과 동일해야 합니다. 따라서, 생성자의 이름은 클래스 이름에 의해 결정되며 변경할 수 없습니다.
2. 리턴 타입: 메소드 오버로딩에서 메소드는 명시적인 반환 타입을 가질 수 있습니다. 즉, 메소드는 값을 반환할 수 있습니다. 그러나 생성자는 값을 반환할 수 없으며, 반환 타입을 가질 수 없습니다. 생성자의 주요 목적은 새 객체를 초기화하는 것입니다.
3. 호출 시점: 메소드는 명시적으로 호출되며 필요한 매개변수를 제공해야 합니다. 반면에, 생성자는 new 키워드를 사용하여 객체가 생성될 때 자동으로 호출됩니다

public class MyClass {
    // Method Overloading
    void myMethod(int x) {
        // code here
    }

    void myMethod(String str) {
        // code here
    }

    // Constructor Overloading
    MyClass(int x) {
        // code here
    }

    MyClass(String str) {
        // code here
    }
}

위의 코드에서 메소드 오버로딩과 생성자 오버로딩을 모두 보여줍니다. myMethod는 메소드 오버로딩의 예로, 한 개의 정수 또는 문자열을 인수로 받습니다. 반면에 MyClass 생성자는 생성자 오버로딩의 예로, 객체 생성 시점에 자동으로 호출됩니다.

* 다형성을 구현하는 다른 방법에는 어떤 것들이 있나요? 이것들과 Method Overloading/Overriding은 어떻게 다른가요?

다형성(Polymorphism)은 객체 지향 프로그래밍의 핵심 원칙 중 하나로, 동일한 인터페이스를 통해 다양한 형태로 동작하도록 하거나 다른 유형의 객체들을 동일하게 처리하는 기능을 제공합니다. Java에서 다형성을 구현하는 주요 방법들은 다음과 같습니다:

1. 상속 (Inheritance): 부모 클래스의 특성과 기능을 자식 클래스가 상속받는 기능입니다. 부모 클래스를 기반으로 다양한 자식 클래스를 생성할 수 있어, 상속을 통해 다형성을 구현할 수 있습니다.
2. 인터페이스 (Interfaces): 인터페이스는 메소드 선언을 모아 둔 추상 타입으로, 클래스가 인터페이스를 구현하면 그 클래스는 인터페이스가 정의하는 모든 메소드를 구현해야 합니다. 서로 다른 클래스가 같은 인터페이스를 구현할 수 있어, 이를 통해 다형성을 구현할 수 있습니다.
3. Method Overloading and Overriding: 앞서 설명한 바와 같이, 메소드 오버로딩은 같은 이름을 가진 여러 메소드를 매개변수의 유형이나 개수를 바꿔서 정의하는 것이고, 메소드 오버라이딩은 상위 클래스의 메소드를 하위 클래스에서 재정의하는 것입니다. 이들은 같은 이름의 메소드를 사용하면서도 다른 동작을 수행하도록 하는 방식으로 다형성을 구현합니다.

위의 모든 방법들은 다형성을 지원하지만, 그 방식이나 목적은 약간씩 다릅니다. 상속과 인터페이스는 다형성을 클래스 레벨에서 지원하면서, 여러 클래스가 동일한 메소드를 공유하거나 동일한 인터페이스를 따르도록 하는 데 초점을 맞추고 있습니다. 이와 달리 메소드 오버로딩과 오버라이딩은 단일 클래스 내에서 다형성을 지원하면서, 메소드가 다양한 방식으로 동작하도록 하는 데 초점을 맞추고 있습니다.

https://vmpo.tistory.com/29

1. 자바에서는 기본 타입(primitive type)과 참조 타입(reference type)이 있는데 기본 타입의 경우 값 자체가 전달되는 call by value이고, 참조 타입의 경우 참조값(즉, 주소)이 전달되는 것이기 때문에 call by reference처럼 보일 수 있습니다.
2. 하지만, 정확히 말하면 자바에서는 모든 것이 call by value입니다. 왜냐하면 메소드에 객체를 전달할 때 객체의 주소를 전달하는 것이 아니라 참조값(즉, 주소를 가리키는 값)을 복사해서 전달하기 때문입니다. 이 복사된 참조값을 통해 객체의 필드를 변경할 수 있지만, 복사된 참조값 자체를 변경하더라도 원본 참조값에는 영향을 미치지 않습니다.
3. 예를 들어, 메소드 내에서 전달 받은 객체를 다른 객체로 바꾸려고 해도 원본 객체는 변하지 않습니다. 이는 참조값이 복사되어 전달되기 때문입니다. 이러한 이유로 자바의 객체 전달 방식은 '참조에 의한 값 전달(call by value of reference)'라고도 설명합니다.
4. 따라서, 객체의 상태를 바꾸는 것은 가능하지만(예: 메소드 내에서 객체의 필드 값을 변경), 객체 자체를 바꾸는 것은 불가능하다(예: 메소드 내에서 새로운 객체를 할당)는 것이 자바에서의 call by value와 call by reference의 차이점입니다.

** Call by reference는 여러가지 상황에서 유용하게 사용될 수 있습니다.

1. 객체의 상태 변경: 함수 내에서 객체의 상태를 변경하려는 경우에 "call by reference"를 사용할 수 있습니다. 예를 들어, 어떤 객체를 메서드에 전달하고, 그 메서드가 객체의 필드를 수정하면 원본 객체도 바뀌게 됩니다. 이는 원본 객체의 상태를 직접 바꿀 수 있다는 장점이 있습니다.
2. 대용량 데이터 처리: 큰 데이터 구조를 다룰 때 "call by reference"를 사용하면, 데이터를 복사하는 데 소요되는 시간과 메모리를 절약할 수 있습니다. 실제 데이터 대신 참조(주소)만 전달하면 되기 때문에, 메모리 사용량을 크게 줄일 수 있습니다.
3. 객체 간의 상호작용: 여러 객체가 서로 상호작용하는 시스템에서 "call by reference"를 사용하면, 한 객체가 다른 객체의 상태를 바꾸는 것이 가능해집니다. 예를 들어, 게임에서 플레이어 객체가 아이템 객체를 사용해서 상태를 변경하는 경우 등에 사용할 수 있습니다.

이러한 방식은 프로그램의 구조를 설계할 때 중요한 요소가 될 수 있으며, 상황에 따라 적절하게 사용해야 합니다. 즉, 객체의 상태를 바꾸는 것이 필요하거나, 메모리를 절약하려는 경우 등에 "call by reference"를 사용합니다. 그러나 항상 주의해야 할 점은, "call by reference"를 사용하면 원본 객체의 상태를 바꾸게 되므로, 이것이 예상치 못한 부작용을 초래하지 않도록 주의해야 합니다.

** 부작용의 예

1. 데이터의 무결성 손실: 원본 데이터를 변경하면, 그 데이터가 정확하게 유지되어야 하는 경우 문제가 발생할 수 있습니다. 예를 들어, 객체의 필드가 특정 조건을 만족해야 하는데, 그 필드를 변경하는 메서드를 통해 그 조건을 위반하게 될 수 있습니다.
2. 동시성 문제: 멀티스레드 환경에서 같은 객체를 여러 스레드가 동시에 접근하여 변경하려고 하면, 경쟁 조건(race condition)이 발생할 수 있습니다. 이는 데이터의 일관성을 손상시키고 예기치 못한 결과를 초래할 수 있습니다.
3. 코드의 가독성과 유지보수: 원본 데이터가 변경되면, 코드의 흐름을 따라가기 어려워지고 디버깅이 더 어려워질 수 있습니다. 함수나 메서드는 보통 입력을 받아 출력을 내는 것이 명확하고 예측 가능하지만, 원본 객체를 변경하면 그 함수의 출력이 어떻게 될지 예측하기 어려워집니다.

이러한 이유로, 가능한 한 "Call by value"를 사용하여 원본 데이터를 보호하거나, "Call by reference"를 사용할 때는 함수 내에서 원본 데이터를 변경하지 않는 것이 좋습니다. 또는 데이터 변경을 명시적으로 나타내는 설계 패턴을 사용할 수도 있습니다.

** 데이터 변경을 명시적으로 나타내는 설계 패턴

1. 데이터 변경을 명시적으로 나타내는 설계 패턴이란, 코드의 특정 부분이 데이터를 변경할 것임을 분명히 명시하는 프로그래밍 방식을 의미합니다. 이는 코드의 가독성을 높이고, 부작용을 최소화하는 데 도움이 됩니다.
2. 예를 들어, 함수 또는 메소드 이름을 선택할 때 "set", "update", "change" 등의 동사를 사용하여 해당 함수/메소드가 데이터를 변경할 것임을 분명히 표시할 수 있습니다. 이런 네이밍 컨벤션은 데이터 변경이 이루어질 것임을 명확하게 나타내어, 다른 개발자들이 코드를 이해하고 예측하는데 도움이 됩니다.

함수의 호출 방식 중 하나로, 참조에 의한 호출 방식입니다. 함수를 호출할 때 인자로 reference(값에 대한 참조 주소, 메모리상의 주소를 담고 있는 변수)를 전달하며 참조 타입(reference type)을 전달합니다. reference를 전달했기 때문에 인자는 일반적으로 전역 변수의 특성을 갖습니다. 그러나 참조 타입의 변수를 함수 내에서 재할당 하게 되면 원본 값이 변경된다는 위험이 있습니다. 이러한 점을 방지 하기 위해서는 reference로 다른 값을 전달하여 사용합니다. 값이 같은 다른 참조값을 만들어 사용하는 것입니다.

Call by value란, 값을 호출하는 것을 의미하고, Call by reference란 참조에 의한 호출을 의미합니다. 전달받은 값을 직접 참조하므로 값을 변경할 경우 원본도 같이 변경이 됩니다. JVM에선 힙 영역에 Object 타입의 데이터, 스택 영역에서는 그 데이터의 참조 값이 할당됩니다. 그렇기에 객체의 주소를 참조해 데이터를 수정한다고 해도 원본에는 변경이 없으므로 JAVA에서의 모든 전달 방식은 Call by value입니다.

 JAVA에서는 Call by value만 사용되어지며 메서드에서 특정 값을 참조할 때 Heap영역에 새로운 값을 임시로 복사하여 스택의 주소값이 가리키는 값이 원본이 아닌 복제된 값을 가리키도록 한다.

Java에서는 원시타입/기본타입(정수, 부동소수점 등)은 값 자체가 함수에 전달되고 객체는 참조(메모리 주소)가 전달되지만, 이 참조 자체는 값으로 전달됩니다. 그래서 함수 내에서 이 참조를 변경해도 원본 참조에는 영향을 미치지 않습니다. 따라서 Java의 모든 전달 방식을 "call by value"라고 할 수 있습니다.

06. 문자열 출력하기 

스캐너의 개념을 잘 몰라서 그랬을까... 처음에 봤을때는 어...뭐지...!? 했다.. 

       while(sc.hasNext()) {
            System.out.print(sc.next());
        }

이번에도 While 을 쓰신 분이 있네... 신기해라 

Scanner의 개념은 Scanner 객체를 생성하고 next(); 또는 nextLine(); 메서드를 호출하여 입력한 내용을 문자열로 반환하는 것이다 

이때 , Scannerclassdpsms nextInt() 나 nextFlat() 와 같이 변환이 필요없거나 Integer.parseInt() 와같이 정수변환을 해주는 매서드도 있다 (p61)

07. 문자열 출력하기 

System.out.println("a = "+a +"\n" +"b = "+b);

이렇게 "\n"을 사용하게 되면 자동으로 줄바꿈을 해주는 것 .... 

08. 문자열 반복해서 출력하기 

for문을 돌린다,,, 

   System.out.println(str.repeat(n));

역시...이런 반복출력 함수가 있었구나... 입력....

09. 대소문자 바꿔서 출력하기 ⭐️

대소문자 변환 toUpperCase(), toLowerCase() 이고 현재 문자열을 하나씩 쪼개는 방법으로는 charAt() 또는 toCharArray() 

Character는 자바에서 제공하는 기본 클래스로, char 데이터 타입을 객체로 표현할 수 있게 해줍니다. 이 클래스는 char 값을 포장하는 데 사용되며, 여러가지 문자 관련 메소드를 제공합니다.

• Character.isLetter(char ch): 주어진 char 값이 문자인지 아닌지를 판단합니다.
• Character.isDigit(char ch): 주어진 char 값이 숫자인지 아닌지를 판단합니다.
• Character.isUpperCase(char ch): 주어진 char 값이 대문자인지 아닌지를 판단합니다.
• Character.isLowerCase(char ch): 주어진 char 값이 소문자인지 아닌지를 판단합니다.
• Character.toLowerCase(char ch): 주어진 char 값을 소문자로 변환합니다.
• Character.toUpperCase(char ch): 주어진 char 값을 대문자로 변환합니다.

        for(int i=0; i<a.length(); i++) {
            char c = a.charAt(i);
            if(Character.isUpperCase(c)) {
                System.out.print((char)(c+32));
            }
            else {
                System.out.print((char)(c-32));
            }
        }

       String answer = "";

        for(int x : a.toCharArray()){
        if(x>=97 && x<=122)answer += (char)(x-32); else answer += (char)(x+32);


}
        System.out.print(answer);

원래는 이렇게 아스키코드를 사용하는 방법도 생각해봤었는데 그냥 toUpperCase(), toLowerCase() 를 사용했다. 

    StringBuffer sb = new StringBuffer();
        for (char ch : a.toCharArray()) {
            if ('a' <= ch && ch <= 'z')
                sb.append((char)(ch - ('a' - 'A')));
            else 
                sb.append((char)(ch + ('a' - 'A')));
        }
        System.out.println(sb.toString());

아직도 buffer를 배우지 못했지만 ... 

StringBuffer는 문자열을 다루는 데 사용되는 클래스로 문자열을 변경할 때 자주 사용되며, StringBuilder와 함께 변경 가능한(mutable) 문자열을 제공

sb.append((char)(ch - ('a' - 'A')));: ch가 소문자일 경우 대문자로 변환. ASCII 표에서 대문자와 소문자의 차이는 32 ('a' - 'A' = 32)입니다. 따라서 소문자 'a'에서 32를 빼면 대문자 'A'를 얻을 수 있습니다. 이 원리를 이용해 소문자를 대문자로 바꿉니다.

System.out.println(sb.toString());: 마지막으로 sb에 저장된 문자열을 출력. sb는 StringBuffer 객체이므로, toString() 메소드를 이용해 문자열로 변환

1. IoC(Inversion of Control) :  "제어의 역전"이라는 의미로, 전통적인 프로그래밍에서 객체가 자신의 로직을 제어하는 구조에서 벗어나, 제어의 흐름을 외부(프레임워크나 컨테이너 등)에 위임하는 디자인 원칙입니다. 이를 통해 객체 간의 결합도를 줄이고, 모듈 간의 독립성을 높이는데 목적이 있습니다. IoC는 프레임워크가 코드의 흐름을 담당하고 개발자는 그 안에서 필요한 코드를 제공하는 방식으로 작동합니다.Spring 같은 경우 프레임워크가 만들어 놓은 객체를 주입, IoC 컨테이너에서 Bean으로 등록된 객체를 관리합니다.

1. DI(Dependency Injection) : DI는 IoC의 한 형태로, "의존성 주입"이라고 합니다. 객체가 서로 의존하는 상황에서, 이 의존성(객체가 필요로 하는 다른 객체)을 직접 생성/관리하는 것이 아니라 외부(컨테이너나 프레임워크 등)에서 주입하는 방식을 말합니다. 이를 통해 객체 간의 결합을 느슨하게 만들어 유지보수성과 재사용성을 향상시킬 수 있습니다.의존성을 주입하는 방법에는 생성자 주입, Setter 주입, 필드 주입 등이 있는데 Spring에서는 생성자 주입을 권장, 생성자 주입은 생성자의 호출 시점에 1회 호출 되는 것이 보장되기 때문에 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우 강제로 주입하기 위해 사용할 수 있다는 장점이 있습니다.
   객체가 생성될 때 생성자가 호출되며, 그 시점에 의존성이 주입
   -> 객체가 생성되는 시점에 필요한 모든 의존성이 주입되어야 함을 보장하며, 이후에 변경될 수 없다는 특징
   따라서, 생성자 주입은 "반드시 객체의 주입이 필요한 경우"에 주로 사용됩니다. 생성자에서 필요한 의존성을 선언하면, 해당 객체를 생성하려면 반드시 해당 의존성을 제공해야 합니다. 이렇게 하면 필요한 의존성이 없는 상태로 객체가 생성되는 것을 방지할 수 있습니다
   

** 예시

1. 자동차(Car) 객체가 엔진(Engine) 객체에 의존하는 상황에, Car 객체 내부에서 Engine 객체를 직접 생성하면 Car와 Engine은 강하게 결합되어 있게 됩니다. 이런 상황에서 Engine의 변화가 Car에도 영향을 미치게 되어 유지보수가 어려워집니다. 반면, DI를 사용하면 Engine 객체는 외부에서 Car 객체에 주입되므로, Car는 Engine의 생성 및 생명 주기에 대해 신경 쓸 필요가 없게 되며 이는 두 객체의 결합도를 낮춥니다.
2. UserService 클래스가 UserRepository 인터페이스를 사용해 DB에서 사용자를 조회하는 상황을 생각해봅시다. UserService 클래스에서 UserRepository의 구현체를 직접 생성하게 되면, UserService는 UserRepository의 특정 구현체에 의존하게 됩니다. 그러나 DI를 사용하면, UserService는 UserRepository 인터페이스에만 의존하게 되고, 실제 사용할 구현체는 프레임워크가 런타임에 주입해줍니다. 이런 식으로 DI를 통해 클래스 간의 의존성을 낮출 수 있고, 코드의 유연성과 재사용성을 높일 수 있습니다.
3. 이와 같은 방식은 특히나 유닛 테스트에서 유용하게 사용됩니다. 의존성 주입을 통해 테스트 환경에서는 실제 객체 대신 모의 객체(mock object)를 쉽게 주입할 수 있기 때문입니다.
4. Java의 Spring 프레임워크와 같은 모던 프레임워크들은 이런 IoC와 DI 원칙을 광범위하게 적용하고 있습니다. 이를 통해 개발자는 더욱 모듈화된 코드를 작성하고, 더 쉽게 유닛 테스트를 실행할 수 있습니다.

IoC는 의존할 메소드나 객체의 호출을 개발자가 결정하는 것이 아닌 프레임워크에서 결정하는 것으로 “제어의 역전”라는 의미를 갖습니다. 기존에는 클래스 내부에서 의존할 객체를 직접 생성하고 객체 메소드를 호출 했다면 Spring 같은 프레임워크에서는 제어권을 프레임워크에 위임하여 프레임워크가 만들어 놓은 객체를 주입합니다. Spring 같은 경우 IoC 컨테이너에서 Bean으로 등록된 객체를 관리합니다.

DI는 IoC(제어의 역전)의 개념을 구현하기 위한 디자인 패턴이자 객체 의존관계를 외부에서 주입 시키는 방법입니다. 의존성을 주입하는 방법에는 생성자 주입, Setter 주입, 필드 주입 등이 있는데 Spring에서는 생성자 주입을 권장하고 있습니다. 생성자 주입은 생성자의 호출 시점에 1회 호출 되는 것이 보장되기 때문에 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우 강제로 주입하기 위해 사용할 수 있다는 장점이 있습니다.

DI(Dependency Injection)란 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능으로, 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식이다. DI(의존성 주입)를 통해서 모듈 간의 결합도가 낮아지고 유연성이 높아진다. IoC(Inversion of Control)란 "제어의 역전" 이라는 의미로, 말 그대로 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부에서 결정되는 것을 의미한다. IoC는 제어의 역전이라고 말하며, 간단히 말해 "제어의 흐름을 바꾼다"라고 한다. 객체의 의존성을 역전시켜 객체 간의 결합도를 줄이고 유연한 코드를 작성할 수 있게 하여 가독성 및 코드 중복, 유지 보수를 편하게 할 수 있게 한다.

제어의 역전 (IoC: Inversion of Control)은 프로그램의 제어 흐름 구조가 뒤바뀌는 것을 의미합니다.

• 일반적으로 개발자가 필요한 객체를 생성하여 사용하는 것이 일반적이지만, IoC에서는 이를 뒤집어, 용도에 맞는 객체를 시스템이 제공하고 개발자는 그냥 사용합니다. 이를 "의존성 주입(Dependency Injection, DI)"이라고 부릅니다.
• 실생활 예제로, 가위를 사용하는 경우를 들 수 있습니다. 가위를 직접 만드는 것이 아니라, 가위를 사용하는 용도에 따라 다양한 가위를 사용하는 것과 같습니다.

스프링 프레임워크와 IoC/DI:

• 스프링 프레임워크는 DI를 지원하여, 개발자가 직접 객체를 생성하지 않고 필요한 객체를 스프링 프레임워크가 제공합니다.
• 스프링에서 관리하는 이러한 객체를 '빈(Bean)'이라고 부르며, '빈'들은 스프링 IoC 컨테이너에 의해 관리됩니다.

스프링 '빈' 등록과 사용: 

• '빈'의 등록은 @Component 어노테이션을 클래스 위에 붙여서 수행하며, 이 클래스는 스프링 서버가 시작될 때 스프링 IoC 컨테이너에 저장됩니다.
• '빈'의 이름은 클래스의 이름을 사용하되, 첫 글자를 소문자로 변경합니다.
• '빈'을 사용하기 위해선, @Autowired 어노테이션을 사용하여 스프링 IoC 컨테이너에 의존성 주입을 요청합니다.
• @Autowired는 멤버변수 선언 위에 또는 '빈'을 사용할 함수 위에 붙일 수 있습니다.
• 이 어노테이션은 스프링 IoC 컨테이너에 의해 관리되는 클래스에서만 사용 가능합니다.
• 특정 조건에서는 @Autowired 어노테이션을 생략할 수 있습니다.

추가적인 주요 개념:

• @ComponentScan: 스프링이 자동으로 빈을 등록할 클래스를 찾을 위치를 지정합니다.
• @Bean: 직접 객체를 생성하여 빈으로 등록하는데 사용됩니다.
• ApplicationContext: 스프링 IoC 컨테이너의 인터페이스로, 스프링 컨테이너의 기본적인 기능을 제공합니다. 빈을 찾거나 빈에 접근하는 등의 역할을 합니다.
• @RequiredArgsConstructor: Lombok 라이브러리에서 제공하는 어노테이션으로, final로 선언된 모든 필드에 대한 생성자를 자동으로 생성합니다. 이는 DI를 위해 사용될 수 있습니다.

따라서 스프링에서는 IoC와 DI를 통해 개발자가 직접 객체를 생성하고 관리하는 부담을 덜고, 개발자는 비즈니스 로직에 집중할 수 있게 합니다. 이를 통해 코드의 가독성과 유지보수성이 향상됩니다.

2023.05.23 - [Mockterview] - DI와 IoC pt.2

스택(Stack)과 큐(Queue)는 컴퓨터 과학에서 중요한 개념으로, 각각의 자료구조는 데이터를 관리하고 처리하는 방식에 따라 차이점이 있습니다.

1. 스택(Stack): 스택은 가장 나중에 들어온 요소가 가장 먼저 나가는, 즉 LIFO(Last In First Out,후입선출) 구조로 작동하는 자료구조입니다. 스택은 용량이 정해져 있으며, 스택이 가득 차면 더 이상 요소를 추가할 수 없습니다. 주요 연산에는 push(스택에 요소를 추가), pop(스택의 가장 위에 있는 요소를 제거하고 그 요소를 반환), peek(스택의 가장 위에 있는 요소를 확인하는데 이때 요소가 제거되지는 않음)가 있습니다. 스택은 함수 호출, 문법 체크, 후위 표기법 계산 등에 활용됩니다.
2. 큐(Queue): 큐는 가장 먼저 들어온 요소가 가장 먼저 나가는, 즉 FIFO(First In First Out,선입선출) 구조로 작동하는 자료구조입니다. 주요 연산에는 enqueue(큐의 끝에 요소를 추가), dequeue(큐의 앞에서 요소를 제거하고 그 요소를 반환), peek/front(큐의 앞에 있는 요소를 확인하는데 이때 요소가 제거되지는 않음)가 있습니다. 큐는 운영 체제의 태스크 스케줄링, 너비 우선 탐색(Breadth First Search) 등에 활용됩니다.

즉 스택과 큐는 데이터를 추가하고 제거하는 순서에 따라 구분됩니다. 스택은 가장 나중에 추가된 데이터를 가장 먼저 처리하고, 큐는 가장 먼저 추가된 데이터를 가장 먼저 처리합니다. 

**예시

1. 스택(Stack): 스택은 책더미에 비유할 수 있습니다. 책을 쌓을 때는 위에서부터 쌓게 되고, 책을 꺼낼 때는 위에 있는 책부터 꺼내게 됩니다. 이처럼 가장 마지막에 들어온 것이 가장 먼저 나가는 구조를 스택이라고 합니다. 이것을 전문용어로는 LIFO(Last In First Out, 후입선출)라고 합니다.
2. 큐(Queue): 큐는 사람들이 줄을 서서 기다리는 모습에 비유할 수 있습니다. 사람들이 줄을 서서 차례대로 기다리다가 차례가 되면 서비스를 받게 됩니다. 이처럼 가장 먼저 들어온 것이 가장 먼저 나가는 구조를 큐라고 합니다. 이것을 전문용어로는 FIFO(First In First Out, 선입선출)라고 합니다.

** 스택의 활용

• 함수 호출: 프로그램에서 함수를 호출할 때마다 시스템은 그 호출 정보(인자, 리턴 주소 등)를 스택에 저장합니다. 함수 호출이 끝나면 그 정보를 스택에서 빼내어(팝) 원래의 상태로 돌아갑니다. 이러한 방식으로 함수의 호출 순서와 실행 순서를 관리합니다.
• 문법 체크: 컴파일러는 괄호의 쌍이 올바른지 확인하기 위해 스택을 사용합니다. 여는 괄호가 나올 때마다 스택에 넣고(푸시), 닫는 괄호가 나올 때마다 스택에서 꺼내서(팝) 괄호의 쌍이 맞는지 확인합니다.
• 후위 표기법 계산: 후위 표기법(예: 2 3 +)은 스택을 이용해서 계산합니다. 숫자를 만나면 스택에 넣고, 연산자를 만나면 스택에서 숫자를 두 개 꺼내서 연산 후 결과를 다시 스택에 넣습니다. 이런 과정을 반복해 최종 결과를 얻습니다.

** 큐의 활용

• 운영 체제의 태스크 스케줄링: 컴퓨터에서 여러 프로그램이 동시에 실행될 때, 어떤 프로그램을 먼저 실행할지 결정하는 것이 태스크 스케줄링입니다. 이 때 큐를 사용해 먼저 요청된 작업부터 순서대로 처리합니다.
• 너비 우선 탐색(Breadth First Search): 그래프나 트리 같은 데이터 구조를 너비 우선으로 탐색할 때 큐를 사용합니다. 방문할 노드를 큐에 넣고, 방문할 때마다 큐에서 노드를 하나씩 꺼내서 이웃 노드를 다시 큐에 넣습니다. 이런 과정을 큐가 빌 때까지 반복해 모든 노드를 방문하게 됩니다.

스택은 마지막에 저장한 데이터를 가장 먼저 꺼내게 되는 LIFO 구조이며 정해진 방향으로만 데이터를 쌓을 수 있고 top을 통해서만 접근 가능합니다. 순차적으로 데이터를 추가하고 삭제하기 때문에 Arraylist 같은 배열기반의 컬렉션 클래스가 적합합니다. 웹 브라우저 방문기록, undo/redo 등이 있습니다. 웹 브라우저의 뒤로 가기 기능

큐는 가장 먼저 저장한 데이터를 가장 먼저 꺼내게 되는 FIFO 구조입니다. 한 쪽에서는 삽입 작업이, 다른 쪽에서는 삭제 작업이 이루어집니다. 배열 기반 클래스를 사용하면 데이터를 꺼낼 때마다 빈 공간을 채우기 위해 데이터의 복사가 발생하므로 큐는 데이터의 추가와 삭제가 쉬운 링크드리스트로 구현하는 것이 더 적합합니다. 캐싱, 콜센터 대기시간, 최근 사용 문서가 있습니다. 프린터의 인쇄 대기열

1. 전송 시 암호화: 사용자의 패스워드는 절대 평문(암호화되지 않은 텍스트)으로 전송되어서는 안됩니다. HTTPS와 같은 보안 프로토콜을 사용해 데이터를 암호화해서 전송해야 합니다. 이렇게 하면 중간에 데이터를 가로채도 원본 패스워드를 알아내기 어렵습니다.
2. 보관 시 해싱: 사용자의 패스워드를 데이터베이스에 저장할 때도, 평문으로 저장하면 안됩니다. 대신 해싱 함수를 사용해서 패스워드를 해시값으로 변환한 뒤, 그 해시값을 저장해야 합니다. 해시 함수는 원래 데이터를 일정한 길이의 무작위 문자열로 변환하는 함수입니다. 해시 함수의 특성 상, 해시값에서 원래 데이터를 복원하는 것은 불가능에 가깝습니다. 따라서 해시값만 봐서는 원본 패스워드를 알아내기 매우 어렵습니다.
3. 솔트 사용: 그러나 해싱만으로는 충분하지 않습니다. 같은 패스워드는 항상 같은 해시값으로 변환되므로, 악의적인 사람이 미리 많은 수의 패스워드와 그 해시값을 계산해 놓은 "레인보우 테이블"을 이용하면, 해시값을 통해 원본 패스워드를 알아낼 수 있습니다. 이를 방지하기 위해 "솔트"라는 랜덤 문자열을 패스워드에 추가한 뒤 해싱합니다. 솔트는 각 사용자마다 다르게 생성되며, 패스워드 해시값과 함께 저장됩니다. 이렇게 하면, 레인보우 테이블을 사용한 공격을 막을 수 있습니다.
4. 보안을 더 높이려면: 이런 기본적인 보안 조치 외에도, 반복적인 해싱, 키 스트레칭, 페퍼(pepper, 전체 시스템에서 공통으로 사용하는 비밀 값) 추가 등 보안을 더 높일 수 있는 방법들이 있습니다.
   

** 대표적인 암호화(해싱) 알고리즘

1. Bcrypt: 솔트와 반복적인 해싱을 사용해 보안을 강화한 알고리즘입니다. 레인보우 테이블 공격을 방어하고, 작업량을 조절해 브루트 포스 공격을 어렵게 만드는 특징이 있습니다.
2. Scrypt: Bcrypt와 비슷하지만, 메모리를 많이 사용하도록 설계된 알고리즘입니다. 이로 인해 하드웨어를 이용한 공격을 더 어렵게 만듭니다. 같은 시간에 시도할 수 있는 암호화 해석 시도 횟수가 제한되어 보안이 향상됩니다.
3. Argon2: 메모리와 CPU 시간을 많이 필요로 하도록 설계된 알고리즘으로복잡한 하드웨어 공격도 어렵게 만들 수 있습니다. 최근에는 많은 시스템에서 이 알고리즘을 사용하는 추세입니다.
4. PBKDF2 (Password-Based Key Derivation Function 2): 솔트와 반복적인 해싱을 사용하는 알고리즘입니다. 원래 암호화된 키를 생성하기 위해 설계되었지만, 패스워드 저장에도 사용됩니다. iOS에서는 이 알고리즘을 사용하여 키를 생성합니다.

**페퍼(pepper)는 "솔트"와 비슷하지만 저장되지 않는 추가적인 랜덤값입니다. 페퍼는 시스템 전체에서 같은 값이 사용되며, 해시를 계산할 때 패스워드와 솔트에 추가로 더해집니다. 페퍼를 사용하면 데이터베이스가 노출되더라도 페퍼를 모르는 공격자는 해시를 제대로 계산할 수 없습니다. 예를 들어, "1234"라는 패스워드를 해시할 때, 패스워드에 "abc"라는 솔트와 "xyz"라는 페퍼를 추가하고 이를 해시합니다. 이렇게 하면 공격자가 "1234abc"에 대한 해시를 미리 계산해놔도 "xyz" 페퍼를 모르기 때문에 실제 해시 값을 얻을 수 없습니다.

유저의 패스워드를 받은 클라이언트는 평문으로 서버로 전송합니다. 평문을 받은 서버는 패스워드를 단방향 해시 함수로 암호화하여 보관합니다. 단방향 해시함수는 수학적 연산에 의해 원본 데이터를 완전히 다른 암호화된 데이터(다이제스트)로 변환하는 것을 말합니다. 원본 데이터로는 다이제스트를 구할 수 있지만 다이제스트로는 원본데이터를 구할 수 없어야 합니다. 이것을 단방향이라 합니다. 단방향 해시함수는 브루트포스 공격으로 쉽게 당할 수 있기 때문에 이를 보완하기 위해 입력된 다이제스트를 N번 반복해서 생성하는 것인 key stretching과 원문 패스워드에 임의의 문자열을 추가하여 해싱하는 것인 salting을 이용해 보안의 강도를 높힐 수 있습니다.

클라이언트에서 패스워드를 전송하고 서버에서 해당 패스워드를 보관해야 할 때 서버에서 패스워드를 그대로 보관하지 않습니다. Bcrypt와 같은 모듈을 이용하여 패스워드를 특정 알고리즘으로 암호화하여 서버에 저장하게 됩니다. 이때 암호화는 주로 단방향 암호화로 진행합니다. 패스워드를 어떤 알고리즘으로 암호화하여 같은 암호화 결과물을 얻을 수 있지만 암호화 된 결과물을 다시 암호화 전의 패스워드로 복구가 불가능 한 것이 단방향 암호화입니다.

기본적으로 정부 지침에 따라 패스워드는 복호화할 수 없는(암호화 방식에 따라 다르지만) 랜덤한 임의의 값으로 암호화 시키지 않으면 형사적 처벌을 받을 수도 있다. 때문에 서버단에서 적절한 상황에 어울리는 인코딩 방식에 따라(Base64 또는 HS256 등등) 단방향 암호화를 적용할지, 양방향 암호화를 적용할지를 정의하고 유저로부터 POST(보안을 위해) 방식으로 비밀번호를 입력받아 암호화 하여 DB에 저장한다. DB에 암호화 되어 저장된 값을 로그인 시에 확인할 때는 동일한 알고리즘을 사용하여 로그인 시에 입력받은 값을 암호화하면 복호화 할 필요없이 DB에 있는 값과 동일한 Value를 가지게 되므로 이를 Match 하여 동일 값인지만 확인하면 본인 확인을 할 수 있다.

사용자의 패스워드를 관리하기 위해서는 Spring Security의 BCryptPasswordEncoder를 통한 BCrtpt 형식의 해시 함수로 인코딩이 필요합니다. 사용자가 패스워드를 전송하면 BCryptPasswordEncoder로 구현된 encoder() 메서드를 사용해 인코딩하게 되고, 이는 단방향 흐름으로 진행됩니다. 추가로 일치 여부 판단을 위해서 matches() 메서드를 사용합니다.

사용자의 패스워드는 단방향인 해싱, 양방향인 암호화로 전송 및 보관이 가능하다. 해싱은 복호화가 불가능하며, 암호화는 복호화가 가능하다. 따라서, 대부분의 개발자들은 단방향 해시로 안전하게 패스워드를 전송 및 보관하려고 한다. 단방향 해시 함수는 어떤 수학적 연산 및 알고리즘에 의해 원본 데이터를 완전히 다른 암호화된 데이터로 변환시키는 것이다. 이렇게 변환된 데이터를 다이제스트라고 한다. 단점으로는 동일한 메세지는 동일한 다이제스트를 갖고있어 레인보우 테이블을 통해 메세지의 원문을 찾을 수 있다. 또한 상징성 있는 문자를 추려서 조합하여 브루트포스 공격을 당할 수 있다. 단방향 해시 함수를 보완하기 위해서 해시 함수를 여러번 수행하거나 해시함수를 돌리기 전 원문에 임의의 문자열을 덧붙이는 솔트를 사용하여 보완할 수 있으며, 둘을 모두 사용할 수 있다.

2023.05.24 - [Mockterview] - 사용자 패스워드를 전송하고 보관하는 방법(일반적인 보안 방법) pt.2

Java의 특징 

1. 객체지향 프로그래밍 언어: 자바는 객체지향 프로그래밍 언어로, 상속, 캡슐화, 다형성 등의 주요 객체지향 개념을 모두 지원합니다. 이러한 특징은 코드 재사용성을 증가시키고, 복잡한 프로그램을 좀 더 쉽게 관리하도록 돕습니다.
2. 운영체제에 독립적: 자바 프로그램은 자바 가상 머신(JVM) 위에서 실행되기 때문에 운영체제에 독립적입니다. 이것은 "한 번 작성하면, 어디에서나 실행할 수 있다(Write once, run anywhere)"라는 원칙을 가능하게 합니다.
3. 자동 메모리 관리: 자바는 가비지 컬렉터를 통해 자동 메모리 관리를 수행합니다. 이는 프로그래머가 직접 메모리를 할당하고 해제하는 번거로움을 덜어줍니다.
4. 풍부한 API 라이브러리: 자바는 풍부한 API 라이브러리를 제공하며, 이를 통해 네트워킹, 데이터베이스 연결, XML 파싱 등 다양한 기능을 쉽게 구현할 수 있습니다.
5. 멀티스레딩 지원: 자바는 멀티스레딩을 지원하여, 여러 스레드를 동시에 실행할 수 있습니다. 이는 효율적인 자원 활용과 더 빠른 응답 시간을 가능하게 합니다.

**가비지 컬렉터(Garbage Collector, GC)는 자바와 같은 언어에서 메모리 관리를 담당하는 시스템입니다.

자바는 개발자가 직접 메모리를 할당하거나 해제하는 코드를 작성하지 않아도, 자동으로 필요없는 메모리를 해제하는 가비지 컬렉터를 제공합니다.프로그램이 실행되면서 동적으로 메모리를 할당받아 사용하게 되는데, 사용이 끝난 메모리는 해제해야 합니다. 만약 해제하지 않으면 메모리 누수가 발생하여 시스템의 성능을 저하시키거나, 최악의 경우 시스템이 멈추는 문제가 발생할 수 있습니다. 이런 문제를 방지하기 위해 가비지 컬렉터가 도입되었습니다.

가비지 컬렉터는 프로그램이 동작하는 동안 주기적으로 실행되며, 더 이상 사용되지 않는 메모리(즉, 가비지)를 찾아 해제합니다. 사용되지 않는 메모리를 판단하는 기준은 다양하지만, 가장 일반적으로는 '참조되지 않는 객체'를 가비지로 간주합니다. 즉, 다른 객체나 코드에서 참조하고 있지 않은 객체는 가비지로 간주되어, 가비지 컬렉터에 의해 메모리에서 해제됩니다.

가비지 컬렉터(GC)는 힙 영역 내부의 메모리를 관리합니다. 힙 영역은 자바에서 동적으로 생성된 객체들이 저장되는 공간입니다. 그런데 이 공간에 저장된 객체들 중에서 사용되지 않는 것들, 즉 '가비지'를 가비지 컬렉터가 처리합니다.

1. Mark(표시): 첫 번째 단계에서는 GC가 어떤 객체가 가비지인지 판단합니다. 이를 위해 GC는 'root'로 부터 시작해 접근 가능한 객체들을 모두 표시합니다. 여기서 'root'는 전역 변수, 스택, CPU 레지스터 등 GC가 시작점으로 사용하는 참조들입니다. 이 단계가 끝나면, 표시되지 않은 객체들은 접근 불가능한 객체로 간주되고, 이들이 바로 가비지입니다.
2. Sweep(청소): 이 단계에서는 GC가 가비지를 실제로 메모리에서 제거합니다. 표시되지 않은 객체들, 즉 가비지들을 힙에서 제거하고 그 공간을 회수합니다.
3. Compact(압축): 이는 선택적 단계이며, 모든 가비지를 제거한 후에 메모리의 단편화를 줄이기 위해 실행됩니다. 즉, 살아있는 객체들을 한쪽으로 몰아서 새로운 객체들이 최대한 연속적인 메모리 공간에 할당될 수 있도록 합니다.

이렇게 GC는 동적으로 할당된 메모리를 자동으로 관리함으로써 개발자가 메모리 관리에 신경 쓰지 않아도 되게 해주며, 이는 메모리 누수와 같은 심각한 버그를 방지하는 데 크게 기여합니다.

JVM (Java Virtual Machine, 자바를 실행하기 위한 가상 컴퓨터) 

1. 플랫폼 독립적: JVM은 자바 바이트코드를 해석하고 실행하는 역할을 하며, 이 때문에 자바 애플리케이션은 '한 번 작성하면 어디에서나 실행 가능'합니다(Write once, Run anywhere). 즉, 어떤 운영 체제에서든 JVM이 설치되어 있다면 동일한 자바 애플리케이션을 실행할 수 있습니다.
   Java는 플랫폼 독립적인 언어로, 코드를 바로 기계어로 컴파일하지 않고 중간 형태인 바이트코드로 컴파일합니다. 이 바이트코드는 JVM이라는 가상 머신에서 동작하며, JVM이 바이트코드를 해당 플랫폼의 네이티브 코드(기계어)로 해석합니다. 이로 인해 Java 프로그램은 다양한 플랫폼에서 실행될 수 있습니다.
   
2. 메모리 관리: JVM은 자바 애플리케이션을 위한 메모리를 할당하고, 더 이상 필요하지 않은 객체에 대한 메모리를 자동으로 회수하는 가비지 컬렉터를 제공합니다. 이를 통해 개발자는 메모리 관리에 대해 크게 걱정하지 않고 코드를 작성할 수 있습니다.
3. 보안: JVM은 자바 애플리케이션을 실행하기 전에 바이트코드 검사를 수행하여 악성 코드가 시스템에 영향을 미치지 않도록 보호합니다. 또한, JVM은 메모리 관리 및 예외 처리와 같은 기능을 통해 애플리케이션의 안정성을 보장합니다.
4. 멀티스레드 지원: JVM은 자바의 멀티스레드 기능을 지원하여 동시성 프로그래밍을 가능하게 합니다. JVM이 스레드 스케줄링과 관련된 작업을 처리하므로 개발자는 비즈니스 로직에 집중할 수 있습니다.
5. 성능 최적화: 최신 JVM들은 JIT(Just-In-Time) 컴파일러를 통해 성능을 최적화합니다. 이는 자주 사용되는 바이트코드를 네이티브 코드로 컴파일하여 프로그램의 실행 속도를 향상시킵니다.
   JVM 내부에는 JIT 컴파일러라는 구성 요소가 있습니다. 이는 프로그램 실행 중에 바이트코드를 해당 시스템의 네이티브 코드(기계어)로 동적으로 컴파일합니다. 이렇게 하면 해당 부분의 코드를 더 빠르게 실행할 수 있습니다.
   "자주 사용되는 바이트코드를 네이티브 코드로 컴파일"한다는 의미는, 프로그램에서 반복적으로 사용되는 부분(즉, '핫스팟'이라 불리는 부분)은 JIT 컴파일러가 바이트코드에서 직접 기계어로 변환하게 됩니다. 이 변환된 코드는 프로그램이 실행되는 동안 캐시에 저장되어 재사용되며, 이로 인해 프로그램 실행 속도가 크게 향상됩니다. 이러한 최적화 방식을 통해 JVM은 고성능을 유지하면서도 플랫폼 독립성을 보장합니다.
6. 즉, 일반 어플리케이션의 코드는 OS 만 거치고 하드웨어로 전달되지만 Java 애플리케이션은 JVM을 한 번 더 거치게 된다. 

**멀티스레드(multi-threading) : 

 컴퓨터의 한 프로세스 내에서 여러 개의 실행 경로(스레드)를 동시에 수행하는 기능을 말합니다.

해당 기능은 한 프로세스 내에서 데이터를 공유하면서 동시에 작업을 처리할 수 있게 해줍니다.

스레드는 프로세스 내의 가장 작은 실행 단위이며, 각 스레드는 독립적인 실행을 위한 자신만의 프로그램 카운터, 레지스터 집합, 그리고 스택을 갖습니다. 또한 같은 프로세스 내의 다른 스레드들과 코드, 데이터 섹션, 열린 파일 등과 같은 시스템 자원을 공유합니다.

멀티스레드의 주요 장점은 다음과 같습니다:

1. 자원 공유: 멀티스레드는 같은 프로세스 내에서 자원을 공유하기 때문에, 자원의 사용 효율이 높습니다. 또한, 프로세스 간 통신에 비해 스레드 간 통신이 더 간단하고 빠릅니다.
2. 응답성 향상: 하나의 스레드가 블록(예: I/O 작업을 기다림)되어 있을 때, 다른 스레드는 계속 실행될 수 있으므로 프로그램의 응답성이 향상됩니다.
3. 프로세서 활용 최대화: 멀티 코어 또는 멀티 프로세서 시스템에서는 멀티스레드를 통해 병렬 처리를 수행하여 시스템의 처리 능력을 극대화할 수 있습니다.

그러나, 멀티스레딩은 동기화, 교착 상태(deadlock), 스레드 간의 경쟁 상태(race condition) 등과 같은 복잡한 문제들을 포함하고 있으므로, 이를 잘 관리하는 것이 중요합니다.

예시)

멀티스레딩은 말 그대로 '여러 스레드를 사용하는 것'을 뜻합니다. 스레드는 간단하게 말하면 '작업 단위'라고 볼 수 있습니다.

예를 들어, 여러 명의 친구에게 문자 메시지를 보내려고 할 때, 한 명에게 메시지를 보낸 후에 다음 친구에게 메시지를 보낼 수 있습니다.

이것은 '싱글 스레딩'과 비슷한 개념입니다. 즉, 한 번에 하나의 작업만 수행합니다.

하지만 '멀티스레딩'을 이용하면,  여러 명의 친구에게 동시에 문자 메시지를 보낼 수 있습니다. 이렇게 함으로써, 각각의 친구들에게 메시지를 보내는 작업이 서로 겹치지 않게 되므로, 메시지를 보내는 전체적인 시간이 줄어듭니다. 이렇게 여러 개의 작업을 동시에 처리하는 것이 바로 '멀티스레딩'의 개념입니다.

이때 주의할 점은, 멀티스레딩이라 하여도 실제로는 한 번에 한 가지 작업만 수행할 수 있습니다. 즉, 컴퓨터는 여러 개의 작업을 동시에 처리하는 것처럼 보이지만, 사실은 매우 빠르게 여러 작업 사이를 전환하면서 처리하는 것입니다.

요약하자면 '멀티스레딩'은 컴퓨터가 여러 작업을 동시에 처리하는 것처럼 보이게 만드는 기능이라고 생각하면 됩니다.

1. 동기화(Synchronization): 동기화는 여러 스레드가 공유 자원에 동시에 접근하는 것을 제어하는 것을 의미합니다. 예를 들어, 두 개의 스레드가 동일한 데이터를 변경하려고 할 때 문제가 발생할 수 있습니다. 이런 경우 동기화를 통해 한 번에 하나의 스레드만 해당 데이터에 접근하도록 할 수 있습니다.
2. 교착 상태(Deadlock): 교착 상태는 두 개 이상의 스레드나 프로세스가 서로가 가지고 있는 자원을 기다리며 무한정 대기하는 상황을 말합니다. 예를 들어, 스레드 A가 자원 1을 잠근 상태에서 자원 2를 요청하고, 동시에 스레드 B가 자원 2를 잠근 상태에서 자원 1을 요청하는 상황이 생길 수 있습니다. 이렇게 되면 두 스레드는 서로가 잠근 자원을 풀어줄 때까지 기다리게 되는데, 둘 다 자신의 자원을 놓지 않으므로 영원히 대기하게 됩니다. 이것이 바로 교착 상태입니다.
3. 경쟁 상태(Race Condition): 경쟁 상태는 두 개 이상의 스레드가 동일한 자원에 동시에 접근하려고 할 때 발생하는 문제를 말합니다. 스레드의 실행 순서에 따라 결과가 달라지므로, 예측 불가능한 결과를 초래할 수 있습니다. 예를 들어, 두 스레드가 같은 변수를 동시에 증가시키려고 하면, 예상했던 것보다 작은 값이 저장될 수 있습니다. 이런 문제는 동기화를 통해 해결할 수 있습니다.

위의 문제들은 멀티스레딩 환경에서 주의 깊게 다뤄야 하는 중요한 이슈들입니다. 즉, 여러 스레드가 동시에 동작하게 만드는 것이 좋을 때도 있지만, 이러한 문제들을 유발할 수 있으므로 신중하게 접근해야 합니다.

https://javapapers.com/core-java/java-jvm-run-time-data-areas/#Program_Counter_PC_Register

https://mangkyu.tistory.com/119

https://d2.naver.com/helloworld/329631

https://www.blog-dreamus.com/post/zgc%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C