1. 의존성 주입방식 3가지(생성자, Setter, Field)에 대해서 예제 코드와 함께 이론 정리
2. 스프링 공식 문서에서 생성자 주입 방식 사용을 정식으로 권고하고 있는데 그 이유가 무엇인지 정리하고 예제코드 작성하기
3. 객체지향 관점에서 DI 방식으로 의존성 문제를 해결하면 어떤 장점이 있는지 예제코드로 정리하기
4. 주변 동료들의 블로그에 들어가서 내 글과 비교해보고 회고록 작성해보기!

의존성 주입 3가지

@Autowired : Spring의 의존성 주입 기능에 의해 자동으로 연결되도록 생성자, 필드, setter 메서드 또는 구성 메서드를 표시합니다. 한마디로 "나는 여기에 스프링이 의존성을 자동으로 주입해 주기를 바란다." 라고 명시하는 어노테이션

1. 생성자 주입

생성자 주입은 객체를 생성할 때, 해당 객체가 의존하는 다른 객체들을 생성자 매개변수로 받아들이는 방식입니다. 이렇게 주입받은 의존성을 객체 내부의 멤버 변수에 할당하여 사용합니다.

• 이점

1. 의존성이 누락되는 것을 방지하고 객체가 항상 유효한 상태로 생성됩니다.
2. 불변성(Immutable)을 유지하며, 객체가 생성된 후에는 의존성을 변경할 수 없습니다.
3. 의존성 주입을 강제하기 때문에 코드를 테스트하기 쉽고 의존성 관리가 용이합니다.

@Service
public class Client {
    private final CocoService cocoService;

    @Autowired
    public Client(CocoService cocoService) {
        this.cocoService = cocoService;
      }

2. Setter 주입

Setter 주입은 의존성을 주입하는 메서드(Setter)를 통해 의존성을 설정하는 방식입니다. Setter 메서드는 객체 생성 후에 호출되어 의존성을 주입합니다.

• 이점:

1. Setter 메서드를 통해 의존성을 주입하므로, 객체 생성 후에도 의존성을 변경할 수 있습니다.
2. 선택적으로 의존성을 주입받을 수 있습니다. 즉, 의존성이 필수적이지 않을 때 사용할 수 있습니다.

   @Service
   public class Client {
       private CocoService cocoService;
       
       @Autowired
       public void setCocoService(CocoService cocoService) {
           this.cocoService = cocoService;
       }
   }

3. 필드 주입

필드 주입은 의존성을 클래스의 멤버 변수로 직접 주입하는 방식입니다. 주로 리플렉션(Reflection)을 사용하여 의존성을 주입합니다.

@Service
class Client {
    private CocoService cocoService;

    @Autowired 
    private CocoService cocoService;
 }

스프링 공식 문서에서 생성자 주입 방식 사용을 권고하는 이유

1. 순환 참조 에러 방지

생성자 주입 방법은 필드 주입이나 수정자 주입과는 빈을 주입하는 순서가 다릅니다.

먼저 Setter 주입을 살펴보면 우선 주입 받으려는 빈의 생성자를 호출하여 빈을 찾거나 빈 팩터리에 등록합니다. 그 후에 생성자 인자에 사용하는 빈을 찾거나 만듭니다. 그 이후에 주입하려는 빈 객체의 수정자를 호출하여 주입합니다.

다음으로 필드 주입은 수정자 주입 방법과 동일하게 먼저 빈을 생성한 후에 어노테이션이 붙은 필드에 해당하는 빈을 찾아서 주입하는 방법입니다. 그러니까, 먼저 빈을 생성한 후에 필드에 대해서 주입합니다.

마지막으로** 생성자 주입**은 생성자로 객체를 생성하는 시점에 필요한 빈을 주입합니다. 조금 더 자세히 살펴보면, 먼저 생성자의 인자에 사용되는 빈을 찾거나 빈 팩터리에서 만듭니다. 그 후에 찾은 인자 빈으로 주입하려는 빈의 생성자를 호출합니다. 즉, 먼저 빈을 생성하지 않습니다. 수정자 주입과 필드 주입과 다른 방식입니다.

그렇기 때문에 순환 참조는 생성자 주입에서만 문제가 됩니다. 객체 생성 시점에 빈을 주입하기 때문에 서로 참조하는 객체가 생성되지 않은 상태에서 그 빈을 참조하기 때문에 오류가 발생합니다.

순환 참조가 있는 객체 설계는 잘못된 설계이기 때문에 오히려 생성자 주입을 사용하여 순환 참조되는 설계를 사전에 막아야 합니다.

2. 객체의 불변성을 확보 : 필드를 final로 선언할 수 있다.

대부분의 의존관계 주입은 한 번 일어나면 애플리케이션 종료 시점까지 의존 관계를 변경할 일이 거의 없습니다.

생성자 주입을 사용하면 객체를 생성할 때 한번만 호출되므로 객체가 불변하게 설계할 수 있습니다.

@Service
public class Client {
    private final CocoService cocoService;

