객체지향?
객체지향 프로그래밍이란?
프로그래밍에서 필요한 데이터를 추상화 시켜 상태와 행위를 가진 객체로 만들고 객체들간의 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다.
추상화 vs 구체화
추상화 :
- 추상화는 필요한 부분만 강조하고, 불필요한 세부 사항을 숨기는 과정을 의미한다.
- 객체의 공통적인 특징(속성, 동작)을 정의하는 것이며, "무엇을 할 것인가?" 에 초점을 맞춘다.
구체화 :
- 구체화는 추상적인 개념을 실제 동작하도록 구현하는 과정을 의미한다.
- "무엇을 할 것인가?"가 정의된 추상화를 "어떻게 할 것인가?"로 변환하는 단계이다.
ex) 동물이 추상화 / 개가 구체화
예를 들어, '자동차'라는 개념을 생각해보겠습니다.
🚗 자동차는 핸들이 있고, 바퀴가 있고, 달릴 수 있습니다. 하지만 어떤 자동차든 공통적으로 가지는 특징만 뽑아낸다면,
'핸들이 있다','바퀴가 있다','달릴 수 있다'와 같은 기본적인 설계(추상화) 가 될 것입니다.그런데 자동차에도 여러 종류가 있죠?
스포츠카는 빠르게 달리고,
전기차는 배터리로 움직이고,
트럭은 짐을 나르는 데 특화되어 있습니다.
이렇게 각각의 자동차가 추상적인 개념을 기반으로 실제 동작 하도록 만든 것이 구체화입니다.💡 즉, 추상화는 설계도이고, 구체화는 그 설계도를 기반으로 만든 실제 자동차라고 생각하면 됩니다!
프로그래밍에서 이를 적용하면,
class나 interface를 사용해서 '자동차의 기본 개념(추상화)'을 정의하고,
extends나 implements를 통해 '스포츠카, 전기차 등의 구체적인 동작(구체화)'을 구현하는 방식으로 사용됩니다.
결국, 저는 개발자로서 핵심 개념을 추출해서 설계하고(추상화), 이를 기반으로 구체적인 객체를 구현하는 능력(구체화)을 갖추고 있습니다!"
객체지향 설계 원칙 5가지(SOLID)
단일 책임 원칙(Single responsibility principle)
개방-폐쇄 원칙(Open/closed principle)
소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 한다.
리스코프 치환 원칙(Liskov substitution principle)
상위 타입은 항상 하위 타입으로 대체할 수 있어야 한다.
인터페이스 분리 원칙 (Interface segregation principle)
의존관계 역전 원칙(Dependency inversion principle)
변경에 대비해라
구체적인 것(특정 오브젝트나 구현체)에 의존하면 그것이 변경될 경우 의존하는 것도 변경되어야 한다.(구체적인 것은 쉽게 변경된다)
그래서 추상적인 것에 의존하도록 구조를 변경하는 것이 의존성 역전(쉽게 변경되지 않는 추상적인 것에 의존해라)
첫째, 상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.
둘째, 추상화는 세부 사항에 의존해서는 안 된다. 세부 사항이 추상화에 의존해야 한다.
의존성 주입
의존성 주입이란?
필요로 하는 오브젝트들을 직접 만들지 않고 전달받도록 한다.
의존한다? 이건 코드 내에 관련 코드가 있어야한다.
예를 들면 상품Entity안에 상품옵션클래스가 들어있다? = 의존한다
상품옵션Entity에 상품클래스가 안들어있다 = 의존하지 않는다.
- 컨트롤러, 서비스, 리포지토리를 협력하게 만들려면?
👉 의존성 주입(특히 생성자 주입 방식)
- ⭐ 왜 직접 오브젝트를 만들지 않고 주입받지?
책임의 분리 - 서로 간의 영향을 최소화 (결합도를 낮추겠다)
- 근데 왜 주로 생성자 주입 방식만 사용하지?
생성자 주입방식
왜?
1. 테스트하기 편하다
- Setter 주입은 주입받는 객체가 변경될 가능성이 있는 경우에 사용하는데 실제로 변경이 필요한 경우는 극히 드물기 때문에
- 테스트 시 Mock 객체를 넣기 쉽움
- 순환 참조 에러를 컴파일 타임에 잡을 수 있음
OOP
OOP의 핵심 개념 4가지
추상화 (Abstraction)
불필요한 정보는 숨기고, 중요한 정보만 표현
예: 자동차의 운전자는 가속, 브레이크만 알면 되고, 엔진 내부 구조는 몰라도 됨.
캡슐화 (Encapsulation)
데이터(변수)와 기능(메서드)을 하나로 묶고, 외부에서 직접 접근하지 못하도록 제한
예: 클래스 내부의 private 변수는 외부에서 직접 접근 못함 → getter/setter로 조작
상속 (Inheritance)
기존 클래스를 확장해 새로운 클래스를 만드는 것
예: Bird 클래스 → Penguin, Eagle 등이 상속받아 공통 기능 재사용
다형성 (Polymorphism)
같은 인터페이스(또는 부모 클래스)를 통해 서로 다른 구현을 사용할 수 있음
예: Animal 클래스의 speak() 메서드는 Dog, Cat 클래스에서 각각 다르게 구현됨
클래스와 객체의 차이점
클래스란?
어떤 객체를 만들기 위한 틀이며, 객체가 가져야 할 속성과 기능을 정의
객체란?
- 먼저 클래스(Class)는 객체를 정의하는 틀 또는 설계도를 의미하고, 객체는 식별 가능한 개체 또는 사물을 뜻한다.
컨트롤러, 서비스, 리포지토리
controller의 역할
- API 스펙 결정
- HTTP 요청/응답 담당
- URL: API 서버 엔드포인트
- 파라미터(Path/Body/Query): 요청 시 데이터
- Return type: 응답 시 데이터
- 요청 시 필드 데이터 검증(validation
HTTP 요청/응답 담당
Service : 비지니스로직
리포지토리 : 데이터베이스(데이터 저장,읽기,조회,수정,삭제 모든 것을 관리한다)
데이터의 이동
자바 스크립트 -> 자바스크립트 오브젝트로 변환 -> http(json형태로 http를 거침)-> 자바 스프링 -> 자바 오브젝트(dto / entity) -> 데이터 베이스에 저장
- 데이터 베이스에 저장하려면 자바 오브젝트가 뭘로 바뀌어야 할까요?
- sql로 바뀐다. -> 데이터 베이스가 알아듣는 언어는 SQL이기 떄문에 SQL문으로 바꿔준다.
서버와 주고받는 방법
- Request body: 쓰기용 데이터 / 쓰기용 데이터는 매우 깐깐하게 체크한다.
- Path:특정 리소스를 가져올 때 사용하는게 url이고, 그걸 사용하는게 path
- Query: 읽기용 데이터 / 읽기를 위한 데이터 - 사용자가 페이지를 조회할 때
Entity와 dto
엔티티가 return 타입으로 사용하면 안되는 이유
1. Api spec이 바뀌면 안돼 - 왜? 개발은 협업 -> 협업하는 사람들과의 필요한 약속
2. 엔티티를 바꾸고 싶은데 api spec이랑 연결되면 절대 수정할 수가 없다. 그래서 retrurn타입에 엔티티를 사용할 수 없는것
Controller / service에서 써도 되냐 ? -> api와 연관이 있냐? -> 파라미터에 들어간다고 api와 연관이 되는건 아니다.
엔티티가 api spec과 같으면 안된다
로그인
로그인할 때의 문제점
- 회원가입 + 비밀번호 해쉬화 + id/pw 검증하면 + 로그인 유지
로그인은 토큰을 주고, 로그인 유지는 jwt를 만들어서 토큰으로 진짜 있는 토큰인지 검증을 한다.
http는 토큰을 저장할 수 없다 왜? http는 원래 그래…특성이.. http는 jwt를 만들어서 토큰을 검증만 하게 된다. - jwt는유효시간을 짧게 준다 왜냐면 서버에서 jwt을 만료시킬 방법이 없다. 모른다. 그래서 그 유효기간을 짧게 해서 빨리 빨리 만료되게 한다.
트랜젝션 격리 수준
트랜젝션이란?
-> 데이터베이스에서 하나의 작업 단위
: 모두 성공하거나 모두 실패하는 작업 묶음입니다.
- Atomicity (원자성)
작업은 ‘모두 수행’되거나 ‘아예 수행 안 함’ 중 하나
부분 실행은 x. - Consistency (일관성)
트랜잭션이 끝나면 데이터는 항상 일관된 상태여야 함
규칙이나 제약 조건이 지켜져야 한다는 뜻 - Isolation (격리성)
여러 트랜잭션이 동시에 실행될 때, 서로 간섭하면 안됨
한 트랜잭션이 끝나기 전까지 다른 트랜잭션은 그 작업 결과를 볼 수 없음 - Durability (지속성)
트랜잭션이 성공적으로 완료되면 그 결과는 영구적으로 저장됨
시스템이 갑자기 꺼져도 데이터가 사라지지 않아야 함.
트랜젝션 격리란?
-> 다른 트렌젝션의 영향을 받지 않겠다. 내가 읽고 있을 때는 바뀐내용을 모른다는 것
-> 중간에 커밋된 내용은 읽지 않겠다
- Read uncommitted : 격리 안하겠다
- Read committed: 커밋 된 것만 읽겠다. 롤백된 데이터는 읽지 않겠다. 아직 커밋도, 롤백도 안된 데이터는 안읽겠다는 의미
- Reapeatable read: 과거의 데이터에 머물러 있어서 팀원들이 커밋을 해도 신경안쓰고 과거의 저장소안에서 해결하고 한다는것 (깃허브 같은 느낌)
- Sereailzation : 순서대로 진행 - 별 신경 안써도됨
트랜젝션과 SQL의 관계
Rest Api vs Restful Api
Rest API
REST의 원리를 따르는 API를 의미
REST란?
- URI : 자원을 나타내야한다.
- ex) 동사보단 명사를 / 대문자보단 소문자를 / 언더바대신 하이픈를
- Method : 자원에 대한 행위(CRUD)
- Message : 행위에 대한 내용
이런 Rest의 원칙을 완전히 따르지 않는 것이 rest api 라면 철저하게 지키는 원칙이 Restful api이다.
즉, Restful api가 더 엄격하게 rest의 형태를 지켜야한다.
Join
데이터베이스에서 두 개 이상의 테이블을 연결해서 관련된 데이터를 함께 조회할 때 사용하는 기능
spring의 jpa를 활용해서 사용
Index
원하는 정보를 쉽고 빠르게 찾을 수 있는 기술
읽기를 사용할 땐, 좋은 성능을 주지만
쓰기가 많이 바뀔 땐 나쁘다
정규화
특징
- 중복 데이터 제거
- 데이터 이상 현상 방지 (삽입/수정/삭제 이상)
- 데이터 무결성 유지
- 논리적 구조로 관리 용이
Spring bean
- Spring 컨테이너가 관리하는 객체로, 의존성 주입, 생명주기 관리, 설정을 쉽게 하기 위해 사용됨
- @Service, @Repository, @Controller 클래스들이 전부 Bean
Spring Boot vs Spring 프레임워크
Spring Framework: 자바 기반의 애플리케이션 개발을 위한 프레임워크Spring Boot: spring을 더 쉽고 빠르게 사용할 수 있도록 도와주는 도구
MVC
| 구성 요소 | 역할 | Spring에서의 예 |
|---|---|---|
| Model | 비즈니스 데이터, 로직 | Model, DTO, Entity, Service, Repository |
| View | 사용자에게 보여질 화면 | Thymeleaf, JSP, HTML |
| Controller | 요청 받고 응답 결정 | @Controller, @RestController |
사용자 요청을 Controller가 받아서 비즈니스 로직을 처리한 후 Model 데이터를 View에 전달.
@RequestMapping
@RequestMapping: 모든 HTTP 메서드를 처리
@GetMapping, @PostMapping 등이 RequestMapping안에 속해있는 것
JPA
자바 객체와 관계형 데이터베이스(RDB)를 매핑해주는 ORM 기술 : SQL 없이도 자바 코드만으로 DB를 다룰 수 있게 해줌
(ORM = Object Relational Mapping → 자바 객체 ↔ RDB 테이블 자동 연결)
ex)
@Entity : 이 클래스는 DB 테이블과 연결된다!
@Id, @Column, @GeneratedValue 등으로 필드와 컬럼을 매핑
EntityManager 또는 Spring에서는 JpaRepository로 DB 조작
JPA vs Hibernate vs Spring Data JPA?
- JPA: 자바 진영의 표준 인터페이스 (API)
- Hibernate: JPA를 구현한 라이브러리 (가장 널리 쓰임)
- Spring Data JPA: JPA 위에 얹은 스프링 확장 라이브러리
→ JpaRepository 등 자동 기능 추가
ORM
프로그래밍 언어의 객체와 데이터베이스의 테이블을 자동으로 연결해주는 기술
SQL로 작성했던 데이터베이스에 의존하지 않고, 추상화작업이 가능하다.
동적 쿼리
where절 / 조건에 따라 쿼리가 유동적으로 바뀌는 것
Jquery
JavaScript 라이브러리 중 하나로, 웹 페이지를 쉽게 조작할 수 있게 도와주는 도구
but 현재는 잘 안씀. why? 리엑트 같이 프론트엔드 프레임워크가 새로 나와 편리하게 사용할 수 있기 때문에
postgreSQL 사용이유
오라클과 비교했을 때
- 무료, 오픈소스임
JSON, 파티셔닝, 트리거 같은 고급 기능들을 모두 지원하고 있어 상용 DB 못지않게 활용할 수 있음. 비용적인 부담 없이도 충분히 안정적이고 강력한 기능을 사용할 수 있음. - mySQL과 비교했을 때
| 항목 | PostgreSQL | MySQL |
|---|---|---|
| SQL 표준 준수 | 높음 (엄격하게 따름) | 낮음 (유연하나 일부 비표준) |
| 트랜잭션 및 동시성 | MVCC 지원, 트랜잭션 처리에 강함 | InnoDB 엔진 사용 시 MVCC 지원되지만 복잡한 처리에선 한계 |
| 데이터 무결성 | CHECK, 외래키 제약 등 완전 지원 | CHECK 제약 조건은 형식만 존재 (실제로는 무시됨) |
| 확장성 및 커스터마이징 | 확장 모듈, 사용자 정의 함수 등 커스터마이징 쉬움 | 커스터마이징은 제한적 |
| 복잡한 쿼리 처리 | CTE, 윈도우 함수 등 고급 SQL 처리에 강함 | 복잡한 쿼리 최적화에 약한 편 |
| JSON 지원 | JSON, JSONB로 고성능 제공 | JSON 컬럼은 있지만 인덱싱 제한적 |
| GIS 기능 | PostGIS 확장으로 강력함 | GIS 기능은 비교적 단순 |
| 속도 | 쓰기, 대용량 분석 등에서 강점 | 단순 읽기 성능은 빠른 편 |
| 사용 사례 | 데이터 분석, 복잡한 로직이 많은 앱 | 웹사이트, 블로그 등 가벼운 트래픽 중심 앱 |
- MySQL: 단순하고 빠르며, 웹 중심 애플리케이션에 적합
- PostgreSQL: 복잡한 로직, 데이터 분석, 정교한 데이터 무결성 보장이 필요한 서비스에 적합
- Oracle: 유료
MyBatis
SQL을 직접 작성해 자바 객체와 매핑해주는 프레임워크
(ORM보다는 SQL Mapper에 가까운 구조)
-> JPA처럼 자동 매핑보다는 SQL을 개발자가 명시적으로 제어할 수 있음
: 복잡한 쿼리가 많은 프로젝트에서 주로 사용
MyBatis:
- 복잡한 SQL 쿼리가 많은 시스템
- 성능 튜닝이 중요한 프로젝트
- SQL을 직접 제어하고 싶은 경우
JPA (Hibernate):
- 객체 지향적으로 개발하고 싶은 경우
- 간단한 CRUD 중심의 비즈니스 로직
- 유지보수와 개발 생산성을 높이고 싶은 경우
Final
이 변수는 수정할 수 없는 변수이다. 라고 저장해두는 변수
오버라이딩VS오버로딩
오버로딩
이름이 같은 함수를 여러 개 만들어 두는 것.
-> 원래 이름이 같은 함수가 있으면 호출할 때 구분이 안 되기 때문에 문제가 있다.
그러나 Java에서는 파라미터가 다르면 함수 이름이 같아도 구분함.
오버라이딩
상위 클래스에서 가지고 있는 함수를 자식 클래스에서 재정의 하는 것
