개발 고양이발

텍스트 - text, utext 1.1 기본적인 텍스트 출력 기능 //controller에서 model.addAttribute("data", "Hello World"); //으로 데이터를 보낸다 이런식으로 작성하면 된다. 1.2 escape 웹 브라우저에서는 th:utext [[...]] ㅡ> [(...)] 로 바꾸면 된다. 1.3 SpringEL 아래의 설명은 PDF파일을 참고했습니다. Object user.username : user의 username을 프로퍼티 접근 ㅡ> user.getUsername() user['username'] : 위와 같음 ㅡ> user.getUsername() user.getUsername() : user의 getUsername() 을 직접 호출 List users[0]...

데이터를 가지고 있는 쪽에 비즈니스 메서드가 있는 것이 좋다. 왜냐하면 응집력이 높아지기 때문이다. 생성로직을 변경할 때 setter를 사용하다보면 다양한 곳에서 값을 변경하게 되어 객체의 일관성이 떨어진다. 엔티티에서 setter를 사용하는 대신에 생성자를 통해 파라미터를 넘기는 것이 좋다. 그래서 protected OrderItem을 사용하면 방지할 수 있다. Lombok 어노테이션을 사용하여 protected 생성자를 생성할 수 있다. cascade (영속성 전이) 부모 엔티티가 영속화 될 때, 자식 엔티티도 같이 영속화 되고 부모 엔티티가 삭제 될 때, 자식 엔티티도 삭제가 되는 등 부모의 영속성 상태가 전이되는 것을 이야기한다. 도메인 모델 패턴 vs 트랜잭선 스크립트 패턴 도메인 모델 패턴: ..

폼 객체 사용 vs 엔티티 객체 사용 만약 요구사항이 단순하다면 엔티티를 그대로 사용해도 된다. 하지만 실무에서는 요구사항이 단순한 경우가 없다. 요구사항이 복잡해진다면 화면을 처리하기 위한 기능이 증가하게 된다. 결국 엔티티는 유지보수성이 어려워질 것이다. 그래서 API에 맞는 DTO, 폼 객체를 사용하고 엔티티는 최대한 순수하게 유지해야한다. 엔티티를 변경할 때는 항상 원하는 데이터만 변경할 수 있도록 변경 감지 기능을 사용해야한다. 컨트롤러에서 엔티티를 생성하지 말자. 트랜잭션이 있는 서비스 계층에서 식별자 ID와 변결할 데이터를(파라미터 or DTO) 명확하게 전달한다. 트랜잭션이 있는 서비스 계층에서 영속 상태의 엔티티를 조회하고 직접 그곳에서 데이터를 변경한다.

package jpabook.jpashop.service; import jpabook.jpashop.Member; import jpabook.jpashop.repository.MemberRepository; import lombok.AllArgsConstructor; import lombok.RequiredArgsConstructor; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; import java.util.List; @Service @R..

연관 관계 외래 키가 있는 곳을 연관관계의 주인으로 정해라. 엔티티 클래스 개발1 엔티티의 식별자 id를 사용하고 pk칼럼명을 member_id로 사용했다. id라고 작성해도 되지만 테이블의 타입을 구분하기 위해 테이블명 + id를 사용하였다. @Embeddable, @Embedded 중복되는 column들을 객체로 해결한다. @Embeddable 하나로 표현하고자 하는 개념에 해당하는 클래스를 생성한 뒤 클래스 상단에 @Embeddable을 입력한다. @Embedded 객체 필드를 생성하고, 필드 바로위에 @Embedded 어노테이션을 부여하면 된다. @Enumerated EnumType을 사용할 때 쓰는 어노테이션이다. 꼭 @Enumerated(EnumType.STRING)을 사용하도록 하자 defa..