    @Autowired
    public Client(CocoService cocoService) {
        this.cocoService = cocoService;
      }

3. 테스트 용이성

생성자 주입은 의존성을 외부로부터 주입받기 때문에 테스트 시 의존성을 직접 주입하여 단위 테스트를 쉽게 수행할 수 있습니다. 생성자 주입을 사용하면 Mock 객체 등을 주입하여 의존성을 대체하고 테스트하기 용이합니다.

객체지향 관점에서 DI 방식으로 의존성 문제를 해결하면 어떤 장점이 있는지

1. 느슨한 결합(Loose Coupling): DI를 사용하지 않은 경우, cocoService 직접 cocoRepository를 생성하고 의존합니다. 이로 인해 cocoService와 cocoRepository 사이의 결합도가 높아집니다.

public class cocoService {
    private CocoRepository cocoRepository;

    public cocoService() {
        this.cocoRepository = new CocoRepository(); // 의존성 직접 생성
    }

    public User getUserById(Long userId) {
        return cocoRepository.getUserById(userId);
    }
}

DI를 사용하여 의존성을 주입받는 방식으로 변경하면, cocoService cocoRepository를 생성하지 않고 외부에서 주입받아 사용합니다. 이로 인해 cocoService cocoRepository를 사이의 결합도가 낮아집니다.

public class CocoService {
    private CocoRepository cocoRepository;

    public CocoService(CocoRepository cocoRepository) {
        this.cocoRepository = cocoRepository; // 의존성 주입
    }

    public User getUserById(Long userId) {
        return cocoRepository.getUserById(userId);
    }
}

2. 단일 책임 원칙 준수 : DI를 사용하여 의존성을 주입받는 방식으로 변경하면, cocoService 자신의 주요 기능에만 집중할 수 있습니다. cocoRepository를 생성과 관련된 책임은 외부에서 담당하므로, 단일 책임 원칙을 준수하게 됩니다.

3. 테스트 용이성: DI를 사용하여 의존성을 주입받는 방식으로 변경하면, 테스트 시에 cocoRepository를 Mock 객체로 대체하여 주입할 수 있습니다. 이렇게 하면 cocoService 테스트할 때 외부 의존성을 제어하고 테스트할 수 있습니다.

참고자료 링크텍스트 링크텍스트 링크텍스트

영속성

영속성(Persistence)은 데이터를 생성한 프로그램이나 처리하는 시스템이 종료되더라도 사라지지 않고 계속해서 유지되는 특성을 의미합니다. 즉, 데이터를 저장하는 과정에서 생성된 객체나 데이터를 DB나 파일 시스템 등에 저장해 놓고 나중에 필요할 때 다시 불러와 사용할 수 있도록 하는 것을 말합니다.

영속성 컨텍스트

