잠깐 읽은 기술글

객체지향 설계(Object-Oriented Design, OOD)

키오스크 프로그래밍
https://velog.io/@alsem17/%ED%82%A4%EC%98%A4%EC%8A%A4%ED%81%AC-%EA%B3%BC%EC%A0%9C-Lv14

객체지향 설계는 객체(Object)와 클래스(Class)를 기반으로 소프트웨어를 설계하는 방법론이다.
소프트웨어를 여러 개의 독립적인 객체로 나누고, 객체 간 관계를 정의하여 유지보수성과 확장성을 높이는 게 목표이다.

1. 캡슐화(Encapsulation)

• 데이터(속성)와 기능(메서드)을 하나의 객체 안에 묶는 것
• 객체 내부의 데이터를 외부에서 직접 접근하지 못하도록 보호(private, protected 사용)
• getter/setter 메서드를 통해 데이터에 접근

class Car {
    private String model;

    public Car(String model){
        this.model = model;
    }

    public String getModel() { // 데이터 보호(Getter 사용)
        return model;
    }
}

장점: 데이터 보호, 코드 변경 최소화

2. 상속(Inheritance)

• 기존 클래스를 확장하여 코드를 재사용하는 개념
• 부모 클래스(슈퍼 클래스)의 속성과 메서드를 자식 클래스(서브 클래스)가 상속받음

class Animal {
    void makeSound(){
        System.out.println("동물이 소리를 냅니다.");
    }
}

class Dog extends Animal {
    void bark() {
        System.out.println("멍멍!");
    }
}

장점: 코드 재사용, 유지보수 용이

3. 다형성(Polymorphism)

• 같은 메서드를 여러 클래스에서 다르게 구현 가능
• 메서드 오버라이딩(Method Overriding) → 부모 클래스의 메서드를 자식 클래스에서 재정의
• 메서드 오버로딩(Method Overloading) → 같은 이름의 메서드를 다른 매개변수로 여러 개 정의 가능

4. 추상화(Abstraction)

• 불필요한 정보를 숨기고 핵심 기능만 노출하는 것
• 추상 클래스(Abstract Class)와 인터페이스(Interface)를 활용하여 구현

interface Animal {
    void makeSound(); // 메서드만 정의(구현 x)
}

class Dog implements Animal {
    public void makeSound() {
        System.out.println("멍멍!");
    }
}

장점: 코드의 의존성을 낮추고, 유지보수 용이

ELK 서버 구성하여 AWS와 연동

https://velog.io/@minu1117/%EC%A7%91%EC%97%90%EC%84%9C-%EB%82%A8%EC%95%84-%EB%8F%84%EB%8A%94-%EB%85%B8%ED%8A%B8%EB%B6%81%EC%9C%BC%EB%A1%9C-ELK-%EC%84%9C%EB%B2%84%EB%A5%BC-%EA%B5%AC%EC%84%B1%ED%95%98%EC%97%AC-AWS%EC%99%80-%EC%97%B0%EB%8F%99%ED%95%B4%EB%B3%B4%EC%9E%90

ELK 서버는 Elasticsearch, Logstash, Kibana의 약자로 로그 및 데이터 분석을 위한 오픈 소스 스택을 의미한다.
이 3가지 도구를 조합해 로그 수집, 저장, 검색, 시각화를 수행할 수 있다.

1. ELK 스택 구성 요소
   ELK는 크게 3가지 주요 컴포넌트로 구성된다.

구성요소	설명
Elasticsearch	검색 및 데이터 저장(빠른 검색 & 분석)
Logstash	로그 수집 및 처리(데이터 변환 및 전처리)
Kibana	데이터 시각화(대시보드 및 그래프)

2. ELK 스택 동작 과정
   ELK 서버의 기본 동작 과정은 다음과 같다.
   1. Logstash
   • 로그 파일, 데이터베이스, 애플리케이션 로그 수집
   • 필터링, 파싱(Parsing), 변환 후 Elasticsearch로 전달
   • (예: 웹서버 로그, 시스템 로그 등)
   2. Elasticsearch
   • Logstash에서 전달받은 데이터를 색인(Indexing) 및 저장
   • REST API로 검색 및 조회 가능
   3. Kibana
   • Elasticsearch의 데이터를 대시보드 형태로 시각화
   • 검색 및 분석 가능

Spring JPA 영속성 컨텍스트(Persistence Context)

https://velog.io/@seongwon97/Spring-Boot-%EC%98%81%EC%86%8D%EC%84%B1-%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8Persistence-Context

JPA 엔티티의 생명주기(Lifecycle)
JPA 엔티티는 4가지 상태를 갖는다.

1. New(비영속 상태)

• JPA가 관리하지 않는 상태
• new 키워드로 엔티티 객체를 생성했지만 아직 DB와 연결되지 않은 상태
• persist()를 호출하면 Managed(영속 상태)로 변환됨

Member member = new Member(); // 비영속 상태 (New)
member.setName("홍길동");

2. Managed(영속 상태)

• JPA가 관리하는 상태
• persist()를 호출하면 영속성 컨텍스트에 저장되고, 이후 자동으로 DB와 동기화 가능
• find()나 JPQL을 사용하면 DB에서 조회한 객체도 Managed 상태
  상태 변화
• persist() -> New -> Managed(DB엔 아직 반영되지 않을 수도 있음)
• find(), JPQL -> DB에서 조회하면 자동으로 Managed 상태
• 변경 감지(Dirty Checking): Managed 상태의 객체는 값이 변경되면 자동으로 DB에 반영됨

em.persist(member); // Managed 상태
member.setName("김철수"); // 값 변경 → 트랜잭션 커밋시 자동 반영(Dirty Checking)

3. Removed(삭제 상태)

• remove()를 호출하면 Removed 상태가 됨
• 트랜잭션이 커밋될 때 실제로 DB에서 삭제됨

em.remove(member); // Removed 상태

아직 flush() 또는 commit()을 실행하지 않았다면 DB엔 반영되지 않음

4. Detached(준영속 상태)

• JPA의 관리에서 벗어난 상태
• 영속성 컨텍스트에서 분리된 상태이므로 변경해도 DB에 반영되지 않음
• detach(), clear(), close() 등을 호출하면 Detached 상태가 됨
• merge()를 호출하면 다시 Managed 상태로 복귀 가능

em.detach(member); // Detached 상태 → 변경 감지 안 됨
member.setName("이순신"); // 변경해도 DB 반영되지 않음

정리하면

New → persist() → Managed
Managed → remove() → Removed
Managed → detach()/clear()/close() → Detached
Detached → merge() → Managed

Spring JPA에서 트랜잭션 관리시, 대부분의 객체는 자동으로 Managed 상태에서 관리됨
변경 감지(Dirty Checking)로 Managed 상태에선 값을 변경하면 자동으로 반영됨
Detached 상태에선 변경해도 DB에 반영되지 않음(merge 필요)