코드 형식은 중요하다. 의사소통의 일환이기 때문에 개발자의 일차적인 의무이다. 적절한 행 길이를 유지하라 소스코드가 적어도 JUnit, fitness 와 같은 파일을 작성할 수 있다. 신문 기사처럼 작성하라 이름은 간단하면서도 설명이 가능하게 짓는다. 즉 읽기쉽고 자세하게 작성하여야 한다. 개념은 빈 행으로 분리하라 import문, 함수 사이 등에 빈행을 넣어야지 시각적으로 보기가 쉽고 가독성이 좋아진다. 세로 밀집도 세로 밀집도는 연관성을 의미한다. 변수같은 경우 밀집하게 적는다. 또한 쓸데없는 주석을 사용하여 밀집도를 떨어트리지말자 수직 거리 서로 밀접한 개념은 세로로 가까이 두어야 한다. 연관성이 깊은 두 개념이 멀리 떨어져 있으면 코드를 읽는 사람이 소스 파일과 클래스를 여기저기 뒤지게 된다. 변..

오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨린다. 주석은 나쁜 코드를 보완하지 못한다. 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가, 복잡하고 어수선하며 주석이 많이 달린 코드보다 훨씬 좋다. 코드로 의도를 표현하라 코드로 의도를 설명하기 어려운 경우는 있지만 충분히 표현할 수 있다. ex) // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if ((emplotee.flags & HOURLY_FLAG) && (employee.age > 65) if (employee.isEligibleForFullBenefits()) 좋은 주석 어떤 주석은 필요하거나 유익하다. 하지만 최고의 주석은 주석을 달지 않을 방법을 찾아낸 주석이다. 법적인 주석: 각 소스 파일 첫머리에 주석으로 들어가는 저작권..

작게 만들어라! 최대한 최대한 아주 작게 만들어야 한다. 한 2줄 3줄 4줄?? 정도가 좋다. if문 while문 등에 들어가는 블록은 한 줄이어야 한다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 추상화 수준이 하나인 단계만 순행한다면 그 함수는 한 가지 작업만 하는 것이다. 함수 당 추상화 수준은 하나로! 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일 해야 한다. 위에서 아래로 코드 읽기: 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. Switch 문 Switch문은 작게 만들기 어렵다.(if/else 도 마찬가지) 다형성을 이용하여 ABSTRACT FACTORY에 꽁꽁 숨겨 다형성 객체..

코딩을 하면서 함수, 변수, 패키지 등등 모든 곳에 이름을 직접 붙인다. 이렇듯 이름을 많이 사용하므로 잘 지어야한다. 의도를 분명하게 밝혀라 주석이 필요하지 않을 정도로 변수, 함수, 클래스명을 작성해야한다. ex) int d -> int elapsed time in days 그릇된 정보를 피하라 ex) 개발자에게 List는 특수한 의미이다. 그래서 실제로 List가 아니면 AccountList같은 변수명을 명명하지 않는다. 또한 소문자 o와 l은 조심해서 사용하자. 각각 0과 1로 보일 수 있기 때문에 혼란을 줄 수 있다. 의미 있게 구분하라 이상한 변수 사용하지 않기 ex) a1, a2, a3 ... 불용어 붙이지 않기 ex) the, a, an, ~s, ~es 등등 발음하기 쉬운 이름을 사용하라 ..

클린코드란? 가독성이 좋은 코드 --> 모든 팀원이 이해하기 쉽게 작성된 코드이다. 가독성이 중요한 이유 어떠한 코드를 변경하려고 할 때 코드 해석시간과 코드를 수정하는 비율이 10대 1 이라고 한다. 즉 이해하기 쉬운 가독성이 좋은 코드야말로 오류를 고치는데의 시간과 위험성을 줄일 수 있다. 왼쪽 그래프에서 시간이 지날 수록 생각했던 것보다 비용이 발생하고 오른쪽 그래프에서는 대응속도가 생각했던것보다 느리게 작동한다. 이러한 차이가 나오는 이유는 초기에 클린코드를 사용하기보다는 빠르고 쉬운 코드를 사용하기 때문이다. ex) copy&paste 내 코드로 보는 클린코드가 필요한 코드 이 문제는 백준 2108 문제이다. 이 코드에는 문제점이 있다. 1. 알수 없는 변수들 ex) n, data ... 2. ..