 엔티티를 영구 저장 하는 환경 이라는 뜻 입니다. 어플리케이션에서 데이터베이스에서 꺼내온 데이터 객체를 보관하고 관리하는 역할을 합니다. 영속성 컨텍스트는 엔티티 매니저를 통해 엔티티를 조회하거나 저장할 수 있습니다.

SQL Mapper

개발자가 직접 SQL문을 작성해 데이터베이스 데이터를 다루는 Persistence Framework입니다. 객체와 테이블 간의 관계를 직접 매핑하는 것이 아닌, SQL문을 실행해 쿼리 수행 결과를 어떤 객체에 매핑할지 바인딩 하는 방법입니다. 따라서 DBMS에 종속적인 방법이라고 할 수 있습니다.

SQL Mapper 장점

1. JDBC를 사용할 때 발생하는 불편함을 줄일 수 있다.
2. SQL이 비즈니스 로직과 분리되어 유지보수가 용이하다.
3. 세부적인 SQL 변경시 편리하다
4. 기존에 SQL문법을 그대로 적용할 수 있어 새로운 기술을 학습하지 않아도 된다.

SQL Mapper 단점

1. DBMS 별로 SQL 문법이 다르다. 2, 개발자가 직접 SQL문을 작성해야 한다.
2. DBMS 변경시 SQL문을 재사용하기 어렵다.
3. 객체와 테이블간 패러다임 불일치가 발생한다.

ORM

ORM(객체 관계 매핑, Object-Relational Mapping)은 객체 지향 프로그래밍 언어와 관계형 데이터베이스를 연결해주는 기술입니다.

ORM은 데이터베이스에 직접 SQL 쿼리를 작성하지 않아도, 객체를 통해 간접적으로 데이터베이스를 조작할 수 있게 해줍니다.

ORM은 객체와 테이블 간의 매핑 규칙을 설정하고, 이에 따라 객체의 필드와 테이블의 칼럼을 매핑하여 객체를 데이터베이스에 저장하고, 데이터베이스에서 객체를 불러올 수 있도록 합니다.

=> 개발자는 데이터베이스와의 상호작용을 객체지향적으로 처리할 수 있고, 복잡한 SQL 문장을 직접 작성하지 않아도 됩니다.

ORM 사용 이유

1. 완벽한 객체지향적인 코드 : 직관적인 이해가 쉬움
2. 재사용, 유지보수, 리팩토링 용이성 : ORM을 통해 작성한 객체를 재활용할 수 있다는 측면에서 재사용 및 유지보수의 편리성이 증가함
3. DBMS 종속성 하락

ORM 단점

1. ORM이 모든 것을 해결해줄 수 없기 때문에 적절하게 SQL문을 사용할 수 있어야 한다.
2. 복잡한 쿼리문의 경우 오히려 SQL문으로 사용이 직관적이면서 효울적일 수 있다.

SQL

SQL은 Structured Query Language의 약어.

SQL을 사용하면 RDBMS에서 데이터를 저장, 수정, 삭제 및 검색 할 수 있습니다.

데이터는 정해진 데이터 스키마에 따라 테이블에 저장됩니다. 데이터는 관계를 통해 여러 테이블에 분산됩니다.

SQL 장점

1. 명확하게 정의된 스키마, 데이터 무결성 보장할 수 있습니다.
2. 관계는 각 데이터를 중복없이 한번만 저장합니다.

SQL 단점

1. 덜 유연해서 데이터 스키마를 사전에 계획하고 알려야 합니다. (나중에 수정하기 힘듦)

스키마 : 데이터베이스에 저장되는 자료 구조와 제약 조건을 정의한 것

2. 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있습니다.
3. 대체로 수직적 확장만 가능합니다.

MVC

MVC는 Model-View-Controller의 약자로, 소프트웨어 개발 패턴 중 하나입니다. 이 패턴은 어플리케이션의 로직과 사용자 인터페이스를 분리하여 개발을 용이하게 하며, 소프트웨어 개발 시 유지보수와 확장성을 높일 수 있는 구조를 제공합니다.

Model

Model은 어플리케이션의 데이터와 비즈니스 로직을 담당하며, 데이터의 상태 변경과 관련된 작업을 처리합니다.

View

View는 어플리케이션의 사용자 인터페이스를 담당하며, Model의 데이터를 보여주는 역할을 합니다.

Controller

Controller는 사용자의 입력을 받아 Model과 View 간의 상호작용을 관리합니다. Controller는 Model의 데이터를 변경하거나, View에 표시할 데이터를 선택하고, View의 표시 방법을 변경하는 작업을 수행합니다.

=> 이렇게 각각의 역할을 분리함으로써, 하나의 역할이 다른 역할의 변경에 영향을 받지 않고 독립적으로 작업할 수 있습니다. 이로 인해 개발자는 어플리케이션의 로직과 사용자 인터페이스를 동시에 수정하지 않아도 되며, 소프트웨어의 유지보수와 확장성을 높일 수 있습니다.

매핑해주는 관계에서 user와 comment사이에서 양방향 매핑이 되어서 사이클이 생성되며 무한루프에 빠지게 됐다.

java.lang.StackOverflowError

Stack Overflow error

❓ 원인

자바에서 발생하는 런타임 예외 중 하나로, 스택 메모리 공간이 꽉 차서 더 이상 메소드 호출을 처리할 수 없을 때 발생한다.

자바 프로그램은 메소드 호출을 처리하기 위해 스택 메모리를 사용하는데 메소드 호출이 발생하면 호출된 메소드의 정보가 스택에 쌓이게 된다. 그리고 해당 메소드의 실행이 완료되면 스택에서 제거된다. 그런데 메소드 호출이 지나치게 많거나 메소드 내부에서 무한 반복문이나 재귀 호출 등이 발생하면 스택 메모리 공간이 모두 소진되어 StackOverflowError 예외가 발생하게 된다.

스택(Stack)영역 : 메서드 호출과 관련된 임시 데이터를 저장하는 영역으로 임시적으로 사용되는 변수나 정보들이 저장되는 영역으로 참조형 주소값만 저장된다. 메서드 실행이 끝나면 해당 메서드와 함께 스택에서 제거되고 메서드 호출 시마다 새로운 스택 프레임(Stack Frame)이 생성되며, 로컬 변수, 매개변수, 리턴 값 등이 저장된다. 스택 메모리는 스레드마다 별도로 생성되며, 스레드 간에 공유되지 않는다.

❗해결방법

해결방법1 : 양방향 관계에서 직렬화 방향을 설정해주어 순환참조를 해결할 수 있도록 설계된 어노테이션인 @JsonManagedReference 또는 @JsonBackReference를 사용한다.

• ** @JsonManagedReference** 역참조 관계에서 관리 주체가 되는 객체를 가리키는 어노테이션. 이 어노테이션을 사용하면 해당 객체를 직렬화할 때 참조하고 있는 다른 객체도 함께 직렬화하도록 지정할 수 있다

역참조관계 : 객체들 간의 서로 참조하는 관계에서 어떤 객체가 자기 자신을 참조하거나, 다른 객체가 자신을 참조하는 것을 말하며 예를 들어, A 객체와 B 객체가 서로를 참조하는 상황에서, A 객체가 B 객체를 참조하고 있으면 B 객체는 A 객체를 역참조하고 있는 것.

• @JsonBackReference 역참조 관계에서 관리 대상이 되는 객체를 가리키는 어노테이션. 이 어노테이션을 사용하면 해당 객체를 직렬화할 때 역참조 관계에 있는 다른 객체의 직렬화를 무시하도록 지정할 수 있다.

직렬화 :객체를 직렬화하면 해당 객체를 파일로 저장하거나 네트워크를 통해 전송할 수 있다. 또한 직렬화된 객체를 역직렬화하여 다시 객체로 복원할 수 있다.

public class Parent {
    private Long id;
    private String name;
    @JsonManagedReference
    private List<Child> children;
}

public class Child {
    private Long id;
    private String name;
    @JsonBackReference
    private Parent parent;
}

위 코드에서 Parent 클래스는 Child 클래스를 매핑하는 children 필드를 가지고 있으며, Child 클래스는 parent 필드를 가지고 있다.

이 때 @JsonManagedReference 어노테이션은 Parent 객체를 직렬화할 때 참조하고 있는 Child 객체도 함께 직렬화하도록 지정한다. 반면 @JsonBackReference 어노테이션은 Child 객체를 직렬화할 때 parent 필드를 무시하도록 지정한다.

따라서, Parent 객체를 직렬화할 때는 Child 객체도 함께 직렬화된다. 그러나 Child 객체를 직렬화할 때는 parent 필드를 무시하므로, Parent 객체는 직렬화되지 않는다.

해결방법2 :@JsonIgnore 사용한다

• @JsomIgnore : 해당 필드나 메소드를 JSON 직렬화/역직렬화할 때 무시하도록 지정할 수 있다. 이 어노테이션을 사용하면 JSON 데이터에 해당 프로퍼티(property)는 null로 들어가게 된다. @JsomIgnore을 사용하는 이유는 보안상 민감한 정보나 직렬화되지 않아도 되는 정보를 숨기는 데에 유용하다. ex)비밀번호

해결방법3 : DTO를 사용한다

• 순환참조의 상황이 발생한 주 원인은 양방향 매핑이기도 하지만, 더 정확하게는 entity를 직접 반환한것이 순환참조 발생의 큰 원인중 하나이다.

entity 자체를 return 하는것이 아니라, DTO객체를 만들어 필요한 데이터만 반환하면 순환참조 관련 문제를 사전에 방지 할 수 있다.

📝 참조링크

1. IoC(Inversion of Control): IoC는 제어의 역전이라는 뜻으로, 기존의 제어 흐름이 개발자가 코드를 작성하여 제어하는 것이 아니라 프레임워크나 컨테이너 같은 외부에서 제어가 되는 개념을 말합니다.개발자가 객체의 생성과 관리, 제어 흐름 등을 직접 제어하는 것이 아니라, 외부에서 이를 관리하는 것을 의미합니다. 이로써 코드의 결합도를 낮추고, 유연한 구조를 가질 수 있습니다.

2. DI(Dependency Injection): DI는 의존성 주입이라는 뜻으로, 객체 간의 의존성을 외부에서 주입하는 개념을 말합니다.객체가 다른 객체에 의존할 때, 객체를 직접 생성하거나 참조하는 대신 외부에서 해당 객체를 주입받아 사용하는 방식입니다. 이로써 객체 간의 결합도를 낮추고, 테스트 용이성과 재사용성을 높일 수 있습니다.

3. DI는 IoC를 구현하는 방법 중 하나로, 외부에서 객체를 주입하는 것이 IoC의 한 형태라고 볼 수 있습니다. DI는 생성자 주입(Constructor Injection), 메서드 주입(Method Injection), 속성 주입(Property Injection) 등의 방법으로 구현될 수 있습니다. 이러한 IoC와 DI는 객체지향 프로그래밍에서 유연하고 확장 가능한 소프트웨어 아키텍처를 구현하는데 도움을 주는 중요한 개념입니다.

회고 :

HTTP

하이퍼텍스트 전송 프로토콜. 인터넷에서 데이터를 주고받기 위한 통신 규약.

동작 : 클라이언트(사용자)가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request)을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작된다.

