Jinnie devlog Jinnie devlog

@ManyToMany 사용을 되도록 피해야 한다고 배웠다. 그 이유는, 개발하다 보면 연결 테이블이 단순히 연결만 하고 끝나지 않는다. 조인 테이블 자체에 주문 시간, 수량 같은 추가 데이터가 많이 들어갈 수 있다. 하지만, 매핑 정보만 넣는 것이 가능하고, 추가 정보를 넣는 것 자체가 불가능하다. 그리고 중간 테이블이 숨겨져 있기 때문에 예상하지 못하는 쿼리들이 나간다. 이러한 문제점들 때문에 실무에서는 사용하면 안된다고 한다. 해결 방법으로는, 연결 테이블용 엔티티를 추가한다. 사실상 연결 테이블을 엔티티로 승격시킨다. 그리고 @ManyToMany를 각각 일대다, 다대일로 관계를 맺어준다. JPA가 만들어주는 숨겨진 매핑테이블의 존재를 밖으로 꺼내는 것이다. 등이 있다. 나는 그럼에도 다대다 관계를 ..

Entity Entity 클래스는 실제 DB 테이블과 매핑되는 핵심 클래스로, 데이터베이스의 테이블에 존재하는 컬럼들을 필드로 가지는 객체이다. DB 테이블과 1:1로 매핑되며, 테이블이 가지지 않는 컬럼을 필드로 가져서는 안된다. Entity는 데이터베이스 영속성(persistent)의 목적으로 사용되는 객체이기 때문에, Entity 클래스가 변경되면 여러 클래스에 영향을 줄 수 있다. 이러한 이유로, Entity에서는 setter 메서드의 사용을 지양해야 한다. https://jinniedev.tistory.com/6 Setter 사용을 지양해야 하는 이유 Setter 사용을 지양해야 한다. 이유는 여러가지가 있지만, 가장 큰 두 가지 이유는 1. Setter를 사용하면 값을 변경한 의도를 파악하기 ..

1697(숨바꼭질), 5014(스타트링크) 두 문제 모두 큐를 활용한 BFS 방식의 문제다. 이동할 수 있는 거리만큼의 for문을 돌며, 큐에 삽입하고 이동거리를 +1씩 해주며 최종 목적지의 이동거리를 구하였다. 똑같은 위치를 반복해서 방문하게 되면, 필요없는 작업을 하게되어 visited 배열을 통해 한번만 방문하도록 하였다. 백준 1697 숨바꼭질 from collections import deque def bfs(s): q = deque([s]) visited[s]=1 while q: cur = q.popleft() if cur == K: return count[K] for i in (cur-1, cur+1, cur*2): if 0

배낭 문제 배낭에 담을 수 있는 무게의 최댓값이 정해져 있고, 일정 가치와 무게가 있는 짐들을 배낭에 넣을 때 가치의 합이 최대가 되도록 짐을 고르는 방법을 찾는 문제이다. 배낭문제는 짐을 쪼갤 수 있는 경우(무게가 소수일 수 있는 경우)와 짐을 쪼갤 수 없는 경우(이 경우 짐의 무게는 0 이상의 정수만 가능) 두 가지로 나눌 수 있는데, 짐을 쪼갤 수 있는 경우의 배낭문제를 분할가능 배낭문제(Fractional Knapsack Problem), 짐을 쪼갤 수 없는 경우의 배낭문제를 0-1 배낭문제(0-1 Knapsack Problem)라 부른다. https://ko.wikipedia.org/wiki/%EB%B0%B0%EB%82%AD_%EB%AC%B8%EC%A0%9C 배낭 문제 - 위키백과, 우리 모두의..

다음과 같이 JPA에서 제공하는 findById 메소드를 이용하여 해당하는 StudyGroup을 가져오려고 하였는데, 컴파일 에러가 나타났다. 아래 처럼 Optional로 리턴타입을 감싸줌으로써 컴파일 에러를 해결할 수 있다. 원인은 CrudRepository 인터페이스에 있다. Repository 인터페이스를 만들 때 JPA를 사용하기 위해 JpaRepository를 상속받는다. JpaRepository 인터페이스의 find와 관련된 메서드에는 CrudRepository 를 확인하라고 적혀있다. CrudRepository 인터페이스의 findById 메서드를 확인해보면 리턴값이 Optional로 고정되어있다. Optional을 사용하면 좋은 점이 무엇이 있을까? Optional은 반복적인 null 처리..

Setter 사용을 지양해야 한다. 이유는 여러가지가 있지만, 가장 큰 두 가지 이유는 1. Setter를 사용하면 값을 변경한 의도를 파악하기 어렵다. public Member updateMember(long id) { final Member member = findById(id); member.setFistName("value"); member.setLastName("value"); return member; } 단순히 이렇게 setter로 값을 변경했을 때, 시간이 지나고 다시 위 코드를 봤을 때는 값을 왜 변경하게 되었는지 알기위해 코드를 역추적해서 찾아가야 한다. 2. 객체의 일관성을 유지하기 어렵다. 회원의 이름을 변경하는 메서드를 만들었다고 가정했을 때 무작정 setter로 값을 변경하게 되..

절대로 패스워드를 평문으로 저장해서는 안된다. - 해당 서비스의 관리자가 DB에서 모든 사용자의 비밀번호를 볼 수 있으며 DB가 노출되는 경우 공격자에게 계정 정보가 넘어갈 수 있다. - id와 password를 동일하게 여러 곳에서 사용하는 경우가 많아서 추가적인 피해가 발생할 수 있다. PasswordEncoder Spring Security 에서는 비밀번호를 안전하게 저장할 수 있도록 비밀번호의 단반향 암호화를 지원하는 PasswordEncoder 인터페이스와 구현체들을 제공한다. public interface PasswordEncoder { // 비밀번호를 단방향 암호화 String encode(CharSequence rawPassword); // 암호화되지 않은 비밀번호(raw-)와 암호화된 비..

Spring Boot, JPA 를 사용한 사이드 프로젝트를 진행하며 새로 알게된 개념 혹은 헷갈리는 내용들을 정리해보았다. 1. EqualsAndHashCode (of="id") 연관 관계가 복잡해질 때, @EqualsAndHashCode에서 서로 다른 연관 관계를 순환 참조 하느라 무한 루프가 발생하고, 결국 stack overflow가 발생할 수 있기 때문에 주로 id 값만 비교하도록 사용한다. https://jinniedev.tistory.com/2 @EqualsAndHashCode, equals, hashCode equals 와 hashCode란? equals 와 hashCode는 Object 클래스에 정의되어 있다. Object 클래스의 자식인 Java의 모든 객체는 Object 클래스에 정의된..