Dev Log

1️⃣ 빌더 패턴 💚 빌더 패턴 복잡한 객체 생성 과정 및 표현 방법을 분리해, 동일한 생성 절차에서 서도 다른 표현 결과를 만들 수 있게 하는 패턴 💚 빌더 패턴 장점 어떤 필드에 어떤 값을 채워야 할지 명확히 지정할 수 있음 필수 및 선택인자가 많아질수록 생성자 방식보다 가독성이 좋다 자바빈 패턴(setter를 이용하는 방식)보다 안전함. setter 생성을 방지하기 때문에 객체를 변경할 수 없음 (불변성 보장) 2️⃣ 생성자 패턴 vs 빌더 패턴 💚 생성자 패턴 예시 지금 채워야 할 필드가 무엇인지 명확히 지정할 수 없음 변수의 위치가 뒤바뀐 채로 생성되어도 문제점을 찾지 못하고 넘어갈 수 있음 public class Person { private String name; private int age..

1️⃣ 의존성주입 (DI : Dependency Injection) 방법 의존성 주입에는 3가지 방법이 존재한다. 필드 주입 수정자 주입 (setter 주입) 생성자 주입 💚 필드 주입 필드에 @Autowired를 붙여서 바로 주입하는 방법이다. 필드 주입의 특징 코드가 간결해진다. 단, 외부에서 변경이 불가능하여 테스트하기 어려운 단점이 있다. @Component public class CoffeeService { @Autowired private MemberRepository memberRepository; @Autowired private CoffeeRepository coffeeRepository; } 필드 주입을 사용하지 않는 이유 DI 프레임워크가 없으면 아무것도 할 수 없다. 테스트 코드의 ..

1. 깨~끗한 내 로컬에 저 레포에 담긴 코드만 가져오고싶다? → clone 사용 기본순서 1. git clone 깃허브 주소 2. 협업중에 or 지금 내 코드에 깃 레포에 있는 코드 받아올 일이 생겼다? → pull 사용 기본순서 1. git init 2. git remote add origin 깃허브주소 if. 이미 연결된 저장소가 있는데 바꾸고 싶다! or 모르겠고 지금 연결하고 싶은 레포랑 당장 연결해야겠다!! git remote remove origin 으로 기존 원격 저장소랑 연결 끊어주세요~ 연결 되어있는거 없고 오류 안나면 패스하셔도 됩니다 3. git pull origin main 우선은 main이라고 써뒀는데 브랜치명입니다. 여러분이 받아와야할 레포의 브랜치가 musicismylife ..

이 전에 깃허브 default branch는 main으로 변경해주세요. github는 디폴트 브랜치로 master을 안쓴지 좀 됐습니다... 기본 순서 1. git init 2. git remote add origin 깃허브주소 3. git add . 4. git commit -m ‘커밋메모’ 5. git push origin main 발생할 수 있는 오류들 이때, 만들어놓은 깃허브 스토리지에 리드미를 추가해 놓았다면 로컬 저장소에는 .readme 파일이 없어서 pull을 해주라는 멘트가 뜰 수 있음 해결방법 git pull origin main (먼저 풀 해줘서 내 로컬이랑 레포랑 상태 맞춰주는거) 근데 이렇게 해도 fatal: refusing to merge unrelated histories 라는 ..

1️⃣ ORM ORM 이란 Object-Relational Mapping 의 약자로 객체(Object)와 관계형 데이터(Relational data) 를 매핑하기 위한 기술 관계형 데이터베이스와 객체 지향 프로그래밍은 서로 패러다임이 달라 패러다임 불일치가 발생함 객체 지향 필드와 메서드 등을 묶어서 객체로 잘 만들어 사용하는 것이 목표 객체 지향 프로그래밍은 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공한다. 관계형 데이터베이스 데이터를 잘 정규화해서 보관하는 것이 목표 이를 해결하기 위해 ORM 기술이 필요하고 JPA는 Java Persistence API의 약자로, 자바 ORM 기술에 대한 API 표준 명세이다. 2️⃣ JPA 자바 ORM 기술..

1️⃣ TDD "테스트 주도 개발: 테스트가 개발을 이끌어 나간다." RED : 항상 실패하는 테스트를 먼저 작성 GREEN : 테스트에 통과하는 프로덕션 코드 작성 REFACTOR : 테스트가 통과하면 프로덕션 코드를 리팩토링 테스트를 작성하고 그걸 통과하는 코드를 만드는 과정을 반복하며 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것 💚 TDD를 사용하는 이유? 개발 단계 초기에 문제를 발견하게 해준다. 추후에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존기능이 올바르게 작동하는지 확인할 수 있다. 기능에 대한 불확실성을 감소시켜준다. 시스템에 대한 실제 문서를 제공한다. 즉, 단위 테스트 자체가 문서로 사용할 수 있다. 테스트 코드 작성시 사람의 눈으로 검증하지 않게 자동검증이 가능 ..