• 요청 : client -> server
• 응답 : server -> client

HTTP Method

• GET : 자료를 요청할 때 사용
• POST : 서버에 데이터를 제출할 때 사용. 데이터를 Body에 담아서 서버로 전송
• PUT : 자료 모두 수정
• PATCH : 자료 일부 수정
• DELETE : 자료의 삭제

요청(request)구조

• Start Line(첫줄) : 요청 메소드, 요청 URL, HTTP 버전 정보로 구성된다.
• Headers(두 번째 줄부터) : 클라이언트가 서버에게 전달하는 추가 정보를 담고 있다.
• Body(헤더에서 다음) : HTTP 요청과 관련된 데이터를 담고 있다. 필수 요소는 아니며, 요청에 따라 전송되지 않을 수도 있다.

응답(response)상태코드(HTTP Status Code)

• 1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
• 2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다. ex)200
• 3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
• 4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다. ex)404
• 5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다. ex)500

응답(response)구조

• Start Line
• Headers
• Body

API

애플리케이션 프로그램 인터페이스.

클라이언트와 서버가 HTTP를 통해 서로 통신을 하며 기능을 동작 시키는데 이때 서로간의 정해진 통신 규칙.

URI : 인터넷에서 특정한 정보 자원을 나타내는 고유 식별자로, 인터넷 자원의 위치나 이름을 나타냅니다. URL : 인터넷에서 특정한 자원의 위치를 나타내는 식별자 입니다. URL 은 프로토콜, 도메인 이름, 포트 번호, 경로 등으로 구성됩니다.

