🙋🏻‍♀️야구 실시간 소통 플랫폼의 라이브 채팅 기능 구현 중, websocket + stomp를 사용해 실시간 채팅기능을 구현했다. 실시간 통신을 위한 1. websocket 등장 이전의 방식 2. 단방향 통신(SSE) 3. 양방향 통신(Websocket) 에 대해 정리했다

기존의 Http 통신은 클라이언트가 서버에게 요청을 보내고, 응답을 받는 HTTP 기반 단방향 통신이다

🚫한계 : HTTP 통신의 Stateless, Connectionless한 특성

예를 들어, 내가 지금 구현하고자 하는 실시간 채팅의 경우, 채팅방에 참여중인 모든 상대방의 메세지를 받기위해서는 매번 요청을 보내야함

내가 먼저 메세지를 보낼 순 있지만, 서버는 선톡을 하지 않는다..^^ 이를 해결하기 위한 Http 에서의 기술은 아래와 같다

📖 HTTP Polling

📌 Polling

클라이언트가 일정 주기로 http request를 보낸다

🚫 단점

• HTTP 오버헤드 발생 : 불필요한 요청 多
• 커넥션 맺을 때마다 비용 발생
• 클라이언트가 많아질 때마다 서버의 부담 ↑

📌 Long Polling

클라이언트의 request를 서버는 일정시간 대기 후 응답을 준다 응답까지의 시간을 최대한 늘려서 이벤트 발생시까지 대기한다

1. 클라이언트에서 서버로 http request를 보내면
2. 서버는 연결을 안끊고 기다림
3. 이벤트 발생시 서버는 응답을 주고 연결 종료
4. 클라이언트는 3번에서 응답을 받고 다시 요청을 보낸다

🚫 단점

• 데이터가 대기시간에 비해 변화가 잦을 경우, 일반 polling보다 <요청-응답>이 많아짐
• 다수의 클라이언트에 동시 이벤트 발생시, 응답 받은 후 마찬가지로 동시에 요청을 보내므로 서버 부담 급증

📖 SSE(Server Sent Event)

서버에서 클라이언트에게 실시간으로 데이터를 전송하는 기술이다 기본적으로 HTTP 연결을 길게 유지하면서 서버 ➝ 클라이언트로 데이터를 전송한다

polling 이후로 등장한 기술로 HTTP통신을 기반으로 단방향 통신 기술이다 주로 서버의 데이터 변경이 있을때 클라이언트에게 실시간으로 알려주기 위해 사용한다

✅ 동작 방식

1. Client : SSE Subscribe 요청

GET /connect HTTP/1.1
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

클라이언트 - EventSource 라는 인터페이스로 SSE 연결 요청을 한다

2. Server: Subscription에 대한 응답

HTTP/1.1 200
Content-Type: text/event-stream;charset=UTF-8
Transfer-Encoding: chunked

서버 - SseEmitter 를 이용해 구독 요청에 대한 응답을 한다

3. Server: 이벤트 전달

• 서버가 이벤트 스트림을 전송하여 실시간으로 업데이트된 정보를 제공한다
• 데이터는 UTF-8로 인코딩된 텍스트 데이터만 가능(바이너리 데이터❌)

🔍 데이터 형식 - name:value

event: type1
data: An event of type1.
>
event: type2
data: An event of type2.

📌 장단점

⭕️ 장점

• HTTP 프로토콜을 사용하기에 구현이 비교적 간단하다 (특별한 라이브러리/추가설정 없이도 사용가능)
• 클라이언트 측에서 데이터를 이벤트로 처리하기 용이하다
• 네트워크 단절시 EventSource가 자동으로 재연결을 시도함

❌ 단점

• payload의 크기가 제한적이다
• 브라우저 호환성
• 단방향 통신만 가능하다

📖 Websocket

WebSocket은 기본 HTTP 핸드셰이크를 통해 연결을 시작하고, 이후에는 지속적인 TCP 연결을 통해 양방향 통신이 가능한 프로토콜이다

🔍 TCP = 연결지향 프로토콜 (http의 connectionless와 대비됨)

✅ 동작 방식

Websocket의 동작은 1️⃣ handshake , 2️⃣ Data transfer, 3️⃣ Close Handshake 의 과정을 거친다 과정 별로 자세히 살펴보자 !

📌 ❶ Handshake

• 처음 연결 시에는 HTTP 요청을 보낸다 GET
• 이후 응답이 101 Switching Protocols면 WebSocket 연결 성공!
• 🔍 port
  • ws://의 기본 포트는 80
  • wss://의 기본 포트는 443

✔️ Request 예시

GET /ws-endpoint HTTP/1.1 
Host: server.example.com 
Upgrade: websocket ---------------------------> ✅ 웹소켓 프로토콜로 변경할래
Connection: Upgrade ---------------------------> ✅ Upgrade 헤더를 사용한다
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 
Origin: http://example. com 
Sec-WebSocket-Protocol: chat, superchat ---------------------------> ✅ 서브 프로토콜
Sec-WebSocket-Version: 13 

✅ Upgrade, Connection 헤더 → 웹소켓 전환 요청임을 표시 ✅ Sec-WebSocket-Key → 서버가 인증을 위해 확인하는 값

✔️ Response 예시

HTTP/1.1 101 Switching Protocols -------------------> ✅ 웹소켓 연결 성공 (101)
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

• 웹소켓 연결 성공은 상태코드 101 (그 외의 코드 응답시 http 통신 유지)
• Sec-WebSocket-Accept 작동 방식
  • 서버는 Sec-WebSocket-Key에 고정 문자열258EAFA5-E914-47DA-95CA-C5AB0DC85B11을 붙이고
  • SHA-1 해시 → Base64 인코딩하여 응답함 👉 연결 위조 방지용 보안 절차

📌 ❷ Data Transfer

WebSocket은 양방향(bidirectional) 통신이 가능하며, 데이터는 메시지 단위로, 그 메시지는 프레임(Frame) 단위로 분할 전송된다

🔍 Bidirectional WebSocket Message

• 서버 ↔ 클라이언트 모두 메시지를 자유롭게 보낼 수 있음
• 메시지를 프레임으로 나눠 보내는 구조

✔️ Websocket Frame 구조

[WebSocket 메시지]
 └── 하나 이상의 프레임으로 구성됨
       └── 각 프레임은 다음을 포함:
           - FIN (메시지의 끝인지)
           - Opcode (텍스트인지, 바이너리인지 등)
           - Masking key (보안용)
           - Payload (실제 데이터)

타입, 길이, 실제 데이터(payload) 등을 포함한다 ! .... 만약 조금 더 자세히 웹소켓의 프레임을 살펴보면 다음과 같다 ( 여기서부턴 진짜 안봐도 된다 나는 그냥 실제 프레임 모습이 궁금했다 )

💡 Websocket Frame

 0               1               2               3
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S| (4)   |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 4               5               6               7
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
 8               9               10              11
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
 12              13              14              15
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

• FIN : 마지막 메세지임을 나타냄 / FIN = 0이면 다음 메세지 있음, FIN = 1이면 전체메세지 도착완료
• opcode : payload의 데이터 포맷을 나타냄
  • 0x0은 continuation, 0x1은 텍스트(UTF-8), 0x2 바이너리 데이터...
• MASK : 메세지의 마스킹 여부 / 클라이언트 - 서버로 가는 메세지는 항상 마스킹되어야..
• payload : 보내고자 하는 실제 데이터
• payload length : 페이로드의 길이

• 🔍 opcode 0x0 ?* 하나의 메세지를 여러 프레임으로 나눠 전송할 때 사용! 이거 n개의 메세지 중 중간이야! 뒤에 더 있음 근데 한 메세지임~을 표시

✔️ ping pong으로 연결 상태 확인

• ping : Websocket 연결 중이라면 클라이언트는 ping을 보낼 수 있음 opcode = 0x9
• pong : 서버는 ping을 받으면 payload를 그대로 담아 pong을 보냄 opcode = 0xA
• 🌟 ping pong을 활용해 웹소켓 연결의 Open-Close 여부를 주기적으로 확인 가능*

➕ 실제 코드 예시로 이해하기

• Websocket은 양방향 메세지를 send() 메서드로 보내고,
• onmessage나 handleTextMessage() 같은 이벤트 핸들러에서 수신 메세지를 처리한다

클라이언트 → 서버로 메시지 보내기

const socket = new WebSocket("ws://localhost:8080/ws-endpoint");
socket.send("Hello, Server"); // 메시지 전송
socket.onmessage = (event) => {
  console.log("Message from Server:", event.data); // 서버로부터 메시지를 받으면 실행되는 리스너
};

서버 → 클라이언트로 응답 처리 (Spring WebSocket)

@Override
protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
    String payload = message.getPayload(); // 클라이언트가 보낸 메시지 추출
    session.sendMessage(new TextMessage("Received: " + payload)); // 응답 보내기
}

❗ 다수의 클라이언트에게 브로드캐스트하려면?

for (WebSocketSession sess : sessions) {
    sess.sendMessage(new TextMessage("Broadcast: " + payload));
}

📌 ❸ Close

• Websocket 연결 종료를 의미한다 opcode = 0x8
• 클라이언트, 서버 어느 쪽이든 종료를 요청할 수 있다.
• Websocket에도 상태코드가 존재하지만, 연결 종료시 (Close Frame)에서만 쓰인다! ( 최초 Handshake시 성공 응답인 101은 Http status code임 )

📎Websocket Close Status Code 1000 : 정상 종료 1001 : 연결 주체 중 한쪽 소실 1009 : 메세지가 커서 처리 실패 1011 : 서버의 비정상 에러 발생

🚫 Websocket의 한계점

1. 데이터 해석의 어려움

• payload에 실제 데이터를 담아 전송하지만, 일정한 형식(json, xml 등,,,)이 정해져 있지않다
• 따라서 서버나 클라이언트에서는 문자열을 해석하는 작업(파싱)이 필요한데

📌 해결책 : 서브 프로토콜을 사용한다 (대표적인 하위 프로토콜 : stomp)

2. 연결 유실 및 호환성 이슈

• 일부 브라우저는 WebSocket의 Upgrade 헤더를 인식하지 못하거나
• 오랜 유휴상태일 TCP 연결을 조기 종료시킬 수 있음 ➝ HTTP와 달리 WebSocket은 기존 인프라와 완전히 호환되지 않을 수 있다

📌 해결책 : SockJS(스프링>stomp) , Socket.io(노드)로 웹소켓 미지원환경에서 우회 연결 시도할 수 있음

🙋🏻‍♀️이렇게 실시간 통신을 위한 몇가지 기술들을 살펴봤다 SSE는 실시간 통신이 필요한 서비스에서 Polling을 대체할 수 있는 간단하고 강력한 옵션이지만, 양방향 통신이나 고급 메시징 구조가 필요하다면 WebSocket 기반으로 넘어가는 것이 일반적이다. 따라서 나는 Websocket + 서브 프로토콜인 STOMP를 사용했다

💡 의존성 옵션 (build.gradle > dependencies)

• implemenataion 옵션
  • 직접적인 의존성을 추가할 때 사용
  • 프로젝트 컴파일 시 필요하지만, 외부로 공개 ❌
• runtimeOnly 옵션
  • 런타임 시점에 필요한 라이브러리
• testImplementation 옵션
  • 테스트 코드를 수행할 때 적용할 라이브러리

📖 H2

💡Java 기반의 RDBMS(Database Engine) 즉, DB 엔진 SQL을 사용하고, JDBC로 연결할 수 있는 관계형 데이터베이스 시스템

📌 DB 사용방식 ( H2 )

1️⃣ Server Mode

