20일차. IT 개념 정리

 

🔹 생성: “ 싱글인 빌더가 프로이다 팩토리 추상훈~!팩토리 ”

→ 싱글톤, 빌더, 프로토타입 팩토리, 추상팩토리(5)

🔹 구조: “ 구조는 컴포즈에서 어댑터 브릿지 쓰고 플라이웨이트 마시고 데코하고 브릿지, 프록시, 퍼사드(브프퍼)”

              →  컴포짓, 어댑터, 플라이웨이트, 데코레이터, 브릿지, 프록시, 퍼사드(7)

 

🔹 행동: “전책임을 상태로 옵저버커먼드메멘토템플릿 이인미비-” →

전략, 책임, 상태, 옵저버, 커맨드, 메멘토, 템플릿 메서드

이터레이터(반복자) ,인터프리터(번역가), 미디에이터(중재자), 비지터(방문자)- (11)

 

---

 

인터페이스 빼고 interface

엔티티 모두 오브젝트(객체)로 이루어져 있음

 

이제 부터 entity 안쓰고 생략할 것임

VO는 다 삭제할 예정

 

이제부터 엔티티는 엔티티로 부르지만 사실은 엔티티를 핸들링하는 역할

dto가 객체이고, vo역할도 다 할것임

 

생성패턴은 빌더로 할거니까 DTO에 builder 넣기

 

실행순서는 컨- 서- 레- 엔 -DB

 

 

---

⚖️ 스칼라(Scalar)

• 의미:
  방향 없이 크기(값) 만으로 표현되는 물리량
• 예시:
  • 질량: 60kg
  • 온도: 25℃
  • 시간: 10초
  • 속력: 80km/h
• 특징:
  덧셈, 뺄셈, 곱셈 등 단순한 수학 연산 가능
• 수학적 표현:
  그냥 숫자 하나로 표현 → 예: 5, 3.2, -7

📘 비유:
스칼라는 “양”만 있는 값이에요.

예를 들어, “5m를 이동했다”라고만 하면 어디로 갔는지 알 수 없죠 → 스칼라

---

🧭 벡터(Vector)

• 의미:
  크기와 방향을 함께 가지는 물리량
• 예시:
  • 속도: 시속 80km, 북쪽 방향
  • 힘: 10N, 오른쪽 방향
  • 가속도, 전기장, 자기장 등
• 특징:
  방향이 있으므로 덧셈/뺄셈 시 방향도 고려해야 함
• 수학적 표현:
  (x, y, z) 같은 좌표 형태로 표현 → 예: →v = (3, 4)
  (여기서 크기는 √(3² + 4²) = 5)

📘 비유:
벡터는 “양 + 방향”이 있는 값이에요.

“5m를 동쪽으로 이동했다” → 벡터

---

🔍 한눈에 비교

구분스칼라 (Scalar)벡터 (Vector)

구성 요소	크기만 있음	크기 + 방향
예시	질량, 시간, 온도, 에너지	속도, 힘, 가속도, 변위
표현 방법	숫자 하나	좌표나 화살표
연산 방식	단순 수학적 연산	크기와 방향 모두 고려
그래프 표현	점(또는 길이 없는 값)	화살표(방향과 길이)

---

JPA에서 크로스 엔티티는 무슨 GOF 디자인 패턴에 가까운가?

무료 한국어 GPT의 말:

좋은 질문이에요 👍
JPA(Java Persistence API) 에서 “크로스 엔티티(Cross-Entity)” 라는 개념은 여러 엔티티(Entity)가 서로 연관 관계를 맺거나, 하나의 비즈니스 로직이 여러 엔티티를 아우르며 동작하는 경우를 말하죠.
이런 구조는 단순히 ORM(Entity 매핑) 이상의 설계 관점이 필요하기 때문에,
몇 가지 GoF 디자인 패턴과 밀접한 연관이 있습니다.

---

🧩 1. 핵심적으로 닮은 패턴: Mediator(중재자) 패턴

🎯 개념 요약

“객체들이 직접 서로 통신하지 않고, 중재자를 통해 협력하도록 만드는 패턴.”

• JPA의 크로스 엔티티 로직은 여러 엔티티가 서로 영향을 주고받을 때,
  엔티티끼리 직접 의존하지 않도록 서비스 레이어나 도메인 서비스가 중재자 역할을 합니다.

💡 예시

 

@Service public class OrderService { private final OrderRepository orderRepository; private final PaymentRepository paymentRepository; @Transactional public void processOrder(Long orderId) { Order order = orderRepository.findById(orderId).orElseThrow(); Payment payment = paymentRepository.findByOrderId(orderId); // 두 엔티티가 서로 직접 연결되지 않게 "중재" 역할 수행 if (payment.isPaid()) { order.setStatus(OrderStatus.CONFIRMED); } } }

➡ 여기서 Order와 Payment 엔티티는 직접 의존하지 않고,
OrderService가 **중재자(Mediator)**로 작동합니다.

따라서 크로스 엔티티 로직은 Mediator 패턴의 철학과 거의 동일합니다.

 

📚 정리

패턴크로스 엔티티와의 관계설명

Mediator (중재자)	⭐ 가장 밀접	여러 엔티티 간 협력을 중재자(서비스)가 관리
Facade (퍼사드)	자주 함께 사용	복잡한 엔티티 로직을 단일 진입점으로 단순화
Observer (옵저버)	이벤트 기반 설계 시	한 엔티티의 변경이 다른 엔티티에 자동 반응
Command (커맨드)	트랜잭션 단위로 묶을 때	여러 엔티티 작업을 하나의 명령 객체로 처리

---

✅ 결론

JPA의 크로스 엔티티 설계는 본질적으로 “Mediator 패턴”에 가장 가깝습니다.

• 서비스 레이어가 여러 엔티티 간의 상호작용을 중재
• 엔티티 간 직접 의존을 최소화
• 코드 응집도는 높이고 결합도는 낮추는 구조

 

 

 

---

 

📊 정리 비교표

구분PK (기본키)UNIQUE (고유 제약)

중복 가능?	❌ 불가능	❌ 불가능
NULL 가능?	❌ 불가능	⭕ 가능
테이블당 개수	1개만 가능	여러 개 가능
주로 쓰는 목적	행 구분 (식별자)	특정 값의 고유성 유지

 

 

🧭 데이터베이스 제약 조건 & 인덱스 비교표

구분PK (Primary Key)FK (Foreign Key)UNIQUEINDEX

의미	각 행(Row)을 유일하게 식별하는 기본 키	다른 테이블의 기본키를 참조하는 외래 키	특정 컬럼 값의 중복을 막는 제약	데이터 검색 속도를 높이기 위한 구조
중복 허용	❌ 불가능	⭕ 가능 (참조 값만 유효해야 함)	❌ 불가능	⭕ 가능
NULL 허용	❌ 불가능	⭕ 가능	⭕ 가능	⭕ 가능
개수 제한	1개만 가능	여러 개 가능	여러 개 가능	여러 개 가능
주요 목적	데이터 식별	데이터 연결(참조)	데이터 고유성 유지	데이터 조회 속도 향상
자동 인덱스 생성	⭕ 자동 생성됨	❌ (필요시 수동)	⭕ 자동 생성됨	⭕ 직접 생성
삭제/변경 시 영향	자식 테이블의 FK 제약 영향 가능	부모 테이블 데이터 변경 제한	없음	없음