=> URI 는 리소스를 나타내는 고유한 식별자를 의미하며, URL 은 리소스의 위치를 나타내는 식별자

MVC

소프트웨어 디자인 패턴 중 하나로, 코드의 재사용성과 유지보수성을 높이고 개발자들 간의 현업을 용이하게 해줍니다.

Controller를 조작하면 Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달한다.

구성요소(Model - View - Controller)

• Model은 데이터와 비즈니스 로직을 담당이다.

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 함
2. 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 함
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함

• View는 사용자 인터페이스를 담당이다.

1. 모델이 가지고 있는 정보를 따로 저장해서는 안됨
2. 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 함
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 함

• Controller는 Model과 View 사이의 상호작용을 조정하고 제어이다.

1. 모델이냐 뷰에 대해서 알고 있어야 함
2. 모델이나 뷰의 변경을 모니터링해야 함

MVC장점

1. 여러 개발자가 역할을 나눠서 모델, 컨트롤러, 뷰를 동시에 개발할 수 있습니다. 예를 들어 Java개발자가 모델과 컨트롤러를 개발하고, UI 개발자가 뷰부분을 담당하여 개발할 수 있습니다. 이를 통해 개발시간 단축과 역할분리가 가능합니다.

2. 중복코드를 없앨 수 있고, 확장성있고 유연한 코딩이 가능합니다. 예를 들어, Java 코드로 로직을 설계한것이 웹으로 배포할 내용과, 앱으로 배포할 내용이 있다면 View 부분만 바꿔서 코딩할 수 있습니다.