• 애플리케이션과 상관없는 외부에서 DB엔진 구현
• 애플리케이션 / 데이터가 분리되어 있으므로 서로 영향 ❌
• [H2 Database 엔진 다운로드하기 (배포할때 사용해보자 ^^)] (https://www.h2database.com/html/main.html)

2️⃣ In memory Mode

• 엔진 별도 설치 ❌, 애플리케이션 내부 엔진 사용 ( build.gradle or application.properties 설정)
• 데이터는 애플리케이션 내부 메모리에 저장! ➝ 앱 종료시 DB 날아감

3️⃣ Embedded Mode

• 엔진 별도 설치 ❌, 애플리케이션 내부 엔진 사용 ( build.gradle or application.properties 설정)
• 데이터는 애플리케이션 외부에 저장! ➝ 앱 종료해도 DB 안날아감

📌 실습하기 - Embedded Mode

❶ 파일 설정하기

💡 jbbc:h2:~/test : ~ 은 홈디렉토리, 홈디렉토리의 test에 저장된다

✔️ application.yml

spring:  
    datasource:    
        driver-class-name: org.h2.Driver
        ✅ url: jdbc:h2:mem:{DB 이름} ----> 2️⃣ In-Memory Mode
        ✅ url: jdbc:h2:{DB가 저장될 경로} ----> 3️⃣ Embedded Mode
        username: sa
        password:  

---

✔️ application.properties

# application.properties
spring.datasource.driver-class-name=org.h2.Driver
✅ spring.datasource.url=jdbc:h2:mem:{DB 이름} ----> 2️⃣ In-Memory Mode
✅ spring.datasource.url=jdbc:h2:{DB가 저장될 경로} ----> 3️⃣ Embedded Mode
spring.datasource.username=sa
spring.datasource.password=

❷ 의존성 등록하기

✔️ build.gradle

❸ 콘솔 띄우기

➝ Path 참고해서 콘솔 url 접속

SQL

DDL

create table alter table drop table TRUNCATE TABLE orders; -> 데이터 초기화 ( 테이블 내용 지우기 ) TRUNCATE TABLE products; TRUNCATE TABLE users;

DML

데이터 찾기 select where 등.. order by group by join

데이터 조작하기 insert into update delete from

DCL

트랜젝션 관리

DB 드라이버

애플리케이션 - 데이터베이스 간의 통신을 중개하는 역할

동작 방식

1. 연결 초기화 - 드라이버 연결 요청 수신후 연결 완료
2. SQL 전송 및 실행 - SQL 쿼리를 변환하고 처리
3. 결과 처리 - 결과 수신 후 변환된 결과 전달
4. 연결 종료 - 다음 세션을 위해 시스템 초기화

JDBC 실습

Spring Boot는 다양한 JDBC 드라이버를 지원한다

-spring-boot-starter-jdbc : 스타터 패키지, 주요 의존성, 자동구성 기능이 포함되어 있음 : 코드 간소화, 자동 구성, 예외처리 ( JDBC에서 발생하는 예외 -> Spring 예외체계로 변환)

• JDBC 드라이버 : 자바 애플리케이션에서 데이터베이스에 접근할 수 있도록 하는 API

JDBC Driver

try-with-resources란?

✅ 자동으로 close()를 호출해주는 try 구문이야. (자원 해제)

JDBC에서 Connection, Statement, ResultSet 같은 객체는 반드시 닫아줘야 해. 그런데 실수로 connection.close()를 안 쓰거나, return 전에 빠지면 리소스 누수가 나지.

그래서 Java7부터는 AutoCloseable 인터페이스를 구현한 객체는 try 괄호 안에 넣으면 자동으로 close()해줘!

예제 코드

@SpringBootApplication
public class JdbcApplication {

    public static void main(String[] args) throws SQLException {
        // 어플리케이션 실행 컨텍스트 생성
        SpringApplication.run(JdbcApplication.class, args);

        // ▶️ 데이터베이스 연결
        String url = "jdbc:h2:mem:test";     // ✅in-memory 모드 H2 DB
        String username = "sa";                // 사용자명

        // 🔹 DriverManager.getConnection()
        // - JDBC 드라이버를 통해 DB와 연결
        try (Connection connection = DriverManager.getConnection(url, username, null)) { // ✅ 파라미터로 연결 정보 넣어주기

            try {
                // ▶️ 테이블 생성
                // 🔹 connection.prepareStatement(String sql)
                // - SQL 문을 미리 컴파일된 상태로 준비 
                String creatSql = "CREATE TABLE USERS (id SERIAL, username varchar(255))";
                try (PreparedStatement statement = connection.prepareStatement(creatSql)) {
                    // 🔹 statement.execute()
                    // - 컴파일 된 SQL문을 실행
                    statement.execute();
                }

                // ▶️ 데이터 추가
                String insertSql = "INSERT INTO USERS (username) VALUES ('teasun kim')";
                try (PreparedStatement statement = connection.prepareStatement(insertSql)) {
                    statement.execute();  
                }

                // ▶️ 데이터 조회
                String selectSql = "SELECT * FROM USERS";
                try (PreparedStatement statement = connection.prepareStatement(selectSql)) {
                    // 🔹 statement.executeQuery()
                    // - SELECT 문 실행
                    var rs = statement.executeQuery();

                    // 🔹 rs.next()
                    while (rs.next()) {
                        // 🔹 rs.getInt("컬럼명")
                        // 🔹 rs.getString("컬럼명")
                        System.out.printf("%d, %s", rs.getInt("id"), rs.getString("username"));
                    }
                }
            } catch (SQLException e) {
                // 예외 메시지를 문자열로 비교해 예외 상황을 분기 처리
                if (e.getMessage().equals("ERROR: relation \"account\" already exists")) {
                    System.out.println("USERS 테이블이 이미 존재합니다.");
                } else {
                    // 그 외 예외는 런타임 예외로 감싸서 던짐
                    throw new RuntimeException();
                }
            }
        }
    }
}

• 특징
  • 대상은 객체 (테이블이 아님)
  • 영속성 컨택스트 활용 가능
  • 컴파일 시점에 엔티티-필드타입 확인 후 오류 감소

📖 JPQL 문법

📌 결과 조회

▶️ 타입 정하기

❶ TypeQuery

• 타입이 명확할때 ! (주로 엔티티나 특정 타입이 있을때)
• 주로 사용한다!

  TypedQuery<Tutor> typeQuery1 = em.createQuery("select t from Tutor t", Tutor.class);
  TypedQuery<String> typeQuery2 = em.createQuery("select t.name from Tutor t", String.class);

  ---

  ❷Query

• 반환 타입 명확하지 않을때 ( = 다양한 타입의 데이터 반환)
• Object로 반환하므로 형변환 필요할 수도

  Query query = em.createQuery("select t.name, t.age from Tutor t");

▶️ 결과 조회

❶ getResultList()

• 결과가 하나 이상일 때 사용한다.
• List 반환 (결과가 없다면 빈 List 반환)

  List resultList = em.createQuery("select t from Tutor t").getResultList();

  ---

  ❷ getSingleResult()

• 결과가 딱 하나일때
• 쿼리 뒤에 엔티티 클래스를 명시해준다 (반환타입)

  Tutor singleResult = em.createQuery("select t from Tutor t where t.id = 1L", Tutor.class).getSingleResult();

📌 파라미터 바인딩

동적으로 값을 전달한다, 쿼리 재사용 가능

Tutor wonuk = em.createQuery("select t from Tutor t where t.name = ✅:name", Tutor.class)
                    .setParameter("name", "wonuk")✅파라미터 지정
                    .getSingleResult();
System.out.println("wonuk.getName() = " + wonuk.getName());
System.out.println("wonuk.getAge() = " + wonuk.getAge());

📌 @Embedded / @Embeddedable

▶️ JPA에서 여러 필드를 하나의 값 객체로 묶어 사용하는 어노테이션

✅@Embeddable - 값을 정의하는 쪽. 내장될 클래스 (예: Period, Address) ✅ @Embedded - 값을 사용하는 쪽. 엔티티에 포함시키는 필드 (예: Tutor.period)

▶️ 상황 예시

❶ @Embedded 사용

@Entity
public class Tutor {
>        
        @Id
        @GeneratedValue
        private Long id;
>        
        private String name;
>        
        @Embedded // ✅ Embedded 사용
        private Period period;
>
}

---

❷ @Embeddable 사용

@Embeddable// ✅ Embedded 정의
public class Period {
>  
  @Temporal(TemporalType.DATE) <--- ✅ 날짜 매핑에 사용
  Date startDate;
>  
  @Temporal(TemporalType.Date)
  Date endDate;
>  
  public boolean isWork (Date date) { <--- ✅ 자체 검증 로직
        // startDate <= date <= endDate 확인
      return (startDate == null || !date.before(startDate)) &&
             (endDate == null || !date.after(endDate));
  }
}

---

❸ 데이터 조회

📌 프로젝션(Projection)

▶️ 쿼리에서 어떤 데이터를 가져올 지 선택하는 것 ( select 어떤거 할지? )

▶️ 왜 사용하는가?

• 모든 데이터를 다 가져오는 건 비효율적
• 필요한 필드만 조회하면 성능 최적화 가능
• 네트워크 비용 절감, 조회 속도 향상

❶ Entity 프로젝션

• 엔티티 전체를 통째로 조회하는 방식

• 조회된 객체는 영속성 컨텍스트에 의해 관리된다 (Dirty Checking 가능)

  Tutor tutor = new Tutor("wonuk", 100);
  em.persist(tutor);
  >
  // 영속성 컨텍스트 초기화 → 조회한 tutor는 더 이상 관리되지 않음
  em.flush();
  em.clear();
  >
  // Tutor 엔티티 전체 조회
  List<Tutor> tutorList = em.createQuery("select t from Tutor t", Tutor.class).getResultList();
  Tutor wonuk = tutorList.get(0);
  >
  // 엔티티가 다시 영속성 컨텍스트에 들어와서 변경 감지 가능
  wonuk.setName("wonuk2");

• ** 🧷 연관 엔티티 조회: 묵시적 vs 명시적 JOIN**

  // 묵시적 JOIN → JPQL에서는 작성하지 않았지만 내부적으로 JOIN 발생
  Company company = em.createQuery(
    "select t.company from Tutor t", Company.class
  ).getSingleResult();
  

  // 명시적 JOIN → 쿼리에서 JOIN을 명확히 선언 Company companyV2 = em.createQuery( "select t from Tutor t join t.company", Company.class ).getSingleResult();

  • 💡 묵시적 JOIN은 SQL을 예측하기 어려워 위험함 → 명시적으로 JOIN을 선언하는 것이 좋다.

❷ Embedded 프로젝션

List<Period> periods = em.createQuery(
    "select t.period from Tutor t", Period.class).getResultList();
    >
* `select p from Period p` → ❌ 불가능
* Embedded 객체는 독립적인 엔티티가 아니기 때문

---

✔️ 조건 검색 예시

// Embedded 내부 필드 접근 가능
"select t from Tutor t where t.period.startDate < :today"

✔️ 상속 구조 → 직관적

"select t from Tutor t where t.startDate < :today"
// → 이건 period 없이 바로 접근 가능 (MappedSuperclass의 경우)

❸ Scalar 프로젝션

• 엔티티가 아닌 단일 필드(문자열, 숫자 등) 또는 여러 필드만 조회할 때

List<Object[]> resultList = em.createQuery(
    "select t.name, t.age from Tutor t"
).getResultList();
>
Object[] result = resultList.get(0);
System.out.println("이름: " + result[0]);  // name
System.out.println("나이: " + result[1]);  // age

📌 결과는 Object[] 배열로 리턴되므로, 형변환 필요

• 💡 확장 → DTO 프로젝션

  // DTO에 생성자 필요: public TutorDto(String name, int age)
  List<TutorDto> dtos = em.createQuery(
    "select new com.example.TutorDto(t.name, t.age) from Tutor t", TutorDto.class ).getResultList();

  Scalar 프로젝션을 더 명확하게 사용하고 싶다면 DTO에 직접 매핑하는 방법이 가장 깔끔하고 안전

📌 페이징(Paging)

▶️ JPQL은 기본적으로 LIMIT, OFFSET 같은 SQL 문법을 직접 쓰지 않고 JPA가 제공하는 메서드로 페이징 처리를 한다.

▶️ 사용 메서드

메서드	설명
setFirstResult(int)	조회 시작 위치 (OFFSET)
setMaxResults(int)	가져올 데이터 개수 (LIMIT)

---

List<Tutor> tutorList = em.createQuery(
    "select t from Tutor t order by t.age desc", Tutor.class
)
.setFirstResult(5)     // 6번째 데이터부터 조회 (OFFSET = 5)
.setMaxResults(10)     // 총 10개 조회 (LIMIT = 10)
.getResultList();
>
for (Tutor tutor : tutorList) {
    System.out.println("tutor = " + tutor.getId() + ", " + tutor.getName() + ", " + tutor.getAge());
}

• order by t.age desc → 나이 순서대로 내림차순 정렬 (가장 나이 많은 튜터부터)
• setFirstResult(5) → 6번째 데이터부터 시작
• setMaxResults(10) → 10개 데이터만 조회

📘 fetch join

JPA에서의 N+1 문제를 해결한다

📖 fetch join 사용법

📌 Entity fetch join (N:1, 1:1)

▶️ 지연로딩(LAZY) 설정된 연관 엔티티를 JOIN과 동시에 한 번에 가져오는 방법

String query = "select t from Tutor t join fetch t.company";

❶ Tutor가 Company를 참조하고 있고, ❷ t.getCompany().getName() 로 접근하면 원래는 쿼리 또 날아가야하는데 ❸ fetch join을 쓰면 그 전에 미리 Company까지 같이 가져온다 → 쿼리 한 번으로 둘 다 가져오니까 N+1 문제 해결!

• ✅ 장점: 깔끔하게 한 번에 가져와서 성능 좋음
• ⚠️ 주의: 무조건 다 들고오니까 필요 없을 땐 오히려 과하게 가져올 수도

📌 Collection fetch join

▶️ 한 엔티티가 여러 개를 갖고 있는 컬렉션(예: 회사 → 튜터 목록)을 한 번에 가져오는 방식

String query = "select c from Company c join fetch c.tutorList";

>
❶ Company 하나에 Tutor 여러 명 붙어있으면,
❷ SQL은 Tutor 수만큼 Company가 중복돼서 나온다
→ 근데 JPA는 알아서 같은 Company는 한 번만 만들어준다!

- ✅ **장점**: N+1 문제 없이 Company와 Tutor를 한 번에 다 가져옴
- ⚠️ **단점**: **페이징(setFirstResult, setMaxResults)** 안 됨
→ 전부 다 불러온 다음 자바 메모리에서 잘라버림 (데이터 많으면 위험)

---

## 📌 @BatchSize

▶️ **지연로딩은 유지하면서**, **한 번에 여러 개를 IN 쿼리로 가져오는 방식**

>```java
@BatchSize(size = 100)
@OneToMany(mappedBy = "company")
private List<Tutor> tutorList;

❶ 예를 들어 Company 2개가 있을 때, ❷ 각 Company의 tutorList를 조회하려고 하면 ❸ Tutor를 하나씩 쿼리하는 게 아니라 → Tutor WHERE company_id IN (1, 2) 이런 쿼리로 한 번에!

✅ 장점: 페이징 가능! 쿼리도 줄어듦 ⚠️ 주의: 한 번에 너무 많이 로딩하면 메모리 터질 수도 있으니 size 조절 중요

🌟 JPQL 실습 코드

- 쿼리 예시

❶ Repository의 튜터별 학생 수 메서드

public interface TutorRepository extends JpaRepository<Tutor, Long> {
>
    @Query("select new com.example.springjpql.dto.TutorStudentCountDto(t.name, count(s)) " +
            "from Tutor t join t.students s group by t.name")
    List<TutorStudentCountDto> findTutorStudentCounts();
}

❷ Repository의 학생 조건부 검색 메서드

@Query("select new com.example.springjpql.dto.StudentDto(s.name, s.age) " +
        "from Student s where s.name like %:keyword% " +
        "and s.age >= :minAge and s.age <= :maxAge")
List<StudentDto> findByNameContainingAndAgeBetween(
        @Param("keyword") String keyword,
        @Param("minAge") int minAge,
        @Param("maxAge") int maxAge
);

- 테스트 데이터 추가하기

❶ 프로필 설정하기 (application.yml )

profiles:
  active: dev ✅

❷ 테스트용 데이터 추가 ( config 패키지 )

• @PostConstruct 로 Application 최초 실행 시에만 초기화 하도록 설정
• @Profile("dev") dev 프로필에서만 동작하도록 설정

  @Slf4j
  @Component
  @Profile("dev") ✅
  public class DataInitializer {
  >
    @Autowired
    private TutorRepository tutorRepository;
  >
    @Autowired
    private StudentRepository studentRepository;
  >
    @PostConstruct ✅
    public void init() {
        // Tutor 데이터 초기화
        Tutor tutor1 = new Tutor("tutor1");
        Tutor tutor2 = new Tutor("tutor2");
        Tutor tutor3 = new Tutor("tutor3");
  >
        tutorRepository.save(tutor1);
        tutorRepository.save(tutor2);
        tutorRepository.save(tutor3);
  >
        // Student 데이터 초기화
        for (int i = 0; i < 30; i++) {
            Student student = new Student("student" + i, 20 + i);
            // 튜터를 순차적으로 할당
            if (i % 3 == 0) {
                student.setTutor(tutor1);
            } else if (i % 3 == 1) {
                student.setTutor(tutor2);
            } else {
                student.setTutor(tutor3);
            }
            studentRepository.save(student);
        }
        log.info("===== Test Data Initialized =====");
    }
  }

📖 개요

이번 팀플 과제에서 내가 맡게된 부분은 주문/장바구니 필수단계에는 주문까지 구현이고, 장바구니는 도전 과제이지만 처음부터 우리는 장바구니를 같이 구현하는 것을 목표로 설계했다 !

▶️ 요구사항과 설계 내용 정리

✔️ 주문

• 고객은 메뉴 여러개를 주문할 수 있다
• 사장님은 주문을 수락할 수 있고, 배달 완료까지의 모든 상태를 순서대로 변경한다
• 주문 요청 및 상태 변경
  • 새로운 주문이거나 주문 상태가 변경될 때는 AOP로 로그를 남긴다
  • 로그 내용 - 요청 시각,가게 id,주문 id
• 제약조건
  • 가게의 최소 주문금액을 만족해야 한다
  • 가게의 오픈/마감시간이 지나면 주문할 수 없다

✔️ 장바구니

• 한 가게의 메뉴만 담을 수 있고, 가게가 변경되면 장바구니는 초기화 된다
• 장바구니는 마지막 업데이트 시점으로부터 최대 하루만 유지된다

📖 설계

1️⃣ 연관관계 설정

✔️ 연관관계 비교하기

• 🅰️ / 튜터님

  User 1 : N Cart 1 : 1 Menu 유저는 여러 개의 Cart 항목을 가질 수 있음

  User
  ├─ Cart1 (Menu: 짬뽕, Quantity: 1)
  ├─ Cart2 (Menu: 탕수육, Quantity: 2)
  └─ Cart3 (Menu: 볶음밥, Quantity: 1)

  • 각 Cart는 메뉴 하나만 담고 있음 , 수량은 Cart에 저장
  • 복수의 메뉴를 담고 싶으면? → Cart를 여러 개 만들면 됨

• 🅱️안 / 내가 최초 생각한 연관관계

  User 1 : 1 Cart 1 : N Menu 유저는 Cart 딱 하나만 가짐

  User
  └─ Cart1
       ├─ CartMenu (Menu: 짬뽕, Quantity: 2)
       └─ CartMenu (Menu: 탕수육, Quantity: 1)

  • Cart 안에 메뉴들이 여러 개 담겨 있음
  • "장바구니 하나 안에 메뉴가 여러 개, 거기에 수량까지 포함된 테이블"이 들어있는 구조

✔️ A안의 장점

1. 데이터 정규화가 깔끔함

• Cart가 메뉴 항목 + 수량으로 분리돼 있음 → Cart만 보면 어떤 메뉴가 몇 개 담겼는지 쉽게 알 수 있음 → 메뉴 + 수량 단위로 계산, 조회, 삭제가 아주 편해!

2. 주문 생성 로직이 깔끔해짐

• 이 구조에선 같은 주문 ID로 여러 Cart를 묶기 만 하면 끝 → 주문 생성을 위해 메뉴 리스트 분해가 필요 없음

3. 확장성이 좋음

• 나중에 옵션, 리뷰, 쿠폰 등 기능 확장할 때도 편리할 것 → CartItem 단위로 복잡한 로직을 분리할 수 있음

✔️ B안의 장점

1. Cart가 한 유저당 1개로 고정됨 → 메뉴 1개만 빼려면 List<Menu>에서 꺼내서 수량 갱신하고 다시 저장해야 함

2. Cart가 메뉴 리스트를 직접 갖고 있음 → 중간 테이블 필요 → 메뉴와 수량을 따로 저장하려면 중간 엔티티가 필요해짐

3. 비즈니스 로직이 엉켜버릴 수 있음 → 장바구니에서 메뉴 수량 늘리기, 줄이기, 삭제하기 모두 복잡한 로직을 요구함

🌟 이해한 내용 요약 정리

A안 - cart1, cart2, cart3은 각각 짬뽕 카트, 탕수육 카트, 볶음밥 카트 B안 - cart1, cart2, cart3은 각각 수린이 카트, 광수 카트, 영식이 카트

수린이 카트에 탕수육, 짬뽕을 담을 수는 있는데 각각의 수량을 정하려면 엔티티가 하나 더 있어서 그 엔티티에 (메뉴이름,메뉴수량) 을 담아서 구현해야한다

---

✔️ A안의 Cart1,2,3은 메뉴 하나씩 담긴 독립적인 항목
✔️ B안은 Cart1이 유저 전체 장바구니 역할, 안에 메뉴와 수량 따로 들어가야 해서 중간 엔티티 필요
✔️ 그래서 실무에서는 A안을 쓰고, 필요 시 CartGroup, Order, CartItem을 붙여서 확장하는 방식 사용

2️⃣ 응답

• 가게의 최소주문금액을 충족했을 때만 주문이 가능하다는 조건을 보고 더 생각을 해보니 사용자 입장에서는 장바구니에 담을때마다 현재 가격 + 주문이 가능한지 나와야 하지 않을까?

✔️ API 명세서 수정

✔️ 상황별 응답 Dto 생성

❶ 장바구니 추가시

• 방금 추가한 카트 ( 메뉴 / 수량 )
• 유저의 모든 카트의 메뉴 총합 + 유저의 모든카트 현재 금액 + 주문가능여부

❷ 장바구니 전체 조회 / 장바구니 수정시

• 유저의 모든카트 내용 ( 메뉴 / 수량 ) + 현재 금액 + 주문가능여부

🌟 Dto에서 카트 금액을 구해서 서비스단의 코드를 줄일 수 있을 것 같다...!

🤯 나의 회고

• 역시 협업에서 가장 중요한 것은 설계라는 걸 다시 한번 깨달았다..^^ 협업에서 설계단계가 70% 이상이라는 성규튜터님의 말씀이 설계단계가 다 끝나고 나니 한 번 더 생각난다..!
• dto에서 전부 가격까지 계산을 해버리게 코드를 구성했는데 이게 맞나 싶지만 stream을 활용해 가격을 다 계산해버리니까 서비스단 코드가 확줄어서 뿌듯하다~!
• 오더까지 쭉 구현해보자~!

Spring Mvc에서 Controller에 도달하기 전이나 후의 흐름을 제어할 수 있다

• HandlerInterceptor를 implements 받는다

• 컨트롤러-디스패쳐서블릿 사이에 위치해서 특정 컨트롤러의 요청과 응답을 컨트롤

• WebMvcConfigurer에 등록해서 사용한다

  ---

  📌 메서드

  ✔️ preHandle()

• 호출시점 : 컨트롤러 호출 전

• 반환 타입이 boolean - true 다음 인터셉터 or 컨트롤러 호출 / false 작업 중단

✔️ postHandle()

• 호출시점 : 컨트롤러 호출 후
• (결과값이 반환된 이후에 실행되기에 )예외 발생시 실행 ❌

✔️ afterCompletion()

• 호출시점 : 뷰가 랜더링된 이후
• 예외 발생 여부와 무관하게 클라이언트에게 응답 전달시 실행

▶️ 사용예시

▪️ AdminInterceptor

• HandlerInterceptor의 구현 클래스 생성
• API에 접근한 시간과 요청 URI를 로그에 남기도록 했다

▪️ Webconfig

• 등록해준뒤에 uri 범위를 지정했다 ( 해당 예제에서는 admin 접근시 로깅하라는 요구사항이 있었음 )

📖 AOP

애플리케이션의 공통기능을 분리하고 모듈화한다 (로깅, 트랜젝션 관리, 보안 등)

참고링크

📌 Aspect

• 공통 관심 사항을 정의하는 모듈

    public AdminLogAspect(ObjectMapper objectMapper) {
        this.objectMapper = objectMapper;
    }

📌 Advice

• Aspect의 동작을 정의하는 부분

  이름	동작 시점
  @Before	메서드 실행 전 동작추가
  @AfterReturning	메서드 정상종료 후 동작추가
  @AfterThrowing	메서드 예외발생 시 동작추가
  @After	메서드가 실행 후 무조건 동작추가 (성공/예외 발생 여부와 무관)
  @Around	메서드 실행 전후 모두 동작추가 (가장 강력한 유형)

✔️ 예시

 @Around("all()")
    public Object logging (ProceedingJoinPoint pjp) throws Throwable {
    ...

📌 Pointcut

• 어떤 메서드가 어떤 Advice를 받을지 결정하는 표현식 ⇢ 정규식으로 작성 ( 패키지, 특정 클래스의 메서드 등으로 작성 가능 )

✔️ 예시

    @Pointcut("execution(* org.example.expert.domain.user.controller.UserAdminController.*(..))")
    public void adminUser() {}

📌 Join Point

• 프로그램 실행 중 특정한 시점을 의미, Advice가 언제 적용될 지
• JoinPoint: 메서드 실행 전까지만 접근 가능 (@Before, @After 등에서 사용)
• ProceedingJoinPoint: 메서드 실행 자체를 제어할 수 있음 (@Around에서만 사용)

📌 Weaving

• Aspect를 대상코드에 적용하는 프로세스를 의미
• 컴파일 시점, 클래스 로딩 시점, 런타임 시점에 Weaving을 수행할 수 있음

일단 블로그 보고 무난하게 구현,,

포인트 컷으로 적용할 컨트롤러를 정규식!!으로 적어준다~ 첨엔 코멘트 유저 나눴다가 around로 또 범위 정해주는데~~ 걍 all로 합침

문제는 요청 본문과 응답 본문을 json 형태로 가져와서 로깅하라는 요구사항이 있는데..

문제점

다른 정보들 처럼 그냥 request.get~ 으로 불러올수있을거라고 생각해서 메서드를 찾아보았으나 tomcat에서 한번 read한 body는 두번 읽을 수가 없다고 한다 내부에서 요청 파라미터를 바인딩할때 한번 리드 하므로,, 내가 메서드 실행 전에 채가서 read 해버리면 바인딩이 불가한 상황! 그럼 어떻게 하냐? 읽는 메서드도 내가 따로 만들어야한다 이말이다 한번밖에 못읽어? 그럼 직접 만들어 읽어~~ ㅎ.. 진짜 여기서부터 모르겠는데 1.HttpServletRequestWrapper를 상속받아 메서드를 오버라이딩 하면된다 2.ContentCachingRequestWrapper를 사용한다 -> 요걸 선택! 1번을 정리한 글이 어마무시했기때문

으아아아아아악

ContentCachingRequestWrapper를 필터로 만든다 왜 필터로 만드냐? 걍 클래스로 만들면 안댐? 안댐 톰캣이 읽을려고 가져가기 전에 감싸놔야하거든~

암튼 필터를 만들고 필터를 등록한다 적용범위는 걍 전체로 함 어차피 aop에서 적용범위가 정해져있음(포인트컷) +언제 다른 메서드의 요청 본문을 로깅해야할지 모르므로~

그리고 사용을 하면되는데 일단 블로그에서 if로 instanceof로 확인하길래 따라하고 이유를 찾아보니 내가불러온 request가 아아까 감싸뒀던!! 걔가 맞는지 검증하는 거라는데 그래서 검증을 꼭 해야하냐고? 안해밨다 모른다 !! 급하니까 하란대로 했다 암튼간에 스트링으로 변환하면 끝~

응답 본문은 걍 objectMapper로 긁어오면 된다~ 얘는 요청이 아니라 응답이라서 톰캣 이새기가 읽을일이 없기 때문이다..

📖 과제 개요

이번 개인 과제는 예제를 가져와 코드를 개선하고, 테스트 코드를 작성해보고, 리팩터링 해보는 과제였다

✔️ 개발 환경

• Java: 17
• JDK: 17.0.1
• IDE: IntelliJ
• Spring Frame Work : 3.4.4
• API 테스트 도구 : postman

🌟 Git Hub 링크

📖 코드 리뷰

📌 [Lv 1] 코드 개선하기

✅ 1. Early Return

    @Transactional
    public SignupResponse signup(SignupRequest signupRequest) {

   if (userRepository.existsByEmail(signupRequest.getEmail())) {
        throw new InvalidRequestException("이미 존재하는 이메일입니다.");
    } // 💡 수정한 위치

    String encodedPassword = passwordEncoder.encode(signupRequest.getPassword());

    //if (userRepository.existsByEmail(signupRequest.getEmail())) {
    //   throw new InvalidRequestException("이미 존재하는 이메일입니다.");
    //} 기존 위치

    UserRole userRole = UserRole.of(signupRequest.getUserRole());

    ...

✔️ 배운점

• 불필요한 로직 실행을 줄이고, 코드 가독성을 높일 수 있다
• 특히 passwordEncoder.encode()와 같은 큰 연산을 줄일 수 있어 효율적이다

✅ 2. 불필요한 if-else문 줄여 리팩토링

if (!HttpStatus.OK.equals(responseEntity.getStatusCode())) {
    throw new ServerException("날씨 데이터를 가져오는데 실패했습니다. 상태 코드: " + responseEntity.getStatusCode());

if (weatherArray == null || weatherArray.length == 0) { throw new ServerException("날씨 데이터가 없습니다."); } }

✔️ 배운점

• 불필요한 else나 중첩을 줄이자

✅ 3. Validation

UserService 클래스

if (userChangePasswordRequest.getNewPassword().length() < 8 ||
        !userChangePasswordRequest.getNewPassword().matches(".*\\d.*") ||
        !userChangePasswordRequest.getNewPassword().matches(".*[A-Z].*")) {
    throw new InvalidRequestException("새 비밀번호는 8자 이상이어야 하고, 숫자와 대문자를 포함해야 합니다.");
}

UserChangePasswordRequest 클래스

 @NotBlank
    @Pattern(regexp = "^(?=.*[0-9])(?=.*[A-Z])[A-Za-z\\d]{9,}$", message = "새 비밀번호는 8자 이상이어야 하고, 숫자와 대문자를 포함해야 합니다.")
    private String newPassword;
>```

#### ✔️ 배운점
- 정규식 쓰는 것이 어려웠다. 기존에 있는 클래스,메서드들을 잘 활용하자


<br>

---

## 📌 [Lv 2] N+1 문제
### ✅ N+1을 방지하는 기능을 찾고, @EntityGraph 기반 구현으로 수정


>|기존|![](https://velog.velcdn.com/images/luv_lyn/post/0afbc5b3-7dce-429f-821f-34c7a9b266aa/image.png)`fetch join`을 사용해 연관된 데이터를 **즉시 로딩**|
|:---:|:---:|
|**수정**|![](https://velog.velcdn.com/images/luv_lyn/post/76bf29fa-8c9d-4a3d-a9d5-9acc55f8eb6f/image.png)**JPA의 `@EntityGraph`로 리팩토링**|

---
## 📌 [Lv 3] 테스트코드 연습
### ✅ 1. 성공 케이스

> 
#### ✔️ 문제
>
<img src='https://velog.velcdn.com/images/luv_lyn/post/06cfbe69-27cc-4d64-9b8a-103287611c2e/image.png' width=60%>
<img src='https://velog.velcdn.com/images/luv_lyn/post/6b7425e9-9925-4ae5-90b5-daa4f81ac74a/image.png' width=50%> 
>
> ---
>
#### ✔️ 해결
>
![](https://velog.velcdn.com/images/luv_lyn/post/62043888-0eda-42d0-b6be-5e089c961276/image.png)
>

- [`passwordEncoder.matches()`](https://hs-backend.tistory.com/207)
- 해싱 알고리즘을 비교할때는 비교 대상이 앞에, 해싱된 암호가 뒤에 와야한다



<br>



### ✅ 2. 예외 처리 성공 케이스

>| | ✔️ 문제 | ✔️ 해결 |
|---|---|---|
|1|<img src='https://velog.velcdn.com/images/luv_lyn/post/e5ec0068-41dd-43c6-b798-7d16fe0b1475/image.png' width=100%> |<img src='https://velog.velcdn.com/images/luv_lyn/post/b37af196-a2d5-4efd-82f5-fe3709985be0/image.png' width=100%> | |
|2|<img src='https://velog.velcdn.com/images/luv_lyn/post/78bff037-8e4f-4814-869f-b4ed616bd322/image.png' width=100%> |<img src='https://velog.velcdn.com/images/luv_lyn/post/0e9ca091-8e57-458c-acb1-57e79c3f766b/image.png' width=100%> | |
|3|<img src='https://velog.velcdn.com/images/luv_lyn/post/11e49451-37fc-4214-bb3f-a638231b3c64/image.png' width=100%> |<img src='https://velog.velcdn.com/images/luv_lyn/post/1f5d7515-fe8f-467d-85d8-5202f5fce804/image.png' width=100%>|

- 알맞은 `Exception`으로 변경해 테스트 코드 실행시 성공하도록 수정했다

---

## 📌 Level 4. API 로깅

> ### [Interceptor와 AOP를 활용한 API 로깅](/@luv_lyn/Interceptor와-AOP를-활용한-API-로깅) 
~~양이 방대해서 따로 썼다..🤯~~



### ✅ Interceptor 사용
- **Interceptor를 사용해 요청 정보 사전 처리**
- 인증 성공 시, **요청 시각과 URL을 로깅**
- **어드민 인증 여부 확인**

### ✔️ 작성한 코드

![](https://velog.velcdn.com/images/luv_lyn/post/e36b268f-fa31-4c63-84c2-f5ccb29435fe/image.png)

![](https://velog.velcdn.com/images/luv_lyn/post/e8d43bf0-81f8-442b-8ac5-8be640ebc7d6/image.png)



<br>


### ✅ AOP 사용
- `@Around`를 사용해 **어드민 API 실행 전후에 로깅**
- 로깅 내용: 요청한 사용자 ID, API 요청 시각, 요청 URL, 요청 본문 (`RequestBody`), 응답 본문 (`ResponseBody`)
- 요청/응답 바디는 **JSON 형태로 기록**
- `Logger` 클래스 활용

![](https://velog.velcdn.com/images/luv_lyn/post/0e3e4dc5-9ff4-4746-802d-e08d483f6b3a/image.png)

![](https://velog.velcdn.com/images/luv_lyn/post/65c5aaa8-9aa5-4131-a937-7090a1d8f8bf/image.png)


>#### ✔️ 어려웠던점 + 배운점
>
1. **본문을 JSON으로 불러올 것**
   - `request.getInputStream()` 등으로는 한 번만 읽을 수 있음
   - **Tomcat이 먼저 읽으면 바디는 null**로 나옴
   - 해결책: `ContentCachingRequestWrapper`를 필터로 감싸 요청 바디를 캐싱
>
>
2. **왜 필터를 만들어야 하는가?**
   - AOP나 일반 클래스에서는 이미 **Tomcat이 읽은 뒤라 감싸도 무용지물**
   - 필터로 **가장 먼저 요청을 가로채고 감싸야** 이후 AOP에서 꺼내 읽을 수 있음
   - 그래서 `OncePerRequestFilter`를 구현한 필터로 직접 감쌈
>
>
3. **캐싱해서 감싸져 있는지 `instanceof`로 확인**
   - `request`가 내가 감싼 `ContentCachingRequestWrapper` 객체인지 체크해야 함
   - 그렇지 않으면 `getContentAsByteArray()` 호출 자체가 불가능
   - `instanceof` 검사 후 → 바이트 배열 → 문자열 변환 → 로깅

---

# 📖 나의 회고

- 필수단계만 착실히 하던 나에게 쉬어가는 느낌의 이번 필수 단계들..
덕분에 시간이 남아서 도전단계까지 해보게 되었는데..! 정말 오래 걸렸다..^^
- 일단 다른 사람이 작성한 코드를 보는게 얼마나 힘든지 깨달았다.
지금 강의 수준에 맞춰 작성한 코드를 주신걸 텐데도 내가 작성한게 아니다보니 어려웠다
- **API 명세서의 중요성**을 깨달았다
레벨 4 구현을 위해 테스트 코드가 아닌 어플리케이션 전체를 실행하는데..
요청시 뭐가 들어가야하는지 Path가 뭔지 컨트롤러 DTO 다 눌러보고 하나씩 확인하며 테스트했다
나도 이런데 정말 엔지니어가 아닌 팀과 협업해야 한다면? API 명세서는 상세할 수록 좋은거구나~
- **AOP**를 알게되고 재밌어서(?) 홀린 듯 블로그를 뒤지며 따라해봤다..
모든곳에 공통으로 적용해야할 작업이라던지 이런 부분들을 내가 커스텀해서 사용할 수 있을 것 같다
- 이번에도 **시간**을 잘 분배하지 못했다. 내가 게으르고 느린걸까 아님 할일이 너무 많은걸까?
여기까지 오니 중간에 하차하신 분들이 꽤 보이는데.. 잠깐씩 부럽기도 했다
이런 생각하지 않도록 꾸준하게 열심히 하자 !

• 관계 종류: @ManyToOne, @OneToMany, @OneToOne, @ManyToMany
• 방향: 단방향 / 양방향 (mappedBy 사용 시 비주인)
• 연관관계의 주인: 외래키(FK)를 가진 쪽 (@JoinColumn 선언됨)

📌 1:N 연관관계 (@OneToMany)

✔️ 단방향

• 한 엔티티가 @OneToMany를 통해 여러 엔티티와 관계를 맺는 경우
• 주인은 1, 비주인의 리스트를 컬렉션으로 보유해야 함
• 실제 FK는 주인 테이블에 있어야 하므로, DB 설계상 부자연스럽고 update 쿼리 추가 발생
• @JoinColumn으로 외래키 컬럼 지정 가능
• 유지보수, 성능 이슈로 실무에서는 잘 사용하지 않음

✔️ 양방향

• 하나의 엔티티가 다른 엔티티와 관계를 맺고 그 반대 방향에서도 서로 참조 가능
• 필요한 경우 insertable = false, updatable = false로 읽기 전용 설정 가능

@ManyToOne
@JoinColumn(name = "company_id", insertable = false, updatable = false)
private Company company;

📌 1:1 연관관계 (@OneToOne)

✔️ 단방향 (지원 ❌)

• 외래키 주인 선택 가능
• JPA에서 지원하지 않는다

✔️ 양방향

• 외래 키가 있는 곳이 연관관계의 주인 (UNIQUE 사용 ❌)

  	장점	단점
  주 테이블	주테이블만 조회해도 대상 테이블을 조회할 수 있다	null 허용 (대상 테이블 값이 없을때) 삭제 시 외래 키 값 처리필요
  대상 테이블	연관관계 변경시에도 테이블 구조 유지	지연로딩을 설정해도 즉시 로딩

📌 N:M 연관관계 (ManyToMany)

• @ManyToMany로 설정 가능하지만 실무에서는 지양
  • 중간 테이블이 숨겨짐
  • 추가 컬럼(ex. level, license 등) 넣을 수 없음
  • 복잡한 쿼리, 제약 조건 관리 어려움

✔️ 단방향 / 양방향

• @ManyToMany는 단방향도 가능, 필요하면 양방향으로도 설정 가능 (mappedBy 사용)
• 실무에서는 중간 테이블을 별도 Entity로 만들어 @OneToMany - @ManyToOne으로 분리하여 매핑

🌟 연관관계 비교하기

연관관계	추천	설명
1:N 단방향	❌ 비추천	FK가 자식에 있는데 부모가 관리하는 구조 → 비효율적
N:1 양방향	✅ 추천	객체-DB 일관성 유지, 가장 자연스러운 구조
1:1	✅ 조건부 추천	상황에 따라 단방향 또는 양방향 선택 (FK 위치 고려)
N:M	❌ 비추천	중간 테이블을 별도 엔티티로 분리하는 방식 추천

📖 JPA 테이블 상속 전략

관계형 데이터베이스의 테이블에는 상속관계가 없지만 JPA를 활용해 상속처럼 사용할 수 있다!

✅ 1. SINGLE_TABLE 전략 (default)

▶️ 사용법

• @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
• 부모 클래스 :@DiscriminatorColumn(name = "dtype") ← 생략 가능
• 자식 클래스 : @DiscriminatorValue("원하는구분값")

📌 특징

• 하나의 테이블에 모든 자식 클래스의 정보를 저장 ( 객체 지향적인 개발에 어울림 )
• @DiscriminatorColumn으로 구분 ( 선언하지 않아도 DTYPE으로 컬럼 생성)
• 단순하고 확장가능성이 없는 경우 사용

📌 장단점

▪️ 사용 예시

✔️ 엔티티 코드

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) ✅
@DiscriminatorColumn(name = "dtype") ✅
public abstract class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
@DiscriminatorValue("B") ✅
public class Book extends Item {
    private String author;
}

@Entity
@DiscriminatorValue("M") ✅
public class Movie extends Item {
    private String director;
}

✔️ 실행 코드

Item book = new Book();
book.setName("JPA Book");
((Book) book).setAuthor("수린");

em.persist(book); ✅

✔️ 결과 테이블

item

✅ 2. JOINED 전략

▶️ 사용법

• @Inheritance(strategy = InheritanceType.JOINED)
• 부모 클래스 :@DiscriminatorColumn(name = "dtype") ← 생략 불가
• 자식 클래스 : @DiscriminatorValue("원하는구분값")

📌 특징

• 부모, 자식 각각 테이블 생성
• JOIN을 통해 조회
• 비즈니스적으로 복잡한 경우 사용 ( 객체 지향적인 개발에 어울림 )

📌 장단점

▪️ 사용예시

✔️ 엔티티 코드

@Entity
@Inheritance(strategy = InheritanceType.JOINED) ✅
@DiscriminatorColumn(name = "dtype") ✅
public abstract class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
@DiscriminatorValue("B") ✅
public class Book extends Item {
    private String author;
}

✔️ 실행 코드

Book book = new Book();
book.setName("JPA Book");
book.setAuthor("수린");

em.persist(book); ✅

✔️ 결과 테이블

item

book

✅ 3. TABLE_PER_CLASS 전략 (사용 ❌)

▶️ 사용법

• @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

• ❌@DiscriminatorColumn, @DiscriminatorValue 사용 안 함

📌 특징

• 부모 테이블 없이 자식마다 테이블 개별 생성
• 자식끼리도 완전 독립
• 부모 클래스 대신, 추상 클래스 사용해야 함
• ❌GenerationType.IDENTIFY 사용 불가

📌 장단점 (사용하지 않는 것 권장)

▪️ 사용 예시

✔️ 엔티티 코드

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) ✅
public abstract class Item {
    @Id @GeneratedValue
    private Long id;
    private String name;
}

@Entity
public class Book extends Item {
    private String author;
}

✔️ 실행 코드

Book book = new Book();
book.setName("JPA Book");
book.setAuthor("수린");

em.persist(book); ✅

✔️ 결과 테이블

book

💡 item 테이블은 없음! Book, Movie 각각 독립 테이블로 생성됨.

🌟 테이블 전략 @Annotation 정리

• @Inheritance(strategy = InheritanceType.${전략})
  1. JOINED : 조인
  2. SINGLE_TABLE : 단일 테이블(Default)
  3. TABLE_PER_CLASS : 구현 클래스마다 테이블

• @DiscriminatorColumn(name = "dtype")
  • dtype 컬럼을 생성함 (관례)
  • 이름 변경 가능
  • 기본 값: DTYPE

• @DiscriminatorValue("${값}")
  • dtype 값 지정
  • 기본 값: 클래스 이름

📖 Proxy

em.getReference()는 프록시 객체를 반환

• 지연로딩을 지원하기 위해 대리 객체를 사용
• 실제 엔티티 생성, DB 조회하지 않고도 참조할 수 있음
• target : 실제 객체의 참조값을 보관 (== 로는 비교 불가, instanceof 사용)

📌 em.getReference()

Tutor proxyTutor = em.getReference(Tutor.class, tutor.getId()); ✅ 프록시 객체 생성 (실제 객체의 참조값만 기억)
System.out.println("proxyTutor.getName() = " + proxyTutor.getName()); ✅ 필드 접근 후 조회 SQL 실행 (초기화)

• em.getReference()는 프록시 객체를 생성
• 프록시 객체 생성 후 최초 사용시(엔티티에 접근시)에 한번만 초기화
• 다만, 이미 영속성 컨텍스트에 해당 Entity가 있으면 프록시 생성하지 않고 그 객체 그대로 반환

✔️ 🆚 영속성 컨텍스트

• 영속성 컨텍스트 = JPA가 관리 중인 모든 엔티티의 저장소 (1차 캐시)
• 프록시 = getReference()로 등록된, 아직 초기화되지 않은 객체(껍데기)
• 영속성 컨텍스트는 프록시를 포함하는 상위 개념

✔️ 관련 예외 - LazyInitalizationException

• 프록시 객체를 생성 후, detach했거나, 프록시 객체를 생성하지 않고 객체에 접근하고자 했을때!
• 프록시 객체가 없다 or 영속상태가 아니다!

📌 em.find()와 비교

🌟 지연로딩, 즉시로딩 정리

지연로딩	즉시로딩
fetch = FetchType.LAZY	fetch = FetchType.EAGER
proxy 객체를 조회	proxy 조회 ❌, 연관된 객체 한번에 조회
연관된 객체를 매번 조회하는게 낭비인 경우	연관된 객체를 매번 함께 조회하는 것이 효율적인 경우

📖 영속성 전이

📌 Cascade

    @OneToMany(mappedBy = "category", cascade = CascadeType.ALL) 
                                      🔼 카테고리-프로덕트 리스트 간의 영속성 전이 설정함
    private List<Product> productList = new ArrayList<>();

• 특정 엔티티를 가지고 작업할 때, 연관된 엔티티에도 동일한 작업을 자동으로 하게 설정
• 지연로딩, 즉시로딩과는 무관
• @OneToMany가 선언된 쪽 = 부모 쪽에 선언

📌 CasecadeType별 의미

▶️ 고아 객체

• 부모 엔티티와의 관계가 끊긴 자식 엔티티

✔️ orphanRemoval

• 부모-자식 관계가 끊긴 자식 객체를 DB에서 자동으로 삭제할지 설정

• @OneToMany가 선언된 쪽 = 부모에 선언

  false (기본값)	true
  자식은 DB에 그대로 남음 (❗수동 삭제 필요)	자식은 DELETE 쿼리 발생, DB에서도 제거됨

▪️ 엔티티 코드

@Entity
@Table(name = "category")
public class Category {

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

    private String name;

    @OneToMany(mappedBy = "category", cascade = CascadeType.ALL, orphanRemoval = true) ✅
    private List<Product> productList = new ArrayList<>();

    public Category() {
    }

    ...

    public void addProduct(Product product) {
        productList.add(product);
        product.setCategory(this); // 연관관계 주인 설정을 메서드로!
    }
}

▪️ 실행 코드

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

        ...

        try {
            // 1. 부모 생성
            Category category = new Category("food");

            // 2. 자식 생성 (아직 연관관계 X)
            Product product1 = new Product("pizza");
            Product product2 = new Product("kimchi");

            // 3. 연관관계 설정 (addProduct가 양방향 연관관계 주입)
            category.addProduct(product1);
            category.addProduct(product2);

            // 4. 부모만 persist했지만, cascade 덕분에 자식도 자동 persist됨
            em.persist(category); // cascade = ALL

            // 5. DB에 반영 + 영속성 컨텍스트 비움
            em.flush(); // INSERT 실행
            em.clear(); // 1차 캐시 초기화

            // 6. 다시 부모 조회
            Category findCategory = em.find(Category.class, category.getId());

            // 7. 자식을 컬렉션에서 제거!
            findCategory.getProductList().remove(0);
            // ✅ orphanRemoval = true 이므로,
            // 여기서 "자식 1개가 부모에서 제거됐네 → 고아 객체!" 라고 판단
            // → 트랜잭션 커밋 시 DELETE 쿼리 날림! 🔥

            transaction.commit(); // ✅ 여기서 자식 1개 DELETE 쿼리 발생

            ...

    }
}

🌟 영속성 삭제 전이 🆚 고아 객체 제거

항목	CascadeType.Remove	orphanRemoval=true
목적	부모 객체 삭제시 자식 객체도 삭제	부모가 없어진 자식 객체는 자동 삭제
작동 시점	부모가 remove 될 때	부모 컬렉션에서 자식을 제거할 때 (관계 끊길 때)
사용 조건	부모-자식 연관관계 + cascade 설정	부모-자식 연관관계만 있어도 가능 (단독 사용 가능 ✅)

📦** HttpMessageConverter**

기존 구조의 view resolver 가 화면을 보여주는 대신, http 메세지를 보여줌

📖 HttpMessageConverter의 구조

• 요청시 ⇢ ArgumentResolver 사용 : @RequestBody, HttpEntity<>, RequestEntity<>

• 응답시 ⇢ ReturnValueHandler 사용 : @ResponseBody, HttpEntity<>, ResponseEntity<>

  💡 구조상 양방향으로 (요청, 응답) 전부 작동한다

  
  

📌 우선순위

▶️ Byte ⇢ String ⇢ JSON

• 요청이나 응답을 변환할때 어떤 Media Type인지 확인
• 순서대로 검사해서 가능한 게 있으면 그걸로 처리하고 나머지는 무시함

📌 동작 흐름

요청

• 1️⃣ RequestBody나 파라미터로 바인딩
• 2️⃣ canRead()로 데이터 타입을 조회, Content-Type 헤더의 미디어타입 지원여부 확인
• 3️⃣ read()로 객체로 변환

응답

• 1️⃣ 컨트롤러가 @ResponseBody나 HttpEntity<> 리턴함
• 2️⃣ canWrite()로 데이터 타입을 조회, Accept 헤더의 미디어타입 지원여부 확인
• 3️⃣ write() 로 응답메세지 바디에 직접 데이터 입력

📥 ArgumentResolver (요청)

🌟 컨트롤러 메서드의 파라미터를 자동으로 바인딩해주는 인터페이스

• Spring MVC 구조에서 요청이 컨트롤러로 가기 전 RequestMappingHandlerAdapter가 호출함
• Controller가 필요한 파라미터 값을 생성함
• 값이 준비되면 실제 컨트롤러를 호출한다

📍 실제 클래스 이름 : HandlerMethodArgumentResolver

✔️ ArgumentResolver의 종류

📤 ReturnValueHandler (응답)

🌟 컨트롤러 메서드가 반환하는 값을 HTTP 응답으로 변환하는 인터페이스

• ModelAndView, @ResponseBody, HttpEntity<> 등
• 예를 들어, 컨트롤러에서 String 리턴해도 문자 그대로가 아니라 View 이름임을 인식함

📍 실제 클래스 이름 : HandlerMethodReturnValueHandler

✔️ ReturnValueHandler의 종류

• 인터페이스이므로 확장가능, 구현체 많음

💡 요청과 응답 모두에서 사용되는 클래스

▶️ArgumentResolver + ReturnValueHandler를 둘다 구현한 클래스

📦 Converter, Fomatter

⚙️ WebMvcConfigurer

설정을 통해 Converter, Formatter를 추가할 수 있다

• 커스텀 Converter, Formatter, HttpMessageConverter 등을 등록할 때 오버라이딩해서 사용
• 속에 @Configuration 도 있음 ⇢ @Component를 포함 ⇢ Spring Bean으로 등록

📖 Converter

객체의 타입을 서로 변환할때

• HttpServletRequest 기본적으로 요청 파라미터는 문자열로 처리가 되기 때문에 숫자로 변환하고 싶다면, 하나씩 직접변환해줘야한다

  @Slf4j
   @RestController
   public class TypeConverterController {
  
       @GetMapping("/param")
       public void param(HttpServletRequest request) {
  
           // 조회시 : String
           String stringExample = request.getParameter("example");
  
           // ✅Integer로 Type 변환
           Integer integerExample = Integer.valueOf(stringExample);
           log.info("integerExample = {}", integerExample);
  
       }
     }

• @RequestParam 변환 안거쳐도 알아서 나온다~~ (바인딩될 타입을 정해놨음) 요걸 누군가 알아서 타입을 자동으로 변환해준다! 이게 타입 컨버터??

  @GetMapping("/v2/param")
  public void paramV2(@RequestParam Integer example) {
        // Integer 타입으로 바인딩
    log.info("example = {}", example);
  }

📌 Converter Interface

특정타입을 다른 타입으로 변환할때 사용하는 인터페이스

• 새로운 타입의 변환

  • localhost:8080/type-converter?person=wonuk:120
  • 입력받은 문자열 데이터를 Person 객체로 변환

  public class Person {
    private String name;
    private String age;
  }

  • wonuk:120 → TypeConverter → name: wonuk , age : 10 (개월수를 나이로)
  • 이럴때 컨버터 인터페이스 사용!

• 스프링이 제공하는 인터페이스이므로 implements해서 컨버터로 등록하면 된다
• 변환하고자 하는 타입에 맞춰서 Type Converter를 구현하고 등록하면 된다

📌 Converter 사용하기

⚠️ 주의 : 같은 이름을 가진 interface가 많으니 주의 org.springframework.core.convert.converter

• 1️⃣ Converter implements 하기
• 2️⃣ Converter를 열고
  • S : 변환할 소스
  • T : 변환할 타입

✔️ 예시

❶ String → Integer

@Slf4j
public class StringToIntegerConverter implements Converter<String, Integer> {

    @Override
    public Integer convert(String source) {
        log.info("source = {}", source);
        // 검증
        return Integer.valueOf(source);
    }

 }

❷ Integer → String

@Slf4j
public class IntegerToStringConverter implements Converter<Integer, String> {

    @Override
    public String convert(Integer source) {
        log.info("source = {}", source);
        return String.valueOf(source);
    }
}

❸ String → Person

(요청예시 : localhost:8080/type-converter?person=wonuk:1200)

@Getter
public class Person {

        // 이름
        private String name;
        // 나이
        private int age;

        public Person(String name, int age) {
            this.name = name;
            this.age = age;
        }

}

------------------

public class StringToPersonConverter implements Converter<String, Person> {
        // source = "wonuk:1200"
        @Override
        public Person convert(String source) {
            // ':' 를 구분자로 나누어 배열로 만든다.
            String[] parts = source.split(":");

            // 첫번째 배열은 이름이다. -> wonuk
        String name = parts[0];
        // 두번째 배열은 개월수이다. -> 1200
        int months = Integer.parseInt(parts[1]);

            // 개월수 나누기 12로 나이를 구하는 로직 (12개월 단위만 고려)
            int age = months / 12;

            return new Person(name, age);
        }
}

------------------

public class PersonToStringConverter implements Converter<Person, String> {

        @Override
        public String convert(Person source) {
                // 이름
                String name = source.getName();
                // 개월수
                int months = source.getAge * 12;
                // "wonuk:1200"
                return name + ":" + months;
        }

}
------------------

PersonToStringConverter converter = new PersonToStringConverter();
String source = "wonuk:1200";
converter.convert(source);

📌 Spring이 제공하는 Converter

1. Converter

   • 기본적인 변환을 담당하는 인터페이스
   • 단일 타입에서 단일 타입으로 변환할 때 사용한다.
     • Converter<Source, Type>

2. ConverterFactory

3. GenericConverter

4. ConditionalGenericConverter

1번만 외우고, 나머지는 필요할때 공식문서에서 찾던지~

🔄 ConversionService

컨버터를 모아서 편리하게 사용하게 해준다

• 인터페이스인데 컨버터를 사용할 수 있는지도 확인해주고, 사용도 해준다
• 우선 순위 = 내가 커스텀해 구현한 컨버터 >>>> 기본제공 컨버터

📌 DefalutConversionService

ConversionService를 구현한 구현체, ConvertRegistry에 다양한 Converter를 등록

📌 ConverterRegistry

Converter를 등록하고 관리

✔️ 예시

import static org.assertj.core.api.Assertions.*;// ✅ Assertions static 임포트 필요

public class ConversionServiceTest {

    @Test
    void defaultConversionService() {
        // given
        DefaultConversionService dcs = new DefaultConversionService();
        dcs.addConverter(new StringToPersonConverter());
        Person wonuk = new Person("wonuk", 100);

        // when
        Person stringToPerson = dcs.convert("wonuk:1200", Person.class);

        // then 
        assertThat(stringToPerson.getName()).isEqualTo(wonuk.getName());
        assertThat(stringToPerson.getAge()).isEqualTo(wonuk.getAge());
    }

}

위 코드를 통해 알수있는 것 ⇢> 컨버터 등록 / 사용은 분리 ! (ISP 원칙 적용)

📌 사용해보기

• 이미 내부적으로 ConversionService 가 있으니까

1️⃣ WebMvcConfigurer를 구현 2️⃣ addFomatters()로 컨버터를 등록만하고 사용 ▶️ 결과

📖 Formatter

객체를 특정한 포맷에 맞춰서 문자로 출력하는데 특화 (Converter보다 더 세부기능 )

• printer, parser 상속 ( 객체를 문자로 변환 / 문자를 객체로 변환 )

Locale

• 지역 / 언어 정보를 나타내는 객체 언어코드 en, ko / 국가코드 US, KR

📌 사용하기

1️⃣ Formatter 만들기

@Slf4j
public class PriceFormatter implements Formatter<Number> {

    @Override
  public Number parse(String text, Locale locale) throws ParseException {
    log.info("text = {}, locale={}", text, locale);

        // 변환 로직
        // NumberFormat이 제공하는 기능
        NumberFormat format = NumberFormat.getInstance(locale);
        // "10,000" -> 10000L
        return format.parse(text);
  }

  @Override
  public String print(Number object, Locale locale) {
            log.info("object = {}, locale = {}", object, locale);
            // 10000L -> "10,000"
      return NumberFormat.getInstance(locale).format(object);
  }

}

2️⃣ 변환하기

class PriceFormatterTest {

        PriceFormatter formatter = new PriceFormatter();

    @Test
    void parse() throws ParseException {
        // given, when
        Number result = formatter.parse("1,000", Locale.KOREA);

        // then
        // parse 결과는 Long
        Assertions.assertThat(result).isEqualTo(1000L);
    }

    @Test
    void print() {
        // given, when
        String result = formatter.print(1000, Locale.KOREA);

        // then
        Assertions.assertThat(result).isEqualTo("1,000");
    }
}

📌 Spring이 제공하는 Formatter

✔️ FormattingConversionService

ConversionService + Formatter 결합 구현체

어댑터 패턴으로 포매터가 컨버터처럼 동작하도록 만들어준다

✔️ DefaultFormatteingConversionService

FormattingConversionService + 통화, 숫자관련 Formatter를 추가한 것

public class FormattingConversionServiceTest {

    @Test
    void formattingConversionService() {

        // given
        DefaultFormattingConversionService conversionService = new DefaultFormattingConversionService();

        // Converter 등록
        conversionService.addConverter(new StringToPersonConverter());
        conversionService.addConverter(new PersonToStringConverter());
        // Formatter 등록
        conversionService.addFormatter(new PriceFormatter());

        // when
        String result = conversionService.convert(10000, String.class);

        // then
        Assertions.assertThat(result).isEqualTo("10,000");

    }

}

✔️ Annotation (DTO)

@NumberFormat - 숫자관련 지정 Formatter 사용 @DateTimeFormat - 날짜관련 지정 Formatter 사용 등등,,,

💡외울 필요 없음 공식문서에서 찾으셈

📝 과제 개요

✔️ 개발 환경

• Java: 17
• JDK: 17.0.1
• IDE: IntelliJ
• Spring Frame Work : 3.4.4
• API 테스트 도구 : postman

📌 공통 조건

• 모든 테이블은 고유 식별자(ID)를 가짐
• 3 Layer Architecture에 따라 각 계층의 역할에 맞춰 개발
• 모든 CRUD 기능은 JPA 기반으로 구현
• 인증/인가 절차는 Cookie/Session 방식으로 처리
• JPA 연관관계는 기본 단방향, 꼭 필요한 경우에만 양방향 설정

🔑 키워드 (CRUD 관련 어노테이션)

• @Entity : 테이블과 매핑되는 클래스에 사용
• @Id : 기본 키 필드 지정
• @GeneratedValue : 기본 키 자동 생성 전략 설정
• @Repository : DAO 클래스임을 명시
• @ManyToOne / @OneToMany : 테이블 간 연관관계 설정
• @JoinColumn : join 대상 컬럼 지정

🎨 구현한 내용

🌟 Git Hub 링크 & ReadMe / API 명세서

📋 참고했던 링크

1️⃣ 커밋 컨벤션

https://sungwookoo.tistory.com/1

• 이번에는 커밋 히스토리를 깔끔하게 하고자 노력했다

2️⃣커스텀 익셉션

https://dev-allday.tistory.com/77 https://beaniejoy.tistory.com/93

• 지난 미니세션을 듣고 커스텀 익셉션을 꼭 활용해야겠다 생각했는데, 생각보다 어려웠다

3️⃣로그인 기능 구현

https://congsong.tistory.com/38

🛠️ TroubleShooting

❶ Patch 요청시 새로운 데이터 생성 문제

📌 문제

• 스케줄 수정 후 PATCH 요청을 보냈는데, 응답이 잘 와서 문제가 없는 줄 알았다! 나중에 DB를 보니까 응답과 다르게 기존 스케줄이 수정된 게 아니라 새로운 아이디로 스케줄이 추가되고 있었다
• 문제는 Repository의 save() 때문이었다. insert/update를 자동으로 처리해줄거라 생각했는데, 내 코드에서는 일부 수정시 기존 엔터티가 없는 것으로 판단해서인지 INSERT만 하고 있었다

💡 해결방법

❎ 문제 코드

Schedule schedule = new Schedule(title, description);
Schedule updatedSchedule = scheduleRepository.save(schedule);

---

✅ 해결 코드

• Save는 Insert와 Update를 어떻게 구분할까? / JPA 변경 감지

• 구글링 한 결과 @DynamicUpdate 나 다른 방법이 있는 것 같았으나,, 나는 일단 @Transactional을 추가하고 update 를 사용했다

  ---

❷ Patch 요청시 부분 수정이 아닌 전체 덮어씌워짐(null까지)

📌 문제

• 스케줄 수정시 제목만 바꾸고 싶어서 제목만 넣어서 PATCH 했더니, 다른 값들은 null로 다 덮어씌워짐..! 심지어 기존에 있던 값들도 null이 되어버렸다

💡 해결방법

✅ 해결 코드

• 조건문으로 기존 데이터가 존재하는지 찾아두고 새로 받은 요청이 null이면 기존 값을 유지, null이 아니면 그 값으로 업데이트 하도록 했다

  ---

  ❸ 로그인 필터 white_list 경로 오류

  📌 문제

• 예제와 같이 로그인 필터에서 로그인 없이 접근 가능한 경로를 whiteList로 설정해뒀는데, /user, /login으로 해두고도 계속 필터링이 안 됐다

• 알고 보니 실제 내 컨트롤러 경로는 /user/login이라서… 매칭이 안 됐다😇

💡 해결방법

• WhiteList 를 실제 URI 경로에 맞게 수정했다

• 항상 URI를 확인하고 작성해야 한다..!

  ---

  ❹ Post 요청에서 username 직접 받지 않고 세션에서 꺼내쓰기

  📌 문제

• 일정 생성 요청에서 username을 request로 받아서 쓰고 있었는데, 로그인 구현 후에는 세션에 이미 로그인 정보가 있는 상태니까 굳이 클라이언트에서 username을 또 받을 필요가 없어졌다.

💡 해결방법

❎ 기존 코드

// 1. 스케줄 생성
@PostMapping
public ResponseEntity<ScheduleResponseDto> save(
           @RequestBody ScheduleRequestDto requestDto
       ){
       ScheduleResponseDto scheduleResponseDto = scheduleService.save(requestDto.getTitle(), requestDto.getDescription(), requestDto.getUsername());
       return new ResponseEntity<>(scheduleResponseDto, HttpStatus.CREATED);

---

✅ 해결 코드

• request.getSession().getAttribute("username") 작성, 그리고 ScheduleResopnseDto 에서는 username 필드를 아예 없애버렸다

  ---

❺ 에러코드 enum 사용 중 instance 오류

📌 문제

• enum으로 정의한 errorCode.USER_NOT_FOUND를 사용하는데, 자꾸만 인스턴스 오류 발생,, enum을 사용해본적도 없고(ㅋㅋ) 틀린 부분을 찾을 수 없어 한참을 해맸다

❎ 에러 메세지

Static member 'com. example. schedulerproject. exception. ErrorCode. USER_NOT_FOUND' accessed via instance reference

>**❎ 에러 코드**
```java
public class UserNotFoundException extends CustomException{
    public UserNotFoundException(ErrorCode errorCode) {
        super(errorCode.USER_NOT_FOUND);
    }
}  
>```

### 💡 해결방법
- `ErrorCode`에서 enum의 `static`으로 선언된 것들을 인스턴스 사용하듯 사용해서 문제가 있었다!
클래스 이름으로 접근해야한다..!
- **`super(ErrorCode.USER_NOT_FOUND);`** 한글자씩만 바꾸니 해결😂



<br>

---

# 🌟 나의 회고
---

📝 과제 개요

✔️ 개발 환경

• Java: 17
• JDK: 17.0.1
• IDE: IntelliJ
• Spring Frame Work : 3.4.4
• API 테스트 도구 : postman

✔️ 공통 조건

• 일정 작성, 수정, 조회 시 - 비밀번호 안 보이게
• 일정 수정, 삭제 - 요청 비밀번호와 비밀번호가 같을 때
• 3 Layer Architecture 활용
• CRUD 필수 기능은 데이터 베이스 연결 + JDBC 활용

🎨 구현한 내용

🌟 Git Hub 링크 & ReadMe / API 명세서

📋 고민했던 부분

1️⃣ 적절한 관심사 분리를 적용했는가?

• Controller 최대한 요청에 대한 응답을 반환하는 역할만 하도록 분리했다

• Service 비즈니스 로직을 담당하고, 검증이나 예외처리를 여기서 하려고 노력했다. (생각해보니 전체 일정 조회-조건부 필터링 할 때 null 검증을 이곳 저곳에서 한 것 같다🥲)

• Repository DB를 입력하고 꺼내오고 기존 DB와 비밀번호가 일치하는지 등등.. JDBC를 기반으로 sql을 활용해 조건을 필터링했다

2️⃣ RESTful한 API를 설계했는가?

• ✔️ RESTful API 체크리스트

  항목	준수 여부
  리소스 명사 사용	✅
  복수형 사용	✅
  동사 허용 조건	동사 사용 없음
  자원 계층 관계 표현	✅ 공통 계층/schedules사용, 기능에 따라/{id} 사용
  끝에 슬래시 금지	✅
  (언더바 사용 금지)하이픈 사용	하이픈 사용 없음
  소문자 사용	✅
  파일 확장자 포함 금지	✅
  CRUD 함수명 미사용	✅ POST, DELETE 등 HTTP 메서드 사용
  필터/정렬/페이징	✅ 일정 전체 조회(필터)시 query param 사용 /schedules?user=Surin&date=2025-03-25

3️⃣ 수정, 삭제 API의 request를 어떤 방식으로 사용했는가?

• id : Path로 전달
• 비밀번호 : Body 내의 dto로 전달 수정과 삭제 API 모두 ID는 @PathVariable로 전달하고 비밀번호는 query나 param에 노출하지 않고 @RequestBody로 전달하여 repository에서 검증했다

🛠️ TroubleShooting

❶ 관심사 분리

📌 문제

• 아직 모든게 미숙했기에 강의 내 '메모장 프로젝트'를 참고해서 모든 로직을 컨트롤러에 다 넣어 만들고 ➝ 관심사를 분리하고 ➝ DB에 연결하며 더 확실하게 역할을 나누는 과정으로 작성했다.

💡 해결방법

• Controller는 요청/응답 담당
• Service는 검증 및 로직 담당
• Repository는 DB와 직접 통신
• 강의대로 하다보니 Service, Repository 인터페이스를 만들었는데, 생성자나 매개변수가 바뀔때마다 인터페이스에서 한번에 수정하고 임플리먼트하니까 편했다

❷ 수정 / 삭제시 비밀번호 처리

📌 문제

• 공통 조건 충족을 위해 수정이나 삭제시에는 비밀번호를 받아 검증해야 했고, 반환될 때는 응답되어선 안됐다... 이건 해본 적이 없었다..! 실습예제에 없다..😂

💡 해결방법

• id는 @PathVariable / 비밀번호는 @RequestBody를 통해 dto로 받아 전달했다

  

• 둘다 비밀번호를 활용해야 해서 ScheduleRequestDto를 활용하고 강의에서 나온대로 Service에서 int타입을 사용해서 예외 상황을 가정했다

• Repository에서 비밀번호가 일치하는지 검증하기 전에 Service에서 예외상황에 대한 상태코드와 메세지를 나타냈다

  

❸ 비밀번호 검증하기

📌 문제

• 수정 / 삭제시 받아온 비밀번호가 기존 테이블의 비밀번호와 일치하는지 확인해야했다.
• java에서 sql문 활용이 익숙치 않아 생각보다 시간이 많이 걸렸다

💡 해결방법

• 비밀번호를 검증하는 sql쿼리를 작성했다.
• 입력값들은 쿼리 내에 직접 작성하지 않고 placeholder ? 로 대체하고 파라미터로 바인딩했다
• placeholder

❹ 수정일 미반영 문제

📌 문제

• 수정후에 수정일이 null이거나, 수정 완료후에 작성일이 null이거나.. 계속 null 파티였는데 심지어 테이블 생성시에 날짜는 전부 NOT NULL로 등록해둬서 exception 파티였다

💡 해결방법

• 일단 DB에 DEFAULT값을 추가해줬다 TIMESTMAP = CURRENT_TIMESTAMP 사용

  
  ALTER TABLE schedule 
  MODIFY created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP;
  
  ALTER TABLE schedule 
  MODIFY updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP;

• 일정 생성시 : 작성일 수정일을 둘다 현재시간으로 초기화 해주고 데이터에 저장했다

  

• 일정 수정시 : 수정일만 사용하고 현재시간으로 업데이트 했다

  

❺ 조건부 조회 설계

📌 문제

• 조건을 작성자명이나 수정일로 필터링을 해야하는데 이 조건이 둘다 있을 수도, 하나만 있을 수도, 둘다 없을 수도 있었다.
• 조건에 따라 sql문을 다르게 사용해야 했다.

💡 해결방법

• 일단 Controller에서는 둘다 null이 들어올 수 있게 해놓고 required = false

• Repository에서 user만 있을때, date만 있을때 각각 다르게 sql문을 이어붙였다

• sql문 동적으로 생성하는 방법을 찾아 작성했다

  @Override
    public List<ScheduleResponseDto> findAllSchedules(String user, String date) {
  
        StringBuilder sql = new StringBuilder("select * from schedule where 1=1 ");
        List<Object> fillteringSql = new ArrayList<>();
  
        if (user != null){
            sql.append("AND user = ?");
            fillteringSql.add(user);
        }
  
        if (date != null) {
            sql.append("AND DATE(updated_at) = ?");
            fillteringSql.add(Date.valueOf(date));
        }
  
        sql.append("Order by updated_at desc");
  
        return jdbcTemplate.query(sql.toString(),scheduleRowMapper(), fillteringSql.toArray());
    }

🌟 나의 회고

• Spring 기초에서 가장 중요한 개념은 ‘관심사 분리라는 걸 이번 과제를 통해 확실히 알게 되었다.
  처음에는 어떻게 시작해야 할지 몰라서, Spring이 처음인 나는 4주차부터 6주차 강의 중 실습 위주로 반복하며 따라 만들었다.
  처음엔 코드를 통으로 짜고, 그걸 분리하고, 또 분리하고… 데이터를 연결하면서 구조를 바꾸다 보니
  자연스럽게 Controller, Service, Repository의 역할 분리가 왜 중요한지를 체감했다.
  한 번 잘 분리해두니까 이후 기능을 추가하거나 수정할 때도 훨씬 편했다.

• 데이터를 다루면서 JDBC 방식의 장단점도 느꼈다.
  DB 연결 자체가 처음이라 application.properties 설정부터 많이 헤맸고,
  사전캠프 때와 달리 이번에는 java에서 SQL 쿼리를 사용하느라 구글링하면서 하나씩 해나갔다. 특히 조건에 따라 데이터를 필터링하는 부분이나 테이블 구조를 계속 바꾸는 과정이 쉽지 않았다.
• 직접 쿼리를 써야 한다는 점은 좋았지만*, 반복적으로 구조가 바뀔 땐 번거로운 점도 있었다.

• 그리고 이번 과제를 하며 API 명세서와 ERD의 중요성도 크게 느꼈다.
  튜터님이 “API 설계와 ERD 작업에 전체 개발 시간의 80%를 쓸 수도 있다”고 하셨는데,그 말이 정말 맞았다 ! 중간중간 막힐 때마다 내가 임의로 정리해둔 API 명세서를 계속 참고하면서 코드를 짤 수 있었고, 덕분에 시간을 아낄 수 있었다.
  특히 ERD를 처음부터 그려두고 사용하니 Repository 단에서 설계에 집중할 수 있어 훨씬 수월했다.
  물론 이번엔 테이블이 하나라 단순했지만, 앞으로는 테이블이 여러 개로 늘어날 거고,, 이번처럼 대충 작성해두면 중간에 계속 수정하게 될 것 같다 😂
• 앞으로는 요구사항을 정확히 파악하고, 초반에 ERD를 더 꼼꼼히 설계*해두면 정말 유용하게 활용할 수 있을 것 같다.

📖 @Slf4j

기본적으로 인터페이스로 구성, 구현체를 사용해야 한다 log back 라이브러리 사용

📌 Logging

Thread 정보나 클래스 이름 같은 부가정보를 확인 ➝ 이제까지는 println으로 콘솔에 출력했다면 별도의 로깅 라이브러리를 사용해 로그를 출력해야한다

@Slf4j // 로깅 사용할 수 있도록 인터페이스 활용
@RestController // 컨트롤러 만들기
public class Slf4jController {

    @RequestMapping("/logging") // 스프링빈 만들기
    public String logging() {

        String sparta = "Sparta";
        // 로그 레벨 : TRACE -> DEBUG -> INFO -> WARN -> ERROR
        // 디폴트 : INFO

        // ❎ 실행되지 않는다
        log.trace("문자 trace={}", sparta);
        log.debug("문자 debug={}", sparta);

        // ✅ 실행된다
        log.info("문자 info={}", sparta);
        log.warn("문자 warn={}", sparta);
        log.error("문자 error={}", sparta);

        return "success";
    }

}

✔️log level

• 용도 : 이 설정을 통해 error만 출력한다던지 (출력모으기) 로그메세지를 일자별로 모아서 외부 저장소에 보관하기도 한다 (로그 모아놓고 에러 찾기)

  🌟 TRACE > DEBUG > INFO > WARN > ERROR

  

• 위 코드로 설정할 수 있음 (레벨 시작 = TRACE 라는 뜻)
• 따로 설정하지 않으면 기본 레벨(defalut) : INFO

📌 log 사용시 주의할 것

✅	❎
중괄호 사용⭕️	중괄호 사용 ❌ (문자열+문자열) 연산 형태 사용
알아서 괄호랑 문자가 치환되고 로그레벨 적용	로그 레벨 상관없이 연산 먼저 해버린다

▪️@Controller VS @RestController▪️

💡 스프링에서 컨트롤러를 만들때 사용하는 어노테이션

📖 @Controller

@Controller
public class ViewController {

    @RequestMapping("/view")
    public String example() {
        // logic
        return "sparta"; // ViewName이 return된다 (리소스의 타임리프로 만든 뷰)
    }

}

• 응답할 View가 있는 경우 = *타임리프나 jsp를 쓰는경우에 사용

*타임리프 사용 그레이들에 타임리프 의존성을 추가하면 뷰의 기본 경로가 main/resources/templates 로 설정된다 ➝ 알맞은 View를 찾는 과정에서 return값이 string이면 ThymeleafViewResolver에 의해 view name으로 인식된다

📖 @RestController

@RestController
public class ResponseController {

    @RequestMapping("/string")
    public String example() {
        // logic
        return "sparta"; // ViewName이 return 되는게 아니라, String Data가 반환된다.
    }

}

• 응답할 Data가 있는 경우에 사용
• 현재는 대부분 이것을 사용해 API가 만들어진다 (Restful API) ➝ return 값으로 View를 찾는 것이 아니라 *HTTP Message Body에 Data를 입력**한다

*알맞는 View를 찾고 View Resolver한테 가는게 아니라! 바로 데이터를 반환한다 (화면이 그려지는게 아니라 데이터가 나온다)

▪️Annotation 자세히 보기▪️

📖 @Conponent

• 스프링 빈에 등록하는 역할 = 서블릿 컨테이너와 비슷한 역할
• 빈? 애플리케이션의 구성요소를 정의하는 객체

💡 @Indexed

• 하위 클래스가 스프링 빈에 더 빠르게 등록되도록 도와준다

📖 @Target

• 하위 어노테이션이 어떤 범위에 적용되는지 설정
• 엘리먼트 타입의 이넘으로 속성을 설정..

📖 @Retention

• 하위의 어노테이션이 얼마나 오래 유지되는지를 설정

1. SOURCE
   • 소스 코드(.java)에서만 유지
   • 컴파일러에 의해 클래스 파일로 저장되지 않는다
2. CLASS
   • 컴파일된 클래스 파일(.class)에 저장되지만, JVM이 실행 시 읽지 않는다(주석과 같음)
   • Default 값임
3. RUNTIME
   • 클래스 파일(.class)에 저장되고, JVM에 의해 런타임 시점에 읽을 수 있다
   • 즉, 실제 런타임 시점의 코드에 반영되어 영향을 준다

📖 @Documented

• 문서화 도구에 의해 문서화되어야 함을 나타냄

▪️Request Mapping▪️

1️⃣ Request Mapping

💡 특정 URL로 요청을 보내면, 그 요청과 컨트롤러 내부의 특정 메서드를 연결 / 매핑함 (실제로는 여러요소를 조합해 매핑한다)

✔️ 사용예시

@RequestMapping(value = "/v1", method = RequestMethod.GET)

• 버전 별로 선언 방식 다르다! ➝ 현재는 맨 뒤에 슬래시 없어야한다

• 속성값들을 설정할때 배열형태로 선언하면 다중설정이 가능하다

• 기본적으로 모든 Http 메서드를 허용한다 (메서드 속성 설정 안했을때)

• 메서드 속성으로 따로 지정을 해버리면 지정된 것만 허용도 가능

     // HTTP Method 는 GET만 허용한다.
     @RequestMapping(value = "/v1", method = RequestMethod.GET)
     public String exampleV1() {
         // logic
      return "this is sparta!";
     }

2️⃣ @GetMapping

✔️ 사용예시

@GetMapping(value = "/v2")

• method = {RequestMethod.GET} 이 설정되어 있는 클래스
• POST, PUT, PATCH, DELETE 모두 사용가능 !
• @RequestMapping 보다 직관적이므로 주로 사용한다

@GetMapping(value = "/v2")
public String exampleV2() {
    // logic
    return "this is sparta!";
}

📌 @RequestMapping 을 사용하는 경우

• 예시 : users/{userId}, category/{categoryId}/product/{productId} prefix로 선언할 URL을 class 레벨에 적용하는 것에 주로 사용

3️⃣ @PathVariable

💡 경로 변수임, 비연결성을 극복하기 위함 URL로 전달된 값을 파라미터로 받아온다

✔️ 사용예시

user/{id}

• 경로 변수를 중괄호에 둘러 싸서 사용
• 반드시 경로변수 값을 가져야한다!
• Restful API 설계를 위해 사용빈도가 높아지고 있음

** 1️⃣ 파라미터 변수명과 PathVariable 변수명이 같으면 생략 가능**

[생략전❌]

@RequestMapping("/posts")
@RestController
public class PathVariableController {

    // postId로 된 post 단건 조회
    @GetMapping("/{postId}")
    public String pathVariableV1(@PathVariable("postId") Long data) {
        // logic
        String result = "PathvariableV1 결과입니다 : " + data;
        return result;
    }
}

---------------

[생략후⭕️]

@RequestMapping("/posts")
@RestController
public class PathVariableController {

    // 변수명과 같다면 속성값 생략가능
    @GetMapping("/{postId}")
    public String pathVariableV2(@PathVariable Long postId) {
        // logic
        String result = "PathvariableV2 결과입니다 : " + postId;
        return result;
    }

}

2️⃣ @PathVariable 다중 사용 가능

[1개 사용]

@RestController
public class PathVariableController {

    @GetMapping("/{postId}/comments/{commentId}")
    public String pathVariableV3(
                                @PathVariable Long postId,
                                   @PathVariable Long commentId
                                 ) {
        // logic
        String result = "PathvariableV3 결과입니다 postId : " + postId + "commentsId : " + commentId;
        return result;
    }

}

---------

[다중 사용]

@RequestMapping("/posts/{postId}")
@RestController
public class PathVariableController {

    @GetMapping("/comments/{commentId}")
    public String pathVariableV4(
                                @PathVariable Long postId,
                                @PathVariable Long commentId
                                ) {
        // logic
        String result = "PathvariableV4 결과입니다 postId : " + postId + "commentsId : " + commentId;
        return result;
    }

}

4️⃣ Request Parameter

💡 요청과 속성의 파라미터를 매핑할 수 있음

📌 1. 특정 파라미터와 매핑하기

✔️ 사용예시

@GetMapping(value = "/users", params = "gender=man")

(요청 :URL GET http://localhost:8080/users?gender=man )

✔️ 규칙

1. params = "gender"

   • params의 key값은 커스텀이 가능하다
   • value는 없어도 된다.

2. params = "!gender"

   • gender가 없어야 한다는 의미

3. params = "gender=man"

   • gender=man 이어야 한다는 의미

4. params = "gender!=man"

   • params의 value값이 man가 아니여야 한다는 의미

5. params = {"gender=man", "gender=woman"}

   • 배열로 속성 값을 여러 개 설정이 가능

   ---

📌 2. 특정 헤더와 매핑하기

✔️ 사용예시

@PostMapping(value = "/users", headers = "Content-Type=application/json")

• 특정 헤더와 매핑할 수 있다

• 속성 작성 규칙은 위 params 속성 값의 규칙과 같다

  ---

📌 3. MediaType 매핑, consume(수용)

✔️ 사용예시

@PostMapping(value = "/users", consumes = "application/json")

• 🌟HTTP Header Content-Type(요청)과 매핑
• consumes 값은 //MediaType.APPLICATION_JSON_VALUE
• 최대한 MediaType의 Enum을 사용해라!

✔️ 규칙

1. consumes=”application/json”

   • application/json 미디어 타입 허용

2. consumes=”!application/json”

   • application/json 제외 미디어 타입 허용

3. consumes=”application/*”

   • application/ 으로 시작하는 모든 미디어 타입 허용

4. consumes=”*\/*”

   • 모두 허용

   ---

📌 4. MediaType 매핑, produces(제공)

✔️ 사용예시

@GetMapping(value = "/users", produces = "text/plain")

• 🌟요청 헤더의 Accept 값에 따라서 produces 하는 값이 변함
• 최대한 MediaType의 Enum을 사용해라!

📖 Spring이 지원하는 파라미터

• @Controller의 사용 가능한 파라미터 목록

• @Controller의 사용 가능한 Response 값 목록

📌 Http 헤더 조회하기

[예시]

// 로깅
@Slf4j
@RestController
public class RequestHeaderController {

    @GetMapping("/request/headers")
    public String headers(
            HttpServletRequest request, // Servlet에서 사용한것과 같음
            HttpServletResponse response, // Servlet에서 사용한것과 같음
            @RequestHeader MultiValueMap<String, String> headerMap,
            @RequestHeader("host") String host,
            @CookieValue(value = "cookie", required = false) String cookie,
            HttpMethod httpMethod,
            Locale locale
    ) {
            // Servlet
        log.info("request={}", request);
        log.info("response={}", response);

        // @RequestHeader
        log.info("headerMap={}", headerMap);
        log.info("host={}", host);

        // @CookieValue
        log.info("cookie={}", cookie);

        // HttpMethod
        log.info("httpMethod={}", httpMethod);

        // Locale
        log.info("Locale={}", locale);

        return "success";
    }
}

• API 호출

• Log 출력 결과

▪️MVC 패턴 개요▪️

📖 Template Engine

💡동적인 웹페이지를 생성하기 위해 사용되는 도구 / 흔히 말하는 UI (SSR에 사용)

📌 등장 배경

• HTML 문서 중 동적으로 변경해야 하는 부분만 자바 코드로 넣을 수 있어 더 편리하다

• 예를 들어 웹페이지가 있을 때 특정 글을 조회할 때, 변하는 부분만 변하고 나머지 요소들은 고정임 변해야 하는 곳만!! 코드로 넣어준다

📌 대표적인 템플릿 엔진

• 1️⃣ 타임리프 - 스프링과 연동이 잘되고, 다양한 기능이 많다
• 2️⃣ JSP

📖 MVC 패턴 등장 배경

💡서블릿과 jsp만으로 만들면 비지니스 로직과 뷰 렌더링까지 처리하기가 구조가 넘 복잡함 (유지보수 힘듦) ➝ 따라서 mvc (모델 뷰 컨트롤러) 패턴을 사용한다

✔️ Servlet, JSP만 사용시 문제점

Servlet	JSP
화면을 그리는 로직과, 비즈니스 로직이 하나의 Servlet 안에 다 섞여 들어있음	우리가 많이 본 html코드가 자바코드랑 같이 있음 ➝ 서블릿에서 뷰만 분리된것
다 섞임	뷰는 분리되었지만 로직이 섞임

📖 MVC 패턴

💡하나의 jsp나 servlet으로 처리하던걸 Model , View , Controller 로 분리

• 🌟 비즈니스 로직과 뷰의 완전한 분리!!

✔️ Controller

• HTTP Request를 전달받아 파라미터 검증
• View에 전달할 결과 조회 후 Model에 임시저장
• Layered architecture 구조 이용해 역할이 또 세분화 된다!
  • 1️⃣ Controller Layer ➝ HTTP Request를 전달받아 파라미터 검증
  • 2️⃣ Service Layer ➝ 비즈니스 로직 실행
  • 3️⃣ Repository Layer ➝ 데이터 베이스와 상호작용

✔️ Model

• View에 출력할 데이터를 저장

✔️ View

• Model 객체의 데이터를 이용해 화면을 Rendering

📌 MVC 패턴의 문제점

기능별로 서블릿이 계속 필요함..

• 중복 호출
• 뷰의 경로도 계속 입력해줘야한다
• 리퀘스트는 사용하지만 리스폰스를 안씀 ( jsp가 다 처리하기 때문에 )
• *공통 기능이 추가 될 수록 컨트롤러가 처리할 부분이 많아짐 ➝ 메서드로 만들어서 호출하면 되는거 아닌가요?
  • 이것도 메서드도 중복 호출해야하고 까먹을 수도 있음
  • 메서드 늘어날때마다 컨트롤러 작업범위 커짐

*공통기능? 모든 컨트롤러에서 공통으로 적용되는 기능 (log 출력, 인가 등)

📖 프론트 컨트롤러 패턴

💡컨트롤러 호출 전에 공통기능을 하나의 서블릿에서 처리해주는 패턴 ➝ 입구가 하나다! 공통기능의 서블릿을 꼬옥 지나가야해

1. 모든 요청을 받고 공통기능을 처리
2. 요청을 처리할 수 있는 컨트롤러를 찾아서 호출한다 ➝ 컨트롤러 맵핑
3. 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 된다 ( 나머지 애들은 상속이나 webservlet을 안써도 된다 )

➝ 응답은 전부 다른 형태로 나올 수 있으니 어댑터 필요

📖 어댑터 패턴

💡 다양한 컨트롤러 핸들러를 유연하게 만들기 위해 도입

1. 컨트롤러는 로직 처리 후 그것에 맞는 결과를 반환
2. 반환된 응답을 어댑터가 공통로직과 맞춰 변환한다
3. 프론트 컨트롤러는 공통 로직 수행

• 모두 각자의 역할만 수행한다(책임분리)
• 새로운 핸들러가 추가되어도 어댑터만 추가하면 공통로직에 영향 없음

🚀 Spring MVC 패턴 개요

❶ Servlet만 사용 ** - 비즈니스 로직, View가 분리되지 않음 *❷ JSP만 사용 * - View는 분리하였으나 로직이 Jsp에 포함 **❸ MVC 패턴 사용 - 모델, 뷰, 컨트롤러를 분리하였으나 공통기능임에도 코드를 중복입력해야함 ❹ 프론트 컨트롤러 패턴 - 하나의 입구를 만들어 공통기능을 처리하지만 모든 핸들러의 응답을 이것에 맞게 바꿔야함 ❺ 어댑터 컨트롤러 패턴 - 핸들러의 응답을 프론트 컨트롤러에 맞게 연결해준다

▪️ Spring MVC 패턴▪️

📖 Spring MVC 패턴

📌 Front Controller (디스패쳐 서블릿)

• 요청을 받고 알맞는 핸들러, 어댑터를 찾고 반환한다
• 핸들러 목록 , 어댑터 목록을 가지고있다

📌 Handler Adapter

• 내가 처리할 수 있는지? 확인하는 메서드 필요
• 핸들러에게 요청을 지시하는 기능
• 리턴할 때 알맞는 응답으로 변환한다

📌 Handler

• 로직만 처리하면 된다 애들이 다 걸러옴

📖 Spring MVC의 주요 Interface

대부분의 기능들이 인터페이스로 만들어져 있기 때문에
DispatcherServlet 코드의 변경없이 기능 변경이나 확장이 가능하다

✔️ 주요 인터페이스 목록

1. HandlerMapping
2. HandlerAdapter
3. ViewResolver
4. View

📖 Controller Interface

• 💡인터페이스를 임플리먼트하여 원하는 핸들러를 만들 수 있다
• Annotation 기반의 Controller와는 상관없다

📌@Component

• Spring Bean으로 등록하기 위한 기본 어노테이션
• Spring이 실행될 때, @Component가 붙은 클래스를 찾아서 객체(인스턴스)로 만들고 컨테이너에 등록한다.

@Component = "너 이거 빈으로 등록해!" @Service, @Repository, @Controller 등 = "이거 빈인데, 역할은 이거야!"

✔️ Spring Bean

• 컨테이너가 관리하는 객체, 즉 인스턴스 !
• Spring은 내부적으로 @Component 계열의 클래스들을 객체화 시키고 Spring Bean으로 등록해둔다
• 특정 경로로 요청이 들어오면, 해당 경로와 바인딩 된 Spring Bean을 찾아서 그 Spring Bean에 매핑된 Controller를 찾아 실행해준다.

📌 Handler Mapping, Handler Adapter의 우선 순위

스프링에서 사용자가 /class/1 같은 요청을 보내면, 중앙에서 모든 요청을 받는 DispatcherServlet이 이걸 받아.

근데 DispatcherServlet 혼자선 이렇게 생각함

"이 URL은 누구한테 맡기지...? 누구 메서드 실행해야 하지...?"

HandlerMapping URL을 기반으로 어떤 Bean의 어떤 메서드를 실행할지 찾음 HandlerAdapter 찾은 Bean을 실제로 어떻게 실행할지 방법을 제공

📖 View Resolver

📖 프레임워크

💡 붕어빵을 만들땐 붕어빵틀을 사용해야 한다 ! 소프트웨어를 만들때 틀

📌 장점

• 일관된 구조로 팀 협업 편해짐
• 필요한 기능과 도구(보안관련 기능까지)를 제공, 개발자들은 비즈니스 로직에 집중 가능
• 인기 있는 프레임 워크는 다양한 문서를 활용할 수 있다 (커뮤니티)

📌 단점

• 구조가 복잡하다 보니 처음 배울때 시간 많이 소요된다
• 버전이 달라지면 기존 코드와 호환이 불가할수도
• 틀이 있다보니 자유롭게 변경은 불가

📖 라이브러리

💡 도서관에서 책 찾아읽듯, 소프트웨어 만들때 필요한 도구를 꺼내서 사용할 수 있다

📌 장점

• 누군가 만들어 두었기에 직접 개발하지 않아도 되고, 개발생산성 높아진다
• 검증된 라이브러리 ➝ 품질 보장

📌 단점

• 라이브러리가 업데이트되거나 지원이 중단될 수도
• 버전 호환성 문제로 기존 코드와 충돌일어날 수도 ➝ 빈번함
• 일부 불필요한 기능 있을 수도
• 내부 구현은 직접 수정이 어려워서 입맛대로 변경 불가

▪️ Annotation

📖 Annotation

💡 Java의 주석과 비슷 ( 사람에게 정보 제공 ) , 어노테이션은 프로그램에게 정보 제공 코드에 특별한 의미를 부여하거나, 특정 동작을 트리거하기 위해 사용

• Annotation @로 시작, 다양한 레벨에 위치할 수 있다

📌 내장 Annotation

• @Override : 상위 클래스나 인터페이스의 메서드를 오버라이드 하고 있음 (컴파일러는 실제 오버라이드 중인지 확인)

• @Deprecated : 더 이상 사용하지 않는 요소를 나타낼 때 (이 코드를 사용하면 컴파일 경고 발생)

• SuppressWarnings : 컴파일러 경고 억제 (사용되지 않는 변수에 대한 경고를 무시할 수 있다)

📌 사용자 정의 Annotation

• 필요에 따라 어노테이션을 커스텀 할 수 있다
• 메타데이터를 추가하거나, AOP를 결합할 수도 있다

📖 Lombok

💡 어노테이션 기반으로 동작, 보일러 플레이트 코드를 줄여주는 라이브러리 주로 컴파일 시점에 필요한 메서드로 변환 *보일러 플레이트 코드 -getter setter 메서드 생성자 등 반복적으로 작성되는 코드

📌 주요 Lombok Annotation

• @Getter, @Setter

  • 클래스 내부에 모든 필드에 대해 getter ,setter를 자동으로 생성
  
  

• @ToString

  • 객체의 toString() 메서드를 자동으로 생성
    

• @EqualsAndHashCode

  • equals()와 hashCode() 메서드를 자동으로 생성
    

• ** ❶@NoArgsConstructor ❷@AllArgsConstructor ❸@RequiredArgsConstructor**

  • ❶ 기본 생성자를 생성
  • ❷ 모든 필드를 매개변수로 하는 생성자를 생성
  • ❸ 필수(final) 필드만을 매개변수로 하는 생성자를 자동으로 생성

• @Data

  • @Getter, @Setter, @ToString, @EqualsAndHashCode,@RequiredArgsConstructor를 한꺼번에 적용
  • 주로 테스트 용도로 사용 (잘 안씀)

• @Builder

  • 복잡한 객체들을 필드 이름을 지정하면서 편하게 생성 가능

    User user = User.builder()
              .name("John")
              .age(30)
              .build();

• @Slf4j

  • 클래스에 로그를 남기기 위한 Logger 객체를 자동으로 생성

    @Slf4j
    public class UserService {
      public void logMessage() {
          log.info("This is a log message");
      }
    }

    
    

▪️Spring Framework와 Spring Boot ▪️

📖 Spring Framework

💡 자바로 엔터프라이즈 애플리케이션 개발에 자주 사용 *엔터프라이즈 애플리케이션 : 대규모 비즈니스 프로세스와 데이터를 처리하는 어플리케이션

📌 특징

• 다양한 구성요소를 유연하게 관리
• 누구나 사용할 수 있는 오픈 소스
• 모듈화되어 있어 특정 기능만 선택적 사용도 가능
• Java의 가장 큰 특징인 객체지향 언어의 특징을 살려낸 프레임워크
  

📖 Spring Boot

💡Spring Framework를 기반으로 간편하게 애플리케이션을 개발할 수 있도록 도와주는 도구

📌 특징

• 자동구성(Auto-configuration) 기능을 제공해서 직접 복잡한 설정할 필요가 없다 -> 생산성 높아짐

• 내장 WAS(Tomcat)를 제공해서 서버 설정 없이 바로 실행 가능

• 빌드 관리 도구(spring-boot-starter-web)를 추가하면 모든 종속성과 설정도 자동 구성

• 라이브러리의 버전을 명시하지 않아도 알아서 호환 가능한 버전 찾고 설정까지!! ( 100% 해결은 아닐지도 )

  
  

▪️ 빌드 관리 도구 ▪️

📖 Gradle

Java와 유사한 문법 구조로 Groovy기반의 스크립트 언어를 사용하는 빌드 자동화 도구

✔️ 빌드?

• 소스 코드를 컴퓨터가 실행할 수 있도록 변환
• 빌드에 필요한 과정

✔️ 빌드 자동화 도구

• Gradle은 빌드 뿐 아니라 라이브러리 테스트 관리하고 배포도 할 수 있다

📌 특징

• 1️⃣ 유연성

  • 직접 커스터마이징 가능

• 2️⃣ 성능 좋다

  • 빌드 결과물을 캐싱해서 재사용
  • 점진적 빌드 ( 마지막 빌드 호출 이후 변경된 부분만 빌드 -> 효율적 )
  • 데몬 프로세스 ( 다음 빌드를 위해 대기하는 프로세스, 초기화 이후 초기화 안함 )

• 3️⃣ 멀티 프로젝트 빌드 지원 ( 다같이 쓰는 클래스를 모듈화 시켜서 각 프로젝트에서 사용 가능 )

• 4️⃣ 설정 주입 방식

  • 프로젝트 별로 설정을 다르게 하거나, 공통을 한번에 주입하거나

🐘 build.gradle를 살펴보자

1. 플러그인
   • 특정 작업을 위해 모아 놓은 task들의 모음집
2. 의존성 관리
   • 우리가 프로젝트에서 사용할 패키지나 라이브러리를 관리
   • 의존성 설정?
   • 라이브러리를 추가하는 시점을 설정할 수 있다.
   • Implementation
     • 컴파일, 런타임 시점 모두에서 사용한다.
   • compileOnly
     • 컴파일할 때만 사용되고 런타임 때에는 사용하지 않는다.
   • runtimeOnly
     • 런타임 때만 사용한다.
   • testImplementation
     • 테스트할 때만 사용한다.
3. repositories
   • 라이브러리가 저장된 위치를 정의하고 온라인 저장소에서 라이브러리를 가져온다

Java 웹 기술의 역사

1. Servlet의 등장

• Servlet만으로 요청과 응답을 다 했음 -> 코드 복잡

2. JSP(JavaServer Pages) 도입

• jsp는 html내에 java코드를 삽입할 수 있다 -> jsp 내에 비즈니스 로직을 분리할 수가 없다

3. MVC 패턴 도입

• UI, 비즈니스 로직, 데이터를 분리할 수 있다
• Servlet으로 컨트롤러를 만들고 JSP로 뷰를 만든다 -> 유지보수성과 확장성 향상, 중복 코드 발생

4. MVC 프레임워크 등장

• MVC 패턴을 구현할 수 있게 도와주는 프레임워크가 등장했다

▪️ HTTP ▪️

📖 HTTP(HyperText Transfer Protocol)

💡 JSON 같은 다양한 형태의 데이터가 HTTP를 통해 전송 주로 HTML/1.1 TCP를 사용 / 최근 HTML/2, HTML/3 UDP의 사용량도 증가중

📌 동작 순서

• 클라이언트 : 요청을 보내고 응답을 기다린다

• 서버 : 요청을 수행하고 결과를 응답한다

  ---

📌 특징

• HTTP는 인터넷 상에서 불특정 다수의 통신환경을 고려하여 설계되었다 (다수의 클라이언트와 상태나 연결을 유지해야한다면 - 많은 서버의 리소스가 필요하다)

1️⃣** 클라이언트 - 서버 각각 독립적 구성**

2️⃣ 무상태 Stateless

- 서버는 클라이언트의 상태를 보존하지 않으므로 수평 확장성 높다
- 한계 : 무상태의 한계 ( = 전부 Stateless하게 설계할 수는 없다)
➡︎ 캐시, 세션, 토큰으로 해결

3️⃣ 비연결connectionless

- 연결을 유지하지 않으므로 자원 효율적 사용
- 한계 : 비연결의 한계 ( = 매 요청마다 연결하고 정적자원 다운로드 )
➡︎ HTTP 지속연결로 해결

🌟기억 안나면 용어모음집 살펴보자🌟

📖 HTTP Message 구조

💡요청메세지 응답메세지 두가지가 있다

• <기본 구조>

📌 구조 분석하기

	요청 메세지(Request Message)	응답 메세지(Response Message)
	HTTP Method - GET, POST, PUT, PATCH, DELETE 등	HTTP Version
Start Line	path - 전송되는 대상의 절대 경로(쿼리포함)	Status Code-요청 성공여부 나타내는 코드
	HTTP Version	Status Text-코드와 함께 전달될 메세지
Header	- 요청의 추가 정보들을 가지고 있다.	- 응답에 쓰는 Header 값 따로 존재
Empty Line	- 공백 한 줄	- 공백 한 줄
Message Body	- 실제 전송하는 데이터가 담겨 있는 부분	- 실제 전송하는 데이터가 담겨 있는 부분

* OWS : 띄어쓰기 허용
* field-name은 대소문자 구분을 하지 않는다.
* 서버가 값을알고 있어야 한다

📖 HTTP Method

📌 주요 메서드 (CRUD)

*1️⃣ POST - 리소스 생성 *

• 보통 생성될 때 데이터를 식별하기위해서 id값(식별자) 생김

• html form에 사용

• 데이터를 처리하는 방식(리소스)에 정해진 것은 없다

• message body를 통해 요청 데이터를 전달한다

  ---

2️⃣ GET - 리소스 조회

• ❶ Query String 미포함시 : message body가 지원되지 않는 경우가 많아 권장안한다

• ❷ Query String 포함인 경우 : 서버에 추가적인 데이터 전송이 필요하면 query string 을 사용!

  ---

3️⃣ PUT - 리소스 덮어쓰기

• 클라이언트가 항상 리소스를 식별해야한다 (post와 다름)

❶	❷	❸
- ❶ 기존 리소스 존재한다면 ➝ 리소스 전체 수정
- ❷ 기존 리소스에서 일부만 변경하고 싶은데? ➝ 그래도 리소스 완전히 덮어씌워짐
- ❸ 기존 리소스가 없는 경우 ➝ 리소스 생성

** 4️⃣ PATCH - 리소스 부분 수정**

• put이랑 다르다, 필요한 부분만 수정할 수 있다

  ---

5️⃣ DELETE - 리소스 삭제

📍 HTTP Method 속성

💡 속성표 *optional : 있을수도 없을수도

💡 안전성 (Safe)

• 🌟 데이터 변경되면 안전하지 않다
  • 안정 : GET (조회만 하니까)
  • 불안정 : POST, DELETE, PUT, PATCH

💡 멱등성 (Idempotent)

• 🌟 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다(요청이 실패한 경우 재시도 하기위해 필요)
  • ⭕️ 멱등성 보장 GET → 같은 결과가 계속 조회된다. (리소스 조회 재요청중 수정요청이 추가된다면? 멱등성 고려X) PUT → 수정해서 대체된 후의 결과는 계속 같다. DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
  • ❌ 멱등성 보장 안함
• POST* → 계좌 송금을 두번한다면?, 게시판 글쓰기, 회원가입

💡 캐시가능성 (Cacheable)

• 🌟 재사용을 위해 요청에 대한 응답을 저장할 수 있는가
  • 캐시(Cache) : 매번 요청때마다 데이터를 다시 전송할 필요가 없도록 웹브라우저가 임시보관하는 장소
  • 변경 가능성이 적은 정적자원을 주로 캐싱
  • 캐시 가능 : GET, HEAD, POST

📖 HTTP 상태 코드

아까 응답 메세지의 200 ok 부분 , 모두 외울필요 없음 백단위로 알고 있으셈

📌 1xx (정보)

• 🌟 요청 수신 후 처리중 (잘 사용 안함)

  📌 2xx (성공)

  • 🌟 정상 처리 완료

  대표코드
  200 OK	요청 성공
  201 Created	새로운 리소스 생성
  202 Accepted	요청이 수신되었으나 처리가 완료되지 않음 (주로 Batch 처리에서 사용)
  204 No Content	요청은 성공했지만, 응답 데이터가 없음 (저장 버튼, 작성 버튼 )

📌 3xx (리다이렉션)

• 🌟 요청을 완료하려면 추가 행동이 필요한 상태 (+ 서버가 너 이거 해바방! 알려줌)

• 리다이렉션의 종류

  • 영구 리다이렉션 url이 영구적으로 변경된 경우 - 기존 url 사용 안함

  301 Moved Permanently	메서드 변경(get), 메세지 변경될 수도
  308 Permanent Redirect	메서드와 본문 유지

  • 일시 리다이렉션 url이 일시적으로 변경된 경우

  302 Found	메서드 변경(get)
  303 See Other	메서드 변경(get)
  307 Temporary Redirect	메서드와 본문 유지
  ```
  💡 URL이 일시적으로 변경된 경우 예시
  -- PRG 패턴 : 게시글 작성(Post) → 응답(Redirect) → 리다이렉트 요청(Get)
  -- 이 패턴이 없으면 새로고침을 할때마다 요청이 중복 처리(post는 멱등성이 없으므로)

• • 적용하면 새로고침 할때 get 요청을 한다

    
    - **기타 리다이렉션**
    캐시를 활용할 것인지에 대한 여부
    
    |  ||
    |---|---|
    |**304 Not Modified**|캐시 목적으로 사용, 리소스가 수정되지 않았다 -> 클라이언트가 캐시 데이터를 조회하도록 유도|
    
    

📌 4xx (클라이언트 에러)

• 🌟 잘못된 문법 등으로 서버가 요청 수행 불가 (재시도 해봤자 실패)

  대표코드
  *400 Bad Request *	요청 내용을 수정해야한다
  401 Unauthorized	리소스에 대한 인증이 필요하다 (로그인같은)
  403 Forbidden	승인 거부, 주로 인가 문제 (권한 없음)
  404 Not Found	요청 리소스가 서버에 없다

📌 5xx (서버 에러)

• 🌟 서버 오류, 요청은 정상이지만 서버가 처리하지 못함 (재시도시 성공할 수도)
• 대표코드
  • 500 Internal Server Error 대부분 이거임
    • 503 Service Unavailable 서비스 이용 불가

📖 HTTP header

💡 부가적인 정보 전달에 쓰임 (Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)

• field-name: OWS field-value OWS (OWS : 띄어쓰기 허용)
• field-name은 대소문자 구분을 하지 않는다.
• HTTP 전송에 필요한 모든 부가정보를 표현할 수 있다.
• 임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함
• 텍스트 (plain text)로 이루어져 있다.
• 각각의 헤더는 하나의 줄로 구분된다.

✔️실제 Header 확인하는 법

• 개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보

📌 HTTP Header 모음

✔️ 표준 Header

• 외우기보다 찾아서 사용하자 !

✔️ 대표적인 Header

1️⃣ 표현 헤더

📎리소스에 대한 표현 정보 (우리 데이터는 이런 형식이에요 ~) 📎 요청과 응답에서 모두 사용

• Content-Type : 형식

  - 데이터의 미디어 타입이나 문자 인코딩을 나타냄

• Content-Encoding : 압축 방식
  • 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 이동
• Content-Language : 언어
• Content-Length : 길이

   - byte 단위로 나타냄

2️⃣ 컨텐츠 협상

📎 클라이언트가 선호하는 표현을 요청 📎 우선순위가 존재 (1에 가까울 수록 우선순위 높다, 1인경우 숫자 생략 가능)

• Accept : 선호하는 미디어 타입
• Accept-Charset : 선호하는 문자 인코딩
• Accept-Encoding : 선호하는 압축 인코딩
• Accept-Language : 선호하는 언어

3️⃣ 일반 정보

• From : 클라이언트 이메일 정보 - 잘 사용 안함

• Referer : 현재 요청된 페이지의 이전 웹 페이지 주소 - 유입 경로 파악 가능

• User-Agent : 클라이언트 애플리케이션 정보(PC, Mobile)- 어떤 환경에서 주로 접속하는지 통계

• Server : 요청을 처리하는 ORIGIN 서버의 Software 정보

• Date : HTTP 요청이 발생한 날짜와 시간

4️⃣ 특별 정보

• Host : 요청한 도메인 정보 (필수)

• Location : 생성된 리소스 URI, 리다이렉트 주소

  • 응답코드 3xx와 함께 응답되면 리다이렉트 주소
  • 응답코드 201(Created)와 함께 응답되면 생성된 리소스의 URI

• Allow : 허용 가능한 HTTP Method

  • 405 (Method Not Allowed)와 함께 응답

• Retry-After : 다음 요청까지 대기 해야하는 시간

  • 503 (Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려줌

5️⃣ 인증

• Authorization : 클라이언트 인증 정보

• WWW-Authenticate : 리소스에 필요한 인증 방법

  • 401 (Unauthorized) 응답과 함께 사용된다.

6️⃣ Cookie

📎 Cookie를 사용해 요청마다 상태를 전달한다 (세션관리나 광고 트래킹에 주로 사용)

• Set-Cookie : 서버에서 응답시 클라이언트로 Cookie 값 전달

  • 만료기간(expire, max-age), 사용될 위치(domain, path) 설정
  • 주의 ❌ 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 시켜야 한다 탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않는다

• Cookie : 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송한다.

• Secure : 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송한다.

• HttpOnly : http 전송에만 사용한다.

  • 자바스크립트에서 쿠키를 접근하지 못하게 만든다.

• SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

  7️⃣ cache

• Cache-Control : 응답시 사용

  • Cache-Control: max-age
    • 캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시를 갱신
  • Cache-Control: no-cache
    • 캐시 가능한 데이터지만, 서버에 검증하고 사용
  • Cache-Control: no-store
    • 보안에 민감한 데이터, 캐시하지 않는다

• if-modified-since : 캐시로 저장된 데이터 최종 수정일

• Last-Modified : 데이터가 마지막으로 수정된 시간

• ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정

📖 Restful API

💡 REST를 잘 준수하는 API , HTTP API를 잘 설계하는 규칙

✔️ REST(Representational State Transfer) ?

• 자원을 이름으로 구분해서 자원의 상태를 주고 받는 것
• URL로 자원 명시, 메서드를 통해 CRUD를 구현하는 것

✔️ 설계 원칙

1. 리소스는 명사를 사용해야 한다.
2. 단수가 아닌 복수 형태를 사용해야 한다.
3. 만약, REST만으로 해결하기 어려운 경우라면 동사를 허용한다.
4. 자원의 계층 관계를 슬래시(/)로 표현한다.
5. 마지막 문자에는 슬래시(/)가 있으면 안된다.
6. 언더바(_)가 아닌 하이픈(-)을 사용해야 한다.
7. 소문자를 사용해야 한다.
8. URI에 파일 확장자를 포함하면 안된다.
9. CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.
10. 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 한다.

📌 Maturity Model (성숙도 모델)

REST의 제약 조건에 따라 API를 등급화하는 방법

level 0 *- URL만 만듦 *level 1 - 의미있는 URL, but http 메서드 사용 부적절 level 2 (최소 권장 레벨) - crud와 매칭되는 메서드를 이용하는것 level 3 - 어떤 작업을 할 수 있는지 상태정보를 함께 넘겨준다

▪️ Web Application ▪️

📖 Web Server

💡 HTTP 기반으로 동작, 정적 리소스 제공 *정적리소스 : 이미 완성된 채로 서버에 존재하는 리소스, 원본 그대로 대답하는 데이터

📖 WAS (Web Application Server)

💡 HTTP 기반으로 동작, 웹서버의 기능을 포함 (추가적으로 코드를 실행 ➝ 로직 수행 ➝ 데이터와 상호작용 후(CRUD) 동적 컨텐츠 생성)

• 대표적인 WAS : Tomcat - spring boot에 내장되어있다

✔️ Web Server 🆚 WAS

1. 실제로는 웹서버에서도 애플리케이션 로직을 포함할 수는 있다
2. 와스는 애플리케이션 코드를 실행하는데 더욱 특화되어 있다
3. 자바에서는 Servlet Container 기능을 제공하면 와스이다

📖 Web System 구성

📌 WAS만 사용하는 경우

(WAS 안에 로직 정적리소스 다 넣고 쓰기)

1️⃣ WAS가 너무 많은 역할을 하게된다 -> 서버 과부하 2️⃣ WAS에서는 애플리케이션 로직이 가장 중요한데 정적 리소스 때문에 로직 수행 불가할 수도 3️⃣ WAS에 장애가 생기면 화면 출력 불가 (+ 클라이언트에게 오류임을 응답할 수 없다)

📌 실제 웹시스템 구성

• 웹서버는 정적자원 처리 와스는 로직만! 분업을 시키자

✔️ 장점

• 효율적인 관리 : 자원 늘어나면 서버를 추가해서 수평적 확장 가능 ( 정적 자원이 많이 쓰이면 Web Server / App관련 자원이 증가되면 WAS를 스케일 아웃 )
• WAS가 다운되어도 Web Server는 정상 동작 (+ 에러페이지 전달 가능)

📖 Servlet

• 💡 HTTP 통신에서 요청과 응답을 처리하는데 사용된다 자바에서는 Http servlet을 상속받아 구현

📌 역할

📎 원래 서버에서 데이터 처리하는 과정

1. 서버와 TCP/IP 연결
2. HTTP Request Message 필요한 형태로 변환하여 읽기
    1. HTTP Method 및 URL 분석
    2. HTTP Header 분석
    3. HTTP Message Body 읽기 및 변환
3. 분석한 결과를 통해 프로세스 실행
🌟4. 비지니스 로직 실행
5. HTTP Response Message 생성
    1. HTTP Start Line 생성
    2. Header 생성
    3. HTTP Message Body에 응답 데이터를 요청한 형식에 맞춰 응답
    4. 처리가 불가하다면 예외처리
6. 응답 전달
7. 연결 종료

🌟 Servlet이 4번빼고 다해줌, 개발자는 개발만 하면된다

📌 동작 순서

• 개발자가 하는 일
  1. Request 객체에 담겨져있는 HTTP 요청 정보를 꺼내서 사용
     • 요청 정보(URL, Method, Message Body)를 통해 필요한 기능(비지니스 로직)을 수행
  2. 생선된 Response 객체에 HTTP 응답 정보를 입력

📖 Servlet Container

Servlet을 지원하는 WAS 내부에 존재한다 💡Servlet을 초기화, 생성, 관리, 호출, 종료하는 역할을 수행한다

• 생명주기 개발자가 직접 객체화 안해도, 코드만 작성하면 알아서 컨테이너가 알아서 Servlet을 생성한다 WAS가 종료될때 Servlet도 함께 종료

• Servlet Container가 하는일 Servlet을 생성, 관리, 호출, 종료하는 역할 - 싱글톤으로 관리 동시 요청 처리를 위해 멀티 스레드를 지원

*싱글톤? 객체를 하나만 생성하여 생성된 인스턴스를 공유하며 사용하는것

📖 Thread

코드를 하나하나 순차적으로 실행하는 것 한번에 하나만 가능하기에 동시에 여러개를 처리하려면 Thread를 추가 생성해야한다

📌 싱글 스레드 - 단일 요청

• Thread가 하나 / 요청도 하나 요청이 종료되면 원래위치로 돌려놓는다

📌 싱글 스레드 - 동시 요청

• Thread가 하나 / 요청이 여러개 두번째 요청이오면 Thread를 할당받기위해 대기한다 첫번째 요청이 끝나고 Thread가 반환되면 그때 다시 할당받고,,,반복

📖 Multi Thread

💡 여러개의 스래드를 만들자! WAS는 멀티스레드를 지원한다

📌 1. 요청이 올때마다 새로운 Thread를 생성하기

✔️ 장점

• 동시요청을 처리할 수 있다
• 하나에 문제가 발생해도 나머지 Thread는 정상적으로 동작한다

✔️ 단점

• Thread드 생성수에 제한이 없고 생성 비용이 높다 (동시요청이 많이 발생하면 리소스 부족으로 서버 다운)
• Thread를 사용하면 context switching 비용이 발생한다

*context switching ? 윈도우의 작업관리자 - 백그라운드 프로세스(순차적으로 실행되는 것) 1번 프로그램을 실행하다 2번으로 스위칭 할때 이 사이에 생기는 것 !

📌 2. Thread Pool을 이용하기

🌟 미리 Thread를 여러개 만들어 두고 요청이 발생할 때 사용, 요청 종료시 반납

• 모든 Thread가 사용중이라면? 일을 마친 Thread가 생길때까지 대기하거나 거절할 수 있다 (예시 - 대기번호)

💡 정리하기

1️⃣ WAS는 Multi Thread를 지원

• 개발자는 멀티스레드 관련코드 고려하지 않아도된다
• 멀티 스레드 환경에서는 싱글톤 객체 사용 → 공유변수 조심

2️⃣ Thread Pool

• 생성가능한 스레드의 최대갯수를 관리 (tomcat? 기본 200개 설정, 갯수 변경가능)

• 장점
  • 요청마다 생성하는 단점 보완
  • 미리 Thread를 생성해두었기 때문에 생성하거나 종료하는 비용 절약 + 응답이 빠르다
  • Thread의 최대갯수가 제한되어 있기때문에 초과 요청이 와도 안전하게 처리
• 단점
  • 최대 Thread 수를 너무 낮게 한다면 응답 지연
  • 최대 Thread 수가 높으면 요청 증가시 리소스 부족으로 서버 다운

▪️ SSR, CSR ▪️

📖 SSR (Server Side Rendering)

💡 서버에서 화면을 그려준다! 동적으로 html을 만들어서 클라이언트에게 제공하는 기술 *Java에서 대표적으로 사용되는 것 : JSP, Thymeleaf

📌 동작 흐름

✔️ 장점

• 초기 페이지 로드시 완전하게 랜더링된 html을 반환하기 때문에 로딩이 빠르다
• SEO에 유리

*SEO? 검색 엔진에서 상위 노출될 수있도록 최적화하는 과정

✔️ 단점

• 모든 요청에 대해 페이지를 렌더링해야함
• 만들어 진 채로 응답해야하기 때문에 느리다

📖 CSR

💡 클라이언트가 화면을 그린다! 자바스크립트로 html을 생성

📌 동작 흐름

• 클라이언트- html을 서버로 요청
• 서버 - 비어있는 html + js 링크 ( 클라이언트 로직, 렌더링 포함 )
• 동작하는 요청에 따라 필요한 형태(json 등)로 응답받는다
• 이 응답 데이터로 html을 동적으로 그린다

✔️ 장점

• 클라이언트가 렌더링을 하므로 사용자의 상호작용에 대한 반응이 빠르다 (구글맵 기억 - 사용자가 바로바로 움직인당)
• 초기 로딩(모든 로직과 js 링크 전달) 후에는 서버와 통신없이 바로 전환 가능

✔️ 단점

• 초기로딩 시간이 길다
• 검색엔진이 js를 실행하지 못하면 SEO에 불리

▪️ 네트워크 ▪️

💡 컴퓨터들은 어떻게 서로 통신할까? _ 초기에는 물리적인 형태(usb)였다. 통신할 컴퓨터가 멀리있다면? 인터넷 사용!_

✔️ 인터넷 (Internet)

• TCP / IP 기반으로 연결된 컴퓨터 네트워크 통신망
• 해저 광케이블(물리적 연결) / 인공위성 (무선 통신) ➝ *World Wide Web(www)구축 *

📖 IP (Internet Protocol)

💡 데이터 통신에 대한 규약 - 숫자는 IP 자체가 아닌 주소임 (데이터를 안전하게 전달하기위해 최소한의 인터넷 프로토콜이 필요하다)

📌 Packet

• 소스IP출발지 + 대상IP도착지를 포함 ➝ *어떤 컴퓨터에 전송할 지 판별 가능 *
• 구분 : 헤더 ,페이로드, 트레일러(수신여부 포함)
• 단지 데이터를 주기만 하는게 아니라 받고 응답한다

📌 IP 방식의 문제점

• ❶ 애플리케이션 구분 (어떤 프로그램에 사용하지? 구분이 어렵다)

• ❷ 비연결성 (수신 대상의 상태에 상관없이 데이터를 전송 - 컴퓨터가 꺼져 있어도)

• ❸ 비신뢰성

  • 패킷이 소실되는 경우, 손상여부를 양측 모두 알 수 없다.
  • 데이터가 큰 경우에는 여러개로 나눠 전송되고, 순서가 섞여버림 ➝ 이런 경우에도 데이터를 재전송 하지 않는다

📖 TCP (Transmission Control Protocol)

💡 데이터를 신뢰성있게 전달 (IP방식의 문제점 보완)

📌 3 Way HandShake

📍 최소한의 논리적 연결로 연결되었다고 가정하는것 !

✔️ SYN , ACK

✔️ 특징

• IP 방식의 단점 보완 (데이터가 잘 전송되었는지 응답 반환)
• 패킷이 나뉘어져 오더라도 순서를 보장한다 ➝ 느리다

📖 UDP (User Datagram Protocol)

💡 비연결형이고 신뢰성이 없는 프로토콜 ➝ 증말로 빠르당 ( 실시간성 보장 ) ( 인터넷 전화, 스트리밍, 온라인 게임 등 )

📌 UDP의 특징

1. IP 방식과 비슷하다 - 3 way handshake 하지 않는다 ** (비신뢰성)**
2. 추가적인 기능이 거의 없다 - 하지만 빨랐죠?
3. PORT가 존재한다
4. 잘못된 데이터가 전송되지 않도록 체크섬(Checksum)을 포함

📌 PORT

• 같은 IP 내에서 프로세스 구분을 함 ➝ IP의 단점 (애플리케이션 구분)을 보완

• Packet에 포함되어 있다

  ✔️ 자주 사용되는 PORT

  1. 0~65535 까지 할당 가능
  2. 0~1023 : 이미 사용되고 있는 포트 애지간하면 쓰지말자 💡 HTTP 80 (TCP) / HTTPS 443 (TCP)

▪️ Web 기초 ▪️

📖 DNS(Domain Name System)

IP주소는 유동적이기도 하고, 변경될 수도 있고, 외우기가 힘들다 💡 사람이 읽을 수 있는 도메인 주소를 컴퓨터가 읽을 수 있는 IP 주소로 변환한다

📌 DNS 동작 순서

1. 원하는 도메인 구매후 DNS 서버에 등록한다
2. 도메인 명을 입력하면 DNS는 IP주소를 반환한다
3. IP가 변경되면 DNS는 그대로, dns에 등록된 IP주소만 바꾸면 댐 ➝ 대표적인 예시 : URL

📖 URI (Uniform Resource Identifier)

💡 인터넷 자원(데이터)을 나타내는 고유식별자

• 자원 : 페이지, 텍스트, 이미지, 동영상, 파일 등
• ➝ URI는 URL, URN을 포함하는 개념*

📌 URL(Uniform Resource Locator)

💡 자원의 위치를 나타낸다

✔️ URL의 구조

** 💡 예시** scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment] https://www.google.com:443/search?q=스파르타+코딩클럽

💡 URL, URN 비교 (예시 참고)

▪️ 용어 모음집 ▪️

📖 프로그램 명명 규칙 (casing)

1️⃣ snake_case

• 데이터 베이스에서 주로 사용
  • 사용법 : 소문자 or 대문자
  • 단어연결 : 언더바 _ 사용

2️⃣ camelCase

• Java, JavaScript, TypeScript에서 변수, 함수, 메서드 이름
  • 사용법 : 첫 글자 소문자
  • 단어연결 : 연결시에만 대문자

3️⃣ PascalCase

• 클래스 이름
  • 사용법 : 첫 글자 대문자
  • 단어연결 : 대문자로 연결

4️⃣ kebab-case

• 거의 사용 안함
  • 사용법 : 모든 단어 소문자
  • 단어연결 : 대시 - 로 연결

📖 JSON

💡_ 클라이언트, 서버가 통신할 때 사용하는 데이터 양식_

• 통일된 양식 : 언어와 관계없이 데이터를 주고 받을 수 있다
• 이해가 쉽고 용량이 작다 ➝ XML 대체
• 클라이언트 to 서버 서버 to 클라이언트 서버 to 서버 모두 사용
• 예시 - MSA(MicroService Architecture) : JSON 형태로 데이터 통신을 하기 때문에 애플리케이션 별 언어가 달라도 서로 통신가능

📌 JSON의 구조

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

• snake_case, camelCase 모두 사용 가능
• key - value 형태

📖 서버 성능향상

💡 서버의 성능향상을 위한 두가지 방법

📌 Scale Up (수직적 확장)

• 단일 서버의 하드웨어의 사용을 높인다 ➝ 비용 증가 (cpu나 메모리의 스펙을 올린다)

• 요청에 대한 처리가 빨라진다

  ---

📌 Scale Out (수평적 확장)

• 같은 사양의 서버를 여러대 배치한다 ➝ 비용 증가 크지 않음
• 동시에 더 많은 사용자 요청을 처리할 수 있다

📖 통신상태 유지 여부

💡 클라이언트와 서버간의 통신상태 유지 여부에 따라 나뉘는 특성 *예시 - 수강생 (클라이언트) / 상담원 (서버)

📌 Stateful(상태 유지)

• 수강생 1명 : 상담원 1명 ➝ 클라이언트의 요청을 기억(상태 유지)한다

✔️ 문제점

• ① 같은 서버가 유지되어야 한다 (같은 상담원에게 요청해야~)

• ② 서버는 다양한 이유로 동작하지 않을 수 있음

• ③ 요청 트래픽이 많아지면 상태를 유지하는데에 리소스가 소모된다

  ---

📌 Stateless (무상태)

✔️ 장점

• 모든 요청을 하나의 서버에 보낼 필요가 없음 ➝ 수평적 확장 Scale Out

  ✔️ 단점

• 클라이언트가 데이터를 추가로 전송해야한다 ➝ 데이터양 증가 (비용이 증가될 수도)

  ✔️ 🌟 한계점

• ** 원칙** : 항상 서버의 확장성을 고려해 최대한 Stateless하게 만들어야 한다
• 한계 : but 전부 다 Stateless하게 만들 수는 없다 (상태유지가 필요한 로그인)
• *한계 극복 * : Cookie, Session, Token등으로 극복하며 상태유지는 최소화 하면 된다

📖 연결 유지 여부

💡 클라이언트-서버간 연결 유지 여부에 따른 특성

📌 Connection (연결)

• 클라이언트 수만큼 연결횟수가 늘어남 ➝ 자원 소모된다
• 클라이언트가 아무 요청이 없어도 연결은 유지한다 (수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 요청이 들어올 경우는 적다!)

✔️ 장점

• 새로운 연결을 안해도 된다, 그만큼 응답속도가 빨라진다

  ✔️ 단점

• 클라이언트가 지속적으로 요청을 보낸단 보장이 없는데도 해야함,, 자원 낭비!

  ---

📌 Connectionless (비연결)

• TCP/IP 연결 ➝ 요청-응답 ➝ 연결 해제 🌟 서버는 최소한의 자원만 사용하게 된다 ( 예를들어,, 인터넷이 끊겨도 보던 페이지는 그대로 보인다!)

✔️ 장점

• 당연! 자원 효율적 사용된다

  ✔️ 단점

• 요청이 추가될 때마다 연결(3 Way Handshake)을 새로 해야한다 ➝ 응답시간 증가
• 연결할 때마다 웹페이지의 정적자원을 전부! 다시 다운로드해야한다 ➝캐시, 브라우저 캐싱으로 해결 (쉽게말해 임시저장) 🌟해결방법 : 현재는** HTTP 지속연결(Persistent Connections)**로 문제를 해결한다.

💡 HTTP 지속연결(Persistent Connections)

• 모든 요청을 전부 응답한 후에 연결을 해제한다
• 연결 횟수는 Connectionless보다 적고, 속도는 더 빠르다!

📖 개요

📌 시스템 환경

• Java: 17
• JDK: 17.0.1
• IDE: IntelliJ

📌 요구사항

✔️ 필수기능

✔️ 도전기능

📌 Git Hub 링크 & ReadMe

📖 구현한 기능

📌 ** 실행예시**

✔️ 카테고리별 메뉴 출력

• 전체 메뉴를 카테고리별로 나누어 구성했고, 숫자 입력과 뒤로가기(0)번을 통해 필요한 카테고리로 쉽게 이동할 수있다.

✔️ 장바구니 기능

• 선택한 메뉴를 장바구니에 추가할 수 있고, 장바구니에 담긴 아이템 리스트와 현재 장바구니의 총 금액을 확인할 수 있도록 했다.

✔️ 주문하기

• 장바구니에 추가한 아이템들을 9번을 통해 주문할 수 있다.
• 주문 완료시 내가 주문한 아이템들과 총 금액을 알 수 있다. (주문 완료 시 장바구니는 초기화)

📖 고민했던 부분

📌 요구사항을 잘 지키고 있는가?

• 지난 과제 해설을 들으면서, 내가 과제의 요구사항을 준수하며 코딩했는지 다시 돌아보게 됐다. 레벨이 올라갈수록 요구사항을 제대로 지키는 게 중요하다는 걸 깨달았고, 이번에는 level 5까지의 필수 기능이 있는 만큼, 요구사항을 요약해 체크리스트처럼 정리하고 신경 쓰면서 구현하려고 했다.

📌 클래스 간의 관계

• 레벨이 올라갈 때마다 새로운 클래스가 추가되고, 기존에 만든 객체를 이동해야 하거나 클래스간의 관계를 변경하면서 계속 혼란스러웠고 객체의 위치까지 헷갈리기 시작했다. 그래서 최대한 클래스 다이어그램을 그리면서 진행하려고 노력했다.

📌 객체의 위치

• 가장 고민했던 건 메뉴 아이템 객체가 최종적으로 어디에 위치해야 하는지였다. 대분류-소분류 개념으로 접근하다 보니 상하 관계로만 생각하게 됐고, 나름 배운 개념을 활용해보겠다고 extends(상속)도 시도해봤다. 하지만 튜터님 피드백을 듣고 나서 내가 정반대로 접근했다는 걸 깨달았다.
• 마지막으로 요구사항을 다시 한 번 확인해보니, 메뉴는 메인에서 관리했어야 하는 듯 하지만.. 제출일 전날 병가로 출석하지 못했던 터라 이 부분을 적용하지 못한 게 아쉬움으로 남는다...🥹

📌 리스트 사용 방식

• 처음엔 메뉴 아이템을 카테고리별로 담은 리스트 3개와 카테고리 이름만 담은 리스트를 따로 만들었는데, 사실상 이 둘이 따로 존재할 필요가 없고 서로 연결되어야 하는데 이 부분 해결이 제일 헷갈렸던것 같다.
• 튜터님께서 전체 메뉴 리스트 하나면 충분하다고 하셨고, 리스트 하나를 이용해서 카테고리를 필터링하기 위해 MenuItem 클래스에서 카테고리 속성을 추가하고, 객체에 하나씩 입력해 보기도 했다. (이건 아니라는 생각이 들었다..) 최종적으로는 Menu 클래스에 속성과 생성자를 추가하고, Kiosk에서 Menu 객체를 생성하는 방식으로 진행했다.

📋 트러블 슈팅

❶ List 관리

▪️ 문제

• 객체들을 이리저리 이동하며 List의 관리 주체를 바꾸다보니 코드가 꼬였다.
• 처음 내가 원한 건 "리스트 안에 리스트 안에 리스트" 처럼 계층적으로 데이터를 관리하는 방식이었는데, 이 방식은 효율적이지 않았다. (그러나 여기에 집착하느라 시간을 많이 낭비했다) 원하던 데이터 구조를 만드려면 다른 자료구조(HashMap, Enum)를 활용하면 되려나..? 싶었으나 아직 미숙한 관계로 사용하지 않기로 결정했다.

▪️ 해결방법

• kiosk에서 menus(전체메뉴 리스트)를 사용하고, menu 객체 생성을 통해 카테고리 별로 필터링하기로 했다.

  ---

❷ 메서드 관리

▪️ 문제

• 최대한 반복되는 코드를 줄이고 메서드를 적극 활용하고 싶었지만, 입출력을 정리하는 것이 어려웠다.
• 계속 sout을 통해 수기로 출력하는 대신, 출력 기능을 메서드로 분리하고 싶었다. [전체 리스트 → 카테고리별 메뉴 → 특정 메뉴 선택] 과정에서 인덱스를 활용해 데이터를 가져오는 방법이 어려웠다. (menuItem의 selectMenuNum도 지금 보니 필요가 없다,,,😂)

▪️ 해결방법

• 메서드들도 분리하고, 향상된 for문과 index값, 리스트의 크기 .size를 활용했다.

💡 배운점

• 다양한 메서드들을 만들어 분리해 사용하는 것이 코드의 가독성을 높이고 중복 코드를 줄일 수 있다.

• 나중에 수정할 때도 쉽다.

  ---

❸ 장바구니 만들기

▪️ 문제

• 지난 과제에서 누적 연산을 했던 덕분에 처음엔 수월하게 구현했다. 그러나 착각도 잠시 누적 금액이 이상하게 계산되는 오류가 있었다.
• 예를 들어 8,000원짜리 메뉴를 2번 담았을 때, 16,000원이 되어야 하는데 (8,000) + (8,000 + 8,000) = 24,000원이 출력되는 것.
• 누적합 계산을 위해 += 연산자를 사용했었는데 계속 틀린 값이 나와서 반복문을 계속 뜯어봤다.

▪️ 해결방법

• totalPrice 값을 List<String>으로 관리하고 있었다. cart 초기화하면서 아무 생각 없이 복붙해서 만들었던 것,, ➡︎ int 타입으로 변경했다.

💡 배운점

• 생각없이 코드 복붙하지 말자 😇

• (팀원 분들과 해결했음) 해결이 안될 때는 다른 사람에게 보여주는 것도 나쁘지 않은 것 같다. 계속 이 코드를 봐서인지.. 이상한데 매몰되어 있어서인지 이 간단한 해결방법이 눈에 안들어오는 경우가 많았다.

  ---

❹ 메뉴판 금액, 장바구니 금액 차이

▪️ 문제

• 메뉴판 가격을 감성 카페마냥 4500원 -> 4.5 이런식으로 표기하고 싶어서 double을 사용했다.
• 장바구니에서는 4500원으로 출력하고 싶어서 int 타입으로 형변환을 했다. ➡︎ 세상에 뒷자리 백원단위가 사라지고 있었다.. 할인을 해주고 말았다..

▪️ 해결방법

• (int)(item.getPrice())*1000; ➡︎ (int)((item.getPrice())*1000);

💡 배운점

• 괄호 하나로 값이 완전히 달라질 수 있다. (어지간하면 정수형을 사용하자..)

  ---

❺ 예외 처리

▪️ 문제

• 기존에 if로 인덱스 값을 벗어난 숫자에만 예외처리를 해뒀었기 때문에 문자열을 입력하면 프로그램이 멈췄다.
• 예외처리를 카테고리 선택, 메뉴선택 등으로 기능을 나눴고, 고로 사용자에게 입력받은 숫자가 기능마다 다른 변수에 들어있었기에 수기로 일일히 try-catch를 여러번 작성하기로 했다 ➡︎ 코드가 지저분했다.

▪️ 해결방법

• 각 메서드에서 직접 try-catch를 쓰는 대신, inputInteger()를 만들어 사용했다.

• Integer.parseInt ➡︎ String타입의 숫자를 int로 바꿔준다, 이를 시도하며 예외를 잡는다!

  ---

❻ 디버깅

▪️ 문제

• List에서 값을 받아서 사용하거나 다른 클래스에서 가져오고 하다보니 출력이 안되거나 값이 없는 경우 발생, 알고보니 데이터 자체가 넘어오지 않았다(!)

▪️ 해결방법

• getter를 통해 확인해보기도 하고 list.size()를 찍어보면서 데이터가 어디서 안 들어오는지 일일히 확인했다.

💡 배운점

• 하나씩 데이터를 찍어보는 습관을 들이자. 돌다리도 두드려보고..

🌟 나의 회고

오타, 형변환, 대소문자 입력 같은 잔실수가 너무 많다. 또 중요한 것은 잔실수들이 야기하는 오류는 꼭 나중에 확인하게 되는데, 수정할때 어느부분에서 실수한건지 찾는게 더 힘든 것 같다. 항상 데이터를 가져오면 찍어보는 습관을 들이자.

아직도 요구사항 그대로! 설계하지 못하는 것 같다. 레벨별로 클래스 다이어그램을 그리는게 나름 도움이 됐다고 생각했었는데.. 그냥 공부자체를 더 해야할 것 같다.

과제를 진행하면서 시간이 여러모로 많이 부족했다. 나는 아직 강의 내용도 다 숙지하지 못한 것 같은데.. 부딪혀보듯 코딩해보는게 맞는건가? 이런 생각도 꽤 자주했다. 지금 과제를 제출하기 직전 느낀 점은, 과제를 하는 과정에서 강의자료를 뒤지고 나랑 비슷한 상황을 찾아 구글링을 하기도 하고 이것저것 시도하다 보니 자연히 체득하는 내용이 더 오래가고 잊어버리지 않을 것 같다. 또한 이번 과제때는 시간때문에 구현하지 못한 부분들이 있어 너무 아쉬웠으므로 다음엔 시간분배를 잘 해야겠다.

▪️ 자바 컬렉션 프레임워크 ▪️

💡 다양한 자료구조들을 쉽게 활용하도록 인터페이스와 구현체(ArrayList, HashSet, HashMap) 를 제공하는 집합

• Collection계열은 Collection 인터페이스를 중심으로 구성됨
• Map 계열은 Collection을 상속받지 않지만, 컬렉션 프레임워크에 포함

자바 컬렉션 프레임워크
 │
 ├── 📌Collection 인터페이스 (데이터 모음, 요소 중심)
 │     ├── List (순서O, 중복O)
 │     ├── Set (순서X, 중복X)
 │     ├── Queue (FIFO 구조)
 │
 ├── 📌Map 인터페이스 (키-값 쌍, 요소 중심X)
 │     ├── HashMap 등
 │
 ├── 📌기타 유틸리티
       ├── Iterator (반복자)
       ├── Collections (유틸 클래스, 정렬 등 제공)

📖 Collection

• 데이터 저장, 조회, 삭제, 정렬 기능등을 간편하게 구현할 수 있다
• 길이를 동적으로 변경할 수 있다 (배열과 다름)

ArrayList<Integer> arrayList = new ArrayList<>();
arrayList.add(10);
arrayList.add(20);
arrayList.add(30);
arrayList.add(40); // ✅ 정상 동작 (길이 제한 없음)

📌 ArrayList (순서유지 중복가능)

• List 인터페이스를 상속받고 있다

// List 를 구현한 ArrayList
ArrayList<String> names = new ArrayList<>();
names.add("Spartan");      // 1 번째 요소 추가
names.add("Steve");        // 2 번째 요소 추가
names.add("Isac");         // 3 번째 요소 추가
names.add("1");
names.add("2");

 // ✅ 순서 보장
System.out.println("names = " + names);

// ✅ 중복 데이터 허용
names.add("Spartan");
System.out.println("names = " + names);

// ✅ 단건 조회
System.out.println("1 번째 요소 조회: " + names.get(0)); // 조회 Spartan

// ✅ 데이터 삭제
names.remove("Steve"); 
System.out.println("names = " + names);

✔️ add() - 데이터 추가

• ()안에 추가할 값
• 중복 데이터를 허용한다

✔️ get() - 데이터 단건 조회

• ()안에는 인덱스 번호

✔️ remove() - 데이터 삭제

• ()안에 삭제할 데이터

📌 HashSet (순서없음 중복가능)

• Set 인터페이스를 상속받고 있다

// Set 을 구현한 HashSet
HashSet<String> uniqueNames = new HashSet<>();

// ✅ 추가
uniqueNames.add("Spartan");
uniqueNames.add("Steve");
uniqueNames.add("Isac");
uniqueNames.add("1");
uniqueNames.add("2");

// ⚠️ 순서를 보장 안함
System.out.println("uniqueNames = " + uniqueNames); 
uniqueNames.get(0); // ❌ get 사용 불가

// ⚠️ 중복 불가
uniqueNames.add("Spartan");
System.out.println("uniqueNames = " + uniqueNames); 

// ✅ 제거
uniqueNames.remove("Spartan");
System.out.println("uniqueNames = " + uniqueNames); 

✔️ add() - 데이터 추가

• ()안에 추가할 값
• 중복 데이터는 한번만 나옴

✔️ 데이터 단건 조회 불가 (get❌)

✔️ remove() - 데이터 삭제

• ()안에 삭제할 데이터

📌 HashMap (순서없음)

• Map 인터페이스를 상속받고 있다

// Map 을 구현한 HashMap
HashMap<String, Integer> memberMap = new HashMap<>();

// ✅ 추가
memberMap.put("Spartan", 15);
memberMap.put("Steve", 15); // ✅ 값은 중복 가능
memberMap.put("Isac", 1);
memberMap.put("John", 2);
memberMap.put("Alice", 3);

// ⚠️ 순서 보장 안함 
System.out.println("memberMap = " + memberMap);

// ⚠️ 키 중복 불가: 값 덮어쓰기 발생
memberMap.put("Alice", 5);
System.out.println("memberMap = " + memberMap);

// ✅ 조회: 15
System.out.println(memberMap.get("Steve"));

// ✅ 삭제 가능
memberMap.remove("Spartan"); 
System.out.println("memberMap = " + memberMap);

// ✅ 키 확인
Set<String> keys = memberMap.keySet();
System.out.println("keys = " + keys);

// ✅ 값 확인
Collection<Integer> values = memberMap.values();
System.out.println("values = " + values);

• 키(Key) - 값(Value) 구조로 데이터 저장
• 키(Key) 중복 불가 / 값(Value) 중복 가능

✔️ put("키", 값 ) - 데이터 추가

✔️ get("키") - 데이터 단건 조회

• 키값을 이용해 데이터 조회

✔️ remove("키") - 데이터 삭제

• 키값을 이용해 데이터 세트를 삭제

✔️ keySet() - 키 확인

• 모든 키값 무작위 순서로 나옴

✔️ values() - 값 확인

• 모든 벨류들 무작위 순서로 나옴

▪️ 제네릭 (Generic) ▪️

<T>타입 매개변수로 클래스나 메서드에 사용된다. 코드 재사용성, 타입안정성을 보장

📖 Generic Class

🌟 클래스의 선언부에 <T>가 선언된 클래스

[클래스 선언부]
public class GenericBox<T> { // ✅ 제네릭 클래스
    private T item;

    public GenericBox(T item) {
        this.item = item;
    }

    public T getItem() {
        return this.item;
    }
}

객체 생성시에 해당 타입을 <>에 넣는다 인스턴스 생성시에 타입소거후 타입이 결정된다

컴파일 시점에 타입소거가 된다 T -> Object 가 된다 getter 사용시에 알아서 다운캐스팅도 해줌 <>에 넣은걸로!

📖 Generic Method

메서드 선언부에 <T>가 선언된 것 클래스인 제네릭과 메서드인 제네릭은 별개이다 클래스의 타입매개변수와는 달라도 됨 별도로 동작한다

메서드 실행시 () 매개변수에 아무거나 들어가도 된다

▪️ 람다 ▪️

📖 익명 클래스

별도의 클래스파일을 만들지 않고 코드 내에서 일회성으로 정의해 사용하기 때문에 인터페이스나 클래스의 구현과 상속을 통해 구현한다

보통은 클래스를 만들어 사용하는데, 익명 클래스는 그냥 메인에서 바로 new로 정의해서 활용 필요할 때만 1회성으로 활용할수 있다

단점 : 코드가 좀 길어짐..

📖 람다 Lambda

익명클래스를 더 간결하게 표현하는 방법! 함수형 인터페이스를 통해 구현하는 것을 적극 권장한다 -> 하나의 추상메서드만 가져야한다

//함수형 인터페이스
@FunctionalInterface // ✅ 함수형 인터페이스 선언
public interface Calculator {

    int sum(int a, int b); // ✅ 오직 하나의 추상 메서드만 선언해야합니다.
}

// 람다 표현식
Calculator calculator1 = (a, b) -> a + b;

// 람다가 추론한 익명클래스
Calculator calculator1 = new Calculator() {
        @Override
        public int sum(int a, int b) {
                return a + b;
        }
};

함수형 인터페이스를 만들고, 람다 표현식을 쓰면 알아서 추론해서 익명클래스를 구현해준다!

📌 주의할 것

1. 꼭 함수형 인터페이스를 선언할 것
2. 하나의 추상메서드만 가지고 있을 것! (오버로딩을 통해 같은 메서드를 여러형태로 정의하지 말것)

@FunctionalInterface // ✅ 함수형 인터페이스 선언
public interface Calculator {
    int sum(int a, int b); // ✅ 오직 하나의 추상 메서드만 선언해야합니다.
    int sum(int a, int b, int c); // ❌ 선언 불가 에러발생!
}

여러개의 추상메서드가 있으면 컴파일러가 뭐가 진짜 sum인지 알수가 없어진다!

💡 오버로딩 : 같은 클래스내에서 동일한 메서드이름 사용 오버라이딩 : 부모클래스의 메서드를 자식클래스에서 재정의하는것

📖 람다식을 매개변수로 전달하는 방법

1️⃣ 익명클래스를 변수에 담아 전달

public class Main {
    public static int calculate(int a, int b, Calculator calculator) {
        return calculator.sum(a, b);
    }

    public static void main(String[] args) {

        Calculator cal1 = new Calculator() {
            @Override
            public int sum(int a, int b) {
                return a + b;
            }
        };

        // ✅ 익명 클래스를 변수에 담아 전달
        int ret3 = calculate(3, 3, cal1);
        System.out.println("ret3 = " + ret3); // 출력: ret3 = 6
    }
}

2️⃣ 람다식을 변수에 담아 전달

public class Main {

    public static int calculate(int a, int b, Calculator calculator) {
        return calculator.sum(a, b);
    }

    public static void main(String[] args) {
        Calculator cal2 = (a, b) -> a + b;

        // ✅ 람다식을 변수에 담아 전달
        int ret4 = calculate(4, 4, cal2);
        System.out.println("ret4 = " + ret4); // 출력: ret4 = 8
    }
}

3️⃣ 람다식을 직접 전달

public class Main {

    public static int calculate(int a, int b, Calculator calculator) {
        return calculator.sum(a, b);
    }

    public static void main(String[] args) {
        // ✅ 람다식을 직접 매개변수로 전달
        int ret5 = calculate(5, 5, (a, b) -> a + b);
        System.out.println("ret5 = " + ret5); // 출력: ret5 = 10
    }
}

▪️스트림▪️

데이터를 효율적으로 처리할 수 있는 흐름 선언형이라 가독성이 뛰어나다 데이터 준비 -> 중간연산 -> 최종연산 순으로 처리

보기 쉽게 3줄로 나열

// 1. 데이터 준비: 스트림 생성
Stream<Integer> stream = arrayList.stream();

// 2. 중간 연산 등록: 각 요소를 10배로 변환 로직 등록
Stream<Integer> mappedStream = stream.map(num -> num * 10);

// 3. 최종 연산: 최종 결과 리스트로 변환
List<Integer> ret2 = mappedStream.collect(Collectors.toList());

이것을 한줄로 표현할 수 있따

// ✅ 한 줄로 표현 가능
List<Integer> ret2 = arrayList.stream() // 1. 데이터 준비
    .map(num -> num * 10)               // 2. 중간 연산 등록
    .collect(Collectors.toList());  // 3. 최종 연산

스트림과 람다를 조합해서 활용하는 세가지 방법

public class Main {

    public static void main(String[] args) {

        // ArrayList 선언
        List<Integer> arrayList = new ArrayList<>(List.of(1, 2, 3, 4, 5));

        // 스트림 없이: 각 요소 * 10 처리
        ArrayList<Integer> ret1 = new ArrayList<>();
        for (Integer num : arrayList) {
            int multipliedNum = num * 10;
            ret1.add(multipliedNum);
        }
        System.out.println("ret1 = " + ret1);

        // 스트림 활용: 각 요소 * 10 처리
        List<Integer> ret2 = arrayList.stream().map(num -> num * 10).collect(Collectors.toList());
        System.out.println("ret2 = " + ret2);

        // 직접 map() 활용해보기
        // 1. 익명클래스를 변수에 담아 전달
        Function<Integer, Integer> function = new Function<>() {

            @Override
            public Integer apply(Integer integer) {
                return integer * 10;
            }
        };
        List<Integer> ret3 = arrayList.stream()
                .map(function)
                .collect(Collectors.toList());
        System.out.println("ret3 = " + ret3);

        // 2. 람다식을 변수에 담아 전달
        Function<Integer, Integer> functionLambda = (num -> num * 10);
        List<Integer> ret4 = arrayList.stream()
                .map(functionLambda)
                .collect(Collectors.toList());
        System.out.println("ret4 = " + ret4);

                // 람다식 직접 활용
        List<Integer> ret5 = arrayList.stream()
                .map(num -> num * 10)
                .collect(Collectors.toList());
        System.out.println("ret5 = " + ret5);
    }
}

스트림 중간 연산 함께 사용하기

List<Integer> arrayList = new ArrayList<>(List.of(1, 2, 3, 4, 5));

// ✅ filter() + map() 사용 예제
List<Integer> ret6 = arrayList.stream() // 1. 데이터 준비: 스트림 생성
        .filter(num -> num % 2 == 0)    // 2. 중간 연산: 짝수만 필터링
        .map(num -> num * 10)           // 3. 중간 연산: 10배로 변환
        .collect(Collectors.toList()); // 4. 최종 연산: 리스트로 변환

System.out.println(ret6); // 출력: [20, 40]

▪️스레드▪️

프로그램 내에서 독립적으로 실행되는 작업 단위! 싱글 스레드 -> 한번에 하나의 작업만 / 멀티스레드 -> 여러 작업 동시에 처리 ( 병렬로 수행)

📖 싱글 쓰레드

• 일꾼이 한명이기에 여러개의 작업이 잇다면 순차적으로 처리
• main()도 하나의 쓰레드이다

public class Main {

    public static void main(String[] args) {
        System.out.println("::: main 쓰레드 시작 :::");
        String threadName = Thread.currentThread().getName();

        // ✅ 하나의 작업 단위: 숫자를 0 부터 9 까지 출력
        for (int i = 0; i < 10; i++) {
            System.out.println("현재 쓰레드: " + threadName + " - " + i);
            try {
                Thread.sleep(500); // 0.5 초 대기
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        // ✅ 추가작업
        for (int i = 0; i < 10; i++) {
            System.out.println("현재 쓰레드: " + threadName + " - " + i);
            try {
                Thread.sleep(500); // 0.5 초 대기
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("::: 작업 끝 :::");
    }
}

📖 멀티 쓰레드

• 스레드 실행시에는 run() 호출하면 안돼고, start() 를 사용하자
• 결과가 병렬로, 스레드1,2를 번갈아가면서 작업이 처리된다

// ✅ Thread 클래스 상속으로 쓰레드 구현
public class MyThread extends Thread {

    @Override
    public void run() {
        String threadName = Thread.currentThread().getName();
        System.out.println("::: " + threadName + "쓰레드 시작 :::");
        for (int i = 0; i < 10; i++) {
            System.out.println("현재 쓰레드: " + threadName + " - " + i);
            try {
                Thread.sleep(500); // 딜레이 0.5 초
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("::: " + threadName + "쓰레드 종료 :::");
    }
}


--------------------

public class Main {

    public static void main(String[] args) {
        System.out.println("::: main 쓰레드 시작");

        MyThread thread0 = new MyThread();
        MyThread thread1 = new MyThread();

        // 1. thread0 실행
        System.out.println("::: main 이 thread0 을 실행");
        thread0.start();

        // 2. thread1 실행
        System.out.println("::: main 이 thread1 을 실행");
        thread1.start();

        System.out.println("::: main 쓰레드 종료");
    }
}

📌 join

• 위 예시에서는 메인스레드가 스레드를 실행시키자마자 끝나버렸음
• 조인 사용시 메인스레드가 다른 스레드가 작업을 끝낼때까지 기다리게 되기 때문에

• 총 작업시간을 측정할 수 있다

public class Main {

    public static void main(String[] args) {
        System.out.println("::: main 쓰레드 시작");
        MyThread thread0 = new MyThread();
        MyThread thread1 = new MyThread();

        // 시작시간 기록
        long startTime = System.currentTimeMillis();

        // 1. thread0 시작
        System.out.println("thread0 시작");
        thread0.start();

        // 2. thread1 시작
        System.out.println("thread1 시작");
        thread1.start();

        // ⌛️ main 쓰레드 대기 시키기
        try {
            thread0.join();
            thread1.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        long endTime = System.currentTimeMillis();
        long totalTime = endTime - startTime;
        System.out.println("총 작업 시간: " + totalTime + "ms");
        System.out.println("::: main 쓰레드 종료");
    }
}

📖 Runnable 인터페이스 활용

1. 유시보수성, 재사용성 향상
2. 기존 클래스를 확장가능

• 지금처럼 Thread를 상속받아서 MyThread를 구현하면?

• 실행로직(내가 만든) + 제어로직(start(),join(),,등) 이렇게 두가지 역할임

• Runnable을 활용하면? 실행로직을 별도 구현체로 분리 가능

• Thread : 제어로직 / Runnable 구현체 : 실행로직

1️⃣ 기본 사용 예시

public class MyRunnable implements Runnable {
    @Override
    public void run() {
        String threadName = Thread.currentThread().getName();
        for (int i = 0; i < 10; i++) {
            System.out.println("현재 쓰레드: " + threadName + " - " + i);
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

----------------------------------

public class Main {

    public static void main(String[] args) {

        MyRunnable task = new MyRunnable(); // ✅ 하나의 작업 객체 선언

                // ✅ 하나의 작업을 여러 쓰레드에서 공유
        Thread thread0 = new Thread(task); // 작업 객체 공유
        Thread thread1 = new Thread(task); // 작업 객체 공유

                // 실행
        thread0.start();
        thread1.start();
    }
}

2️⃣ 기존 클래스를 유지하면서 확장하는 예시

• Thread를 상속하면 Java는 다중상속을 지원하지 않기에 다른 클래스 상속은 불가능!
• Runnable은 인터페이스이므로 상속까지 해서 확장이 가능

public class MyNewClass { // ✅ 새로운 클래스 

    public void printMessage() {
        System.out.println("MyClass 기능 실행");
    }
}
----------

public class MyRunnable extends MyNewClass implements Runnable { // ✅ 다중 상속

...

----------

public class Main {

    public static void main(String[] args) {

        MyRunnable task = new MyRunnable();

        // ✅ 기존 클래스를 유지하면서 확장해서 활용
        task.printMessage(); 

...

📋 필수 요구사항

• Lv 1. 기본적인 키오스크를 프로그래밍해보자
• Lv 2. 객체 지향 설계를 적용해 햄버거 메뉴를 클래스로 관리하기
• Lv 3. 객체 지향 설계를 적용해 순서 제어를 클래스로 관리하기
• Lv 4. 객체 지향 설계를 적용해 음식 메뉴와 주문 내역을 클래스 기반으로 관리하기
• Lv 5. 캡슐화 적용하기

이번 과제에서 신경쓸 부분🥲 저번 과제 이후 클래스간의 역할을 정리하고 분리하는 작업이 얼마나 중요한지를 깨달았다. 각 레벨을 구현하기 전에는 항상 클래스의 역할을 정리하고 시작하기로 했다 ! 요구 사항을 잘 읽고 잘 지키자..

📝 나의 코드 리뷰하기

🌟 [ Level2 ]

📍 요구사항

• *MenuItem *
  • 클래스 생성 후 속성 입력
• *Main *
  • MenuItem을 통해 객체 생성 / 이름, 가격, 설명을 세팅
  • Array list로 아이템들을 추가

    Main (메뉴의 객체 생성)
     ├── MenuItem (메뉴 속성 등록)
    >   ```
    

📍 주요 코드

public class MenuItem  {

//    속성
    String name;
    double price;
    String detail;

//    생성자
    public MenuItem(String name, double price, String detail) {
        this.name = name;
        this.price = price;
        this.detail = detail;  

 // 개별 속성을 가져올 getter 메서드들
 ...

    }
}      

-------------------------------------

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

        List<Menuitem> menuitems = new ArrayList<>();

        menuitems.add (new Menuitem("ShackBurger", 6.9, "토마토, 양상추, 쉑소스가 토핑된 치즈버거"));
        menuitems.add (new Menuitem("SmokeBurger", 8.9, "베이컨, 체리 페퍼에 쉑소스가 토핑된 치즈버거"));
        menuitems.add (new Menuitem("CheeseBurger", 6.9, "포테이토 번과 비프패티, 치즈가 토핑된 치즈버거"));
        menuitems.add (new Menuitem("HamBurger", 5.4, "비프패티를 기반으로 야채가 들어간 기본버거"));


        for (Menuitem item : menuitems) {
            System.out.println( item.getName() + " | " + item.getPrice() + " | " + item.getDetail());
        }

        System.out.print("메뉴를 선택하세요 : ");
        int num = scanner.nextInt();

        // switch문으로 입력한 번호에 따라 선택한 버거 보여주기
        ...

💡 어려웠던 점

• 객체를 생성하고 List에 담아야 할때, 저렇게 객체 생성과 동시에 하는게 깔끔한듯 하다
• List의 데이터를 탐색할 때는 향상된 for문 을 사용하는 것 잊지말자..^^

🌟 [ Level3 ]

📍 요구사항

• Kiosk
  • 클래스 생성하기
  • start 함수로 입력,반복문 로직 만들기 (메인에서 하지말고)
    • 0 을 입력하면 뒤로가기되거나 종료
  • menuitem을 관리하는 리스트가 존재한다
  • List는 kiosk의 생성자를 이용하기

    Main 
          ├── Kiosk (시작-반복 로직, 객체 관리하기)
         ├── MenuItem (객체 등록하기)
    > 
    

주요코드

public class Main {
    public static void main(String[] args) {
        Kiosk kiosk = new Kiosk ();
        kiosk.start();
    }
}
----------------------------------------------

public class Kiosk {
    Scanner scanner = new Scanner(System.in);
    List<Menuitem> menuitem = new ArrayList<>();

    void wholeMenu () {
        menuitem.add(new Menuitem("ShackBurger", 6.9, "토마토, 양상추, 쉑소스가 토핑된 치즈버거"));
        menuitem.add(new Menuitem("SmokeBurger", 8.9, "베이컨, 체리 페퍼에 쉑소스가 토핑된 치즈버거"));
        menuitem.add(new Menuitem("CheeseBurger", 6.9, "포테이토 번과 비프패티, 치즈가 토핑된 치즈버거"));
        menuitem.add(new Menuitem("HamBurger", 5.4, "비프패티를 기반으로 야채가 들어간 기본버거"));
    }

    void start () {
        System.out.println("키오스크를 시작하려면 아무거나 입력하세요");
        scanner.nextLine();
        System.out.println("키오스크를 시작합니다");
        wholeMenu();

        for (Menuitem item : menuitem) {
            System.out.println(item.getName() + " | " + item.getPrice() + " | " + item.getDetail());
        }
        System.out.print("종료는 0 | ");
        System.out.print("메뉴를 선택하세요 : ");
        int num = scanner.nextInt();

        // 기존 main에서 쓰던 switch문 옮겨오기
        ...
        }
    }
}

💡 어려웠던 점

• main이 깔끔하다 못해 휑해졌다(ㅋㅋ)
• 키오스크로 객체,리스트를 옮겨와야 하는데 시작점이 아니라 그런지 바로 List에 넣을 수 없었다. 그래서 그냥 냅다 메서드로 만들어 버리고 start함수 실행시 메뉴를 쭉 불러오는 것으로 변경,,,
• switch 문에서 예외처리 다시 하기
• 카테고리가 추가되면 어쩌지..?

🌟 [ Level4 ]

📍 요구사항

• *Menu *
  • 클래스 생성 후 list 옮기기
  • Menuitem을 관리한다
  • (상위개념-"버거"같은) 카테고리 이름 필드를 만들자
  • 카테고리 이름을 반환하는 메서드가 구현되어야 한다

      Main 
          ├── Kiosk (입력,실행)
            ├── Menu (객체 등록하기)
              ├── MenuItem (객체 등록하기)
    >   ```
    

📍 주요 코드

• 일단 카테고리를 나눠야 하기 때문에 카테고리 별 리스트를 새로 선언했다

• 출력은 Kiosk에서 하고 리스트 관리는 Menu에서 하기 때문에 접근할 수 있도록 getter를 추가했다

• 이제 카테고리 선택 후에!! 출력을 해야하기 때문에 MenuItem의 getter와 List의 index을 활용해서 메뉴 출력 방식도 변경했다 (그러나 카테고리 출력은 아직도 수기 느낌,,ㅎ)

💡 어려웠던 점

• 처음에 kiosk에 생성했던 객체를 왜인지 menuitem으로 옮겨야 한다고 생각했다 (요구사항 다 까먹은듯) 아무튼 그래서 이상한데 사로잡혀 몇시간을 고민하다가,, 튜터님께 갔고 피드백 후에 생각을 고쳐먹을 수 ? 있었다 ^^
• 아직까지 요구사항이 전부 구현된지 모르겠다 뭘 모르는데 뭘 모르는지 모르는 이 기분,,
• 아직까지 코드가 지저분한 느낌이다. kiosk에 출력방식도 뿌듯하게 캡쳐해뒀는데 지금보니 맘에 안들고, list에 추가는 왜 저렇게 했으며... 카테고리 메뉴는 아직도 sout으로만 출력하고 있다..!

🥹 나의 회고

난 글렀다..... 뭘 모르는지 몰라서 질문도 못한다 코드가 뒤죽박죽 동물원이다...

📖 예외

프로그램 실행중 예상하지 못한 상황

📌 의도하지 않은 예외 (예상하지 못한 예외)

• 개발자가 예측하지 못했거나, 예외 처리를 해두지 않아서 프로그램이 비정상 종료되는 경우
• 사용자가 입력한 값이나 실행 중 상황에 따라 우연히 발생할 수도 있음 ➡ 예를 들어 10/0 같은 경우, (내가 해당 예외를 예측하지 않았다는 가정하에) 이 연산으로 인해 발생하는 예외는 내가 의도하지 않은 것임

📌 의도적인 예외 (내가 특정 조건에서 일부러 발생시킨 예외)

• 개발자가 특정한 조건에서 예외를 발생시키도록 throw 를 사용한 경우 ➡ 예를 들어, 미성년자의 접근등 비즈니스 규칙에 대한 예외상황을 정의해두고 제어하는 것 !

✔️ throw - 예외 발생시키기

• throw new IllegalArgumentException 사용하기
• 예시 ) 나이 제한이 있는 경우

  public class Main {
    public static void main(String[] args) {
        int age = 10;
        if (age < 18) {
                // ✅ 의도적으로 예외를 발생시키는 부분
            throw new IllegalArgumentException("미성년자는 접근할 수 없습니다!");
        }
        System.out.println("....");
    }
  }

  • 예외 발생 내용을 콘솔에서 알려준다 (가독성)

📖 예외의 구조와 종류

• 예외의 구조

❎ 언체크드 - RuntimeException

• 예외처리를 컴파일러가 확인하지 않는다 ➝ 예외처리 하지 않아도 컴파일 가능

  ✅ 체크드 - Exception

• 예외처리를 컴파일러가 확인한다 ➝ 예외처리하지 않으면 컴파일 오류 발생
• 🌟 반드시 예외 처리를 해야한다 🌟*

💡 예외의 전파

상위 메서드로 계속 퍼져서 프로그램 시작지점 메인까지 도달하게된다! 끝내 처리만 되면 프로그램은 종료되지 않을 것. (메인에서 처리해도 된다는 말)

📖 예외 처리

❎ UncheckedException

• RuntimeException 을 상속받는 모든 예외는 UncheckedException 이다
• 예외처리를 하지 않으면 비정상적인 결과가 나오거나 프로그램이 종료될 수 있다
  > 1️⃣ `RuntimeException()` 으로 `ExceptionPractice`를 예외 상황으로 가정. > > 2️⃣ **처리하지 않는 경우** - 언체크 예외가 호출되고 나면 예외가 발생하고, 실행되지 않는다 > > 3️⃣ **예외 처리** - 이 예시에서는 main에서 `try-catch`로 모든 예외를 처리해주고 있다 >- 예외는 전파되기에 메인에서 잡아줘도 된다! >- try문 안에서 if문을 사용하고, `throw new RuntimeException();`을 통해 특정 조건에서 예외를 발생시킬 수 있다

✅ CheckedException

• Exception 클래스를 직접 상속받는 모든 예외는 CheckedException이다 ( RuntimeException을 상속받는 예외 제외 )
• 예외처리는 필수, 하지 않으면 컴파일 오류 ① 바로 try-catch를 사용한다 ② throws로 다른 클래스에 책임을 전가 후에 처리한다
  > 1️⃣ `Exception()` 으로 `callCheckedException`를 예외 상황으로 가정. > 아직 처리되기 전이므로 컴파일 오류(빨간줄) 발생 ! > > > 2️⃣ **예외 처리** - 이번에는 예외 객체를 생성후에 처리했다!

📌 throw와 throws의 차이

1️⃣ throw ➡ 예외를 "직접" 발생시키는 키워드

✔ 개발자가 특정한 조건에서 예외를 발생시킬 때 사용
✔ throw new 예외클래스명("예외 메시지") 형태로 사용

📌 예제 (throw로 직접 예외 발생)

public class Example {
    public static void main(String[] args) {
        int age = 10;
        if (age < 18) {
            throw new IllegalArgumentException("미성년자는 접근할 수 없습니다!"); // 예외 발생
        }
        System.out.println("정상 실행됨");
    }
}

✔ throw는 즉시 예외를 발생시키고 프로그램을 중단시킴
✔ 특정한 조건에서 "잘못된 입력이 들어왔다!" 하고 예외를 던지는 역할

2️⃣ throws ➡ 메서드에서 "예외를 던질 수 있다"고 선언

✔ 메서드가 예외를 직접 처리하지 않고, 호출한 곳에서 처리하도록 예외를 넘기는 역할
✔ throws 예외클래스명 형태로 메서드 선언부에 사용

📌 예제 (throws를 사용해 예외를 호출한 곳에서 처리)

public class Example {
    // 메서드에서 예외를 던질 수 있다고 선언
    public static void checkAge(int age) throws IllegalArgumentException {
        if (age < 18) {
            throw new IllegalArgumentException("미성년자는 접근할 수 없습니다!");
        }
    }

    public static void main(String[] args) {
        try {
            checkAge(10); // 메서드 호출 → 예외 발생 가능
        } catch (IllegalArgumentException e) {
            System.out.println("예외 발생: " + e.getMessage());
        }
    }
}

✔ throws는 메서드가 예외를 직접 처리하지 않고, 예외를 던질 수 있다고 알리는 것
✔ 호출한 main() 메서드에서 try-catch로 예외를 처리

📍 throw와 throws 같이 쓰는 예제

throws로 예외를 넘기고, throw로 예외를 발생시키는 코드

public class Example {
    // throws로 예외를 넘길 수 있다고 선언
    public static void checkNumber(int num) throws IllegalArgumentException {
        if (num < 0) {
            throw new IllegalArgumentException("음수는 허용되지 않습니다!"); // throw로 예외 발생
        }
        System.out.println("정상적인 숫자입니다: " + num);
    }

    public static void main(String[] args) {
        try {
            checkNumber(-5); // 메서드 호출 → 예외 발생 가능
        } catch (IllegalArgumentException e) {
            System.out.println("예외 처리: " + e.getMessage());
        }
    }
}

✔ throw는 IllegalArgumentException을 실제 발생시키는 역할
✔ throws는 checkNumber(int num) 메서드가 예외를 던질 수 있다는 걸 선언하는 역할

throw 🆚 throws 비교 요약

• 예외를 던질 때 👉 throw
• 메서드에서 넘길때는 👉 throws

▪️ Optional ▪️

📖 Optional

• null을 안전하게 다루게 해주는 객체이다! ➝ 관련 예외인 *NullPointerException 을 방지
• Optional 객체는 값이 있을 수도 있고 없을 수도 있는 컨테이너다!

💡 NullPointerException (언체크드 예외)

• 단순 값이 없을 때보다도, 없는 객체의 메서드를 사용할 때 발생!
• 컴파일러가 확인해주지 않기 때문에 미리 예외 처리 해둬야함

• if문 을 활용해 논리적으로 예외를 잡을 수도 있지만,,! 하나씩 언제 다해?????

📌 Optional 활용하기

1️⃣ ofnullable

• 🌟ofnullable로 null이 담길 가능성이 있는 데이터를 감싸서 메서드에 넣자!🌟

• 이 메서드를 사용하게 되면 Optional 객체가 생성되므로, "어쩌면 null 값이 있을 수도 있겠다!" ➝ 가독성 높아짐

  ---

2️⃣ isPresent()

• Optional이 비었는지 아닌지 알 수 있다!

• True = 안 비었음 , False = 비어있음

  ---

3️⃣ get()

• Optional 안의 값들을 꺼내준다

💡 Optional 사용 예시

• student가 null이 아닌 경우 안전하게 가져오고, 게터 사용
• student가 null인 경우 메세지 출력

  public class Main {
    public static void main(String[] args) {
        Camp camp = new Camp();
  >
        //  Optional 객체 반환받음
        Optional<Student> studentOptional = camp.getStudent();✅
  >
        // Optional 객체의 기능 활용
        boolean flag = studentOptional.isPresent(); // ✅false 반환
        if (flag) {
            // 존재할 경우
            Student student = studentOptional.get(); // ✅ 안전하게 Student 객체 가져오기
            String studentName = student.getName();
            System.out.println("studentName = " + studentName);
  >
        } else {
            // null 일 경우
            System.out.println("학생이 없습니다.");
        }
    }
  }

객체지향의 4가지 특징을 정리했다 ! - 개인적으로 기초 개념정리를 더했다,,,

⬛️ < 객체지향 PART ❶ - 캡슐화 >

📖 캡슐화

• 객체의 정보를 외부에서 직접 접근하지 못하게 한다

• 접근제어자로 구현할 수 있다

  ---

📖 접근제어자

- | 접근제어자 | 클래스 내부 | 패키지 내부 | 상속한 클래스 | 전체 공개 | | --- | --- | --- | --- | --- | | public | ✅ | ✅ | ✅ | ✅ | | protected | ✅ | ✅ | ✅ | ❌ | | default | ✅ | ✅ | ❌ | ❌ | | private | ✅ | ❌ | ❌ | ❌ |

📌 접근제어자 활용 예시

• 1. 생성자 호출

  잘못 사용한 예시	올바르게 사용한 예시
  ❌ 오류 발생	문제없음 😁
  private 같은 클래스 내부에서만 사용가능하기 때문	public = 전체공개이기 때문에

• 2. 인스턴스 변수

  ✔️클래스	✔️메인

• 3. 인스턴스 메서드 접근

  ✔️클래스	✔️메인

💡 Tip 속성은 private로 사용하고, 한단계씩 풀어가자 생성자는 public으로 열어두면 매개변수를 활용해 객체를 생성하고 나면 속성은 변경이 안된다는 것 !! 기억하자

📖 데이터 접근 - getter, setter

• 캡슐화 때문에 데이터를 찾거나 접근이 곤란할 때 사용한다
• 당연 각 메서드를 만드는게 먼저임

📌getter : 데이터 찾을때

• 예시 ) 걔 이름이 머였더라? 너무 코드가 길어서 찾을 수 없어🥲

  String name = person.getName();
  System.out.println("이름:"+name); // 출력에 person의 이름 나옴

📌setter *: *캡슐화 된 데이터를 바꿀때

• 예시 ) 데이터를 보호했지만 ! 이름을 private으로 보호해뒀지만 바꿀래😉

  person.setName("steve"); // 원래 이름 "surin"
  String name2 = person.getName();
  System.out.println("이름:"+name2); // "steve"로 출력됨
  

  💡 세터 활용의 예시 (핵시설의 관리자)

  • ❌ 무분별한 세터 사용 - B를 입력하지 못하게 `String store`를 `private`으로 보호 ➡︎ `store`를 사용할 수 없음 - `setter`를 이용해 접근 가능하도록 함 ➡︎ 다시 "B"입력 가능해짐..🤔

  ---

  • *⭕️ 올바른 사용 * - 이 경우 "B"를 입력할 수 없도록, **`if문`을 함께 사용**한다 - 이외에도 세터를 남발대신 `private`으로 묶인 것들을 모아서 별도의 기능으로 만들어 제공하기 등등,, 다양한 방법이 있다

⬛️ < 객체지향 PART ❷ - 상속 >

📖 상속(Inheritance)

• 클래스간의 관계를 부모(상위) ,자식(하위) 관계로 바라본다 (부모의 속성과 기능을 자식이 물려받는다)
• 재사용성, 확장이 가능하다
• extends 로 상속 관계 표현 가능

📌 장점 1️⃣ - 재사용성

• 상속을 통해 부모 클래스의 인스턴스 멤버들에 접근할 수 있다
• 모든 부모의 요소를 자식이 활용할 수 있다

  💡 예시

• 이렇게 child 에는 아무것도 작성하지 않았으나, parent 의 모든 요소를 물려받고 있다

✔️super - 부모 인스턴스 호출

• 자식 클래스에서 명확하게 부모의 인스턴스를 호출하고 싶을 때
• super로 구현

  ✔️자식클래스	✔️메인클래스
  부모클래스의 familyName = "스파르탄"임	부모 클래스 무시, 자식 클래스에서 다시 할당한 값이 나온다
  super를 통해 부모의 인스턴스를 호출한다	부모 인스턴스가 명확하게 호출됨

  ---

  ✔️super() - 부모 인스턴스의 생성자

  • 부모의 생성자를 물려받았지만 *추가적으로 자식 클래스에서 생성자를 입력하고 싶을 때 *!

• 무조건 super()를 위에 두고 아래에 생성자를 만든다 (부모 생성자가 있어야 자식 생성자도 만들수 있음)

📌 장점2️⃣ - 확장

• 부모 클래스의 기능 유지 + 자식 클래스에서 기능을 더 확장

📖 메서드 오버라이딩(overriding)

• 부모 클래스의 메서드를 자식 클래스에서 변경하고 재정의
  • 메서드 이름, 매개변수, 반환타입이 일치해야한다
  • 접근제어자는 부모보다 강한 수준으로 변경가능
• @Override 로 구현

✔️부모클래스의 메서드	✔️자식클래스에서 재정의

📖 추상 클래스

• 계층 구조를 활용해서 하위 클래스에 특정 메서드 구현을 강제하기 위해 사용한다

  • 1️⃣ abstract 로 클래스 선언

    

  • 2️⃣ abstract 로 메서드 자식에게 강제 구현시키기

    부모 클래스	자식 클래스
    	@Override를 쓰고 작성하기

• 주의 ‼️ 추상클래스는 인스턴스화 할 수 없다!!!

추상클래스 vs 인터페이스 ? 🤔

• 인터페이스 : 표준을 제공 / 인스턴스 변수 사용불가
• 상속 : 계층적 구조 표현 / 속성이나 기능 재사용시 용이

⬛️ < 객체지향 PART ❸ - 추상화 >

📖 추상화

• 불필요한 정보를 제거하고 본질적인 특징만 남기는 것 (예를 들어, 고양이의 특성, 동물의 특성을 제외해주면 생명체라는 본질적 특성에 집중할 수 있다) ➡︎ 덕분에 유지보수성이 좋아진다

📌 인터페이스를 사용한 추상 계층 표현

• 나는 막연히 클래스끼리만 상속할 수 있다고 생각했는데,, 왜그랬지 인터페이스 > 인터페이스 > 클래스 이렇게도 상속이 된다 이런식으로 ! 주석에 달아놓은 것들이** 원래 해당 메서드가 선언된 클래스의 위치**다

📌 클래스를 사용한 추상 계층 표현

• 동일하게 상속을 통해 계층을 표현할 수 있다
• 추가로!! 메서드 오버라이딩을 통해 부모의 메서드를 재정의 할 수 있다

⬛️ < 객체지향 PART ❹ - 다형성 >

📖 다형성

• 상위 타입을 통해 여러 객체를 다룰 수 있다 (예시 - 동물을 통해 고양이 강아지를 다룬다) 약간 카테고리 느낌, 대분류 소분류 느낌
• 상속 구조 : Lifeform > Animal > Cat,Dog ➡︎ 다형성을 활용해서 Cat, Dog를 Animal 자료형에 넣어줄 수 있다!

📖 형변환

📌 업캐스팅

• 부모 타입으로 자식타입을 받을 수 있다 (스몰박스 > 큰 박스)

  💡 주의사항

• 자식 클래스의 고유 기능은 사용할 수 없다 ➡︎ 사용하려면 다운캐스팅

📌 다운캐스팅

• 부모데이터 타입을 다시 자식 데이터 타입에 넣어준다 (데이터 손실이 일어나기 때문에 자료형 명시해야함)

  💡 주의사항

• 자료형을 잘못써도 컴파일러가 감지하지 못하기 때문에 instanceof를 사용

📖 다형성 장점

• 한가지 타입으로 여러 데이터타입을 다룰 수 있다