3. 각 컴포넌트별로 나눠져 있어 디버깅과 테스트가 용이 합니다.

MVC단점

1. 규모가 커질수록 파일이 많아져 복잡해질 수 있습니다. 하나의 새로운 기능을 구현하려면 Model, View, Controller를 각각 따로 만들어서 너무 많은 파일이 생성될 수 있습니다.

2. 개발자 수가 적으면 오히려 유지보수 시간이 길어질 수 있습니다. 하나의 파일에서 모든 로직을 처리하도록 하도록 하면 해당 파일만 수정하면 되나, MVC 패턴으로 개발을 하면 여러 파일을 왔다갔다 하면서 수정해야하기 때문에 유지보수 개발하는데 시간이 더 거릴 수 있습니다.

Spring의 MVC

서브릿(Servlet)

• Java 언어로, 자바를 사용하여 웹을 만들기 위해 필요한 기술.
• 클라이언트의 요청에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트
• Servlet은 클라이언트로부터 요청을 받아서 처리하고, 응답을 생성하여 클라이언트에게 전송합니다. ex) 사용자가 로그인을 하려고 할 때, 사용자는 아이디와 비밀번호를 입력 후 로그인 버튼을 누름 - 이때 서버는 클라이언트의 아이디와 비밀번호를 확인하고 다음 페이지를 띄워주는 역할을 수행.
• Servlet은 HTTP 요청과 응답에 대한 처리를 담당하며, Java EE(Enterprise Edition) 플랫폼의 일부로 제공됩니다.
• Java Thread를 이용하여 동작한다.
• MVC 패턴에서 Controller로 이용된다.
• 일반적으로 웹 애플리케이션 서버에서 실행되며, 템플릿 엔진과 함께 웹 애플리케이션을 개발하는 경우가 많습니다.
• 템플릿 엔진은 웹을 동적으로 처리하기 위해 만들어진 것으로 JSP(Java Server Pages), Thymeleaf 등이 있습니다.

톰캣(Tomcat)

Servlet과 MVC

• Servlet을 이용하면 Controller 역할을 수행할 수 있습니다. Servlet은 클라이언트의 요청을 처리하고, 요청에 따른 적절한 데이터를 Model에서 가져와서 View에게 전달하는 역할을 할 수 있습니다.(아까 예시 처리 과정에서 Servlet이 Controller 역할을 수행)
• 템플릿 엔진을 이용하여 View 역할을 수행할 수 있습니다. 템플릿 엔진은 HTML과 Java 코드가 결합된 형태로 웹 페이지를 생성할 수 있는 기술입니다. 템플릿 엔진은Model에서 가져온 데이터를 HTML 형식으로 출력하는 역할을 수행합니다.

=> Servlet과 MVC 패턴을 함께 사용하면, 웹 애플리케이션의 구조를 명확하게 설계할 수 있고, 각각의 역할을 분리하여 개발 및 유지보수를 보다 쉽게 할 수 있습니다.

객체지향 프로그래밍?

• 객체란, 세상에 존재하는 모든 것으로 특징과 행동이 있다.

• 객체 지향이란, 객체 지향 모델링은 기능이 아닌 객체가 중심이 되며 "누가 어떤 일을 할 것인가?"가 핵심이 된다. 즉, 객체를 도출하고 각각의 역할을 정의해 나가는 것에 초점을 맞춘다.

• 객체 지향 프로그램의 특징으로는 추상화, 캡슐화, 상속성, 다형성, 동적바인딩이 있다.

JVM

JVM : Java Virtual Machine 의 약자로 “자바 가상 머신” 이라는 뜻. 즉, 여러기기 위에 java 프로그램을 실행시킬 수 있는 가상의 기기.

• 바이트 코드 : JAVA 프로그램 변환 코드. 내가 작성한 코드가 운영 체제가 읽을 수 있는 코드로 java 컴파일러(compiler)가 변환한 코드.

컴파일러 : java가 class로 변환되는 것

• 인터프리터 : Java .class 코드 해석기

• JIT 컴파일러 : 빠른 Java .class 코드 해석기

• 메모리 영역 : Java 데이터를 저장하는 영역

• 클래스 로더 : Java .class 바이트 코드를 메모리 영역에 담는 운반기

• 가비지 컬렉터 : Java 쓰레기 청소기

• JVM 방법 : JRE 설치(Java Runtime Environment 즉, 자바 실행 환경 이라는 뜻) JRE(JVM) 만 있다면 Java 프로그램을 실행만 가능.(.class로 변환)

• JDK : ava Development Kit 즉, 자바 개발 키트 라는 뜻

1. 컴파일러 가능 가능
2. JRE의 기능 가능
3. 디버깅하는 jdb 등의 기능 : 실행중인 프로그램의 코드 실행을 따라다니며 보기 가능.

힙영역(Heap Area)

• 힙 영역은 메서드 영역와 함께 모든 쓰레드가 공유하며, JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다. 즉, new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타입 등 Reference Type이 저장되는 곳. 참조형 변수의 원본이 저장된다.

스택영역(Stack Area)

• 기본 자료형을 생성할 때 저장하는 공간. 임시적으로 사용되는 변수나 정보들이 저장되는 영역으로 참조형 주소값만 저장된다.
• 스택 영역은 각 스레드마다 하나씩 존재하며, 스레드가 시작될 때 할당된다.

메소드 영역

• 클래스 정보와 클래스 변수가 저장되는 곳.JVM은 클래스를 로드할 때 해당 클래스의 정보를 메서드 영역에 저장함. 공유 가능.

pc레지스터

• 현재 실행 중인 JVM 명령어의 주소를 저장

네이티브 메서드 스택

• 자바가 아닌 다른 언어로 작성된 네이티브 메서드를 실행할 때 사용하는 스택