Facts (사실, 객관) 8주 차 데브노트, 과제 밀리지 않고 제출했다. 밀린 5, 6주 차 데브노트 정리 못함 과제 로컬에서는 테스트 전부 통과해서 제출했는데 CI는 통과 못하길래 왜 억까하지..? 생각하고 있었는데 내 잘못이었음.. 회사에서 git관련 문제를 만나 해결에 어려움이 있었다. git에 대해 공부할 필요를 느꼈음 Feelings (느낌, 주관) & Findings (배운 점) DDD에 대해 가볍게 배우고 과제를 통해 살짝 맛봤지만 모델 간의 관계를 제대로 설계한 건지는 아직 감이 제대로 잡히지 않는다. Aggregate의 개념은 아직도 익숙하지 않고 어떻게 활용해야 할지 모르겠다. 이전까지는 과제가 crud의 반복인 느낌이었지만, 이번에는 DDD를 적용해 도메인 간의 관계를 설정하는 과제..

오늘 새로 배운 내용 Java Varargs (가변인자) 오늘은 Java 5부터 도입되었다는 Varargs (가변인자) 기능을 알게 되었다. Varargs기능은 메서드의 매개변수로 동적인 개수의 인수를 전달할 수 있게 해주는 기능으로, 메서드가 동일한 타입의 인수를 다양하게 받을 수 있게 해 준다. 아래 예시 코드르 보면 이해가 편하다. public void printNumbers(int... numbers) { for (int num : numbers) { System.out.println(num); } } printNumbers(1, 2, 3); // 1, 2, 3을 인수로 전달 printNumbers(10, 20); // 10, 20을 인수로 전달 printNumbers(100); // 100을 인..

오늘은 응답 객체 직렬화 관련해서 고생을 했는데 그 과정을 짧게나마 기록해 본다. 간단하게 문제상황을 설명하면 market의 open 여부를 확인하는 api를 get 요청했을 때 market의 open 여부에 따라 true, false 값을 반환하는 api인데 동일한 응답값이 두 개가 나오는 문제가 발생했다. 필드명이 isMarketOpen이라 치면 아래와 같이 두 개가 중복돼서 나오는 문제가 발생했다. { "isMarketOpen":false, "marketOpen":false } 이건 누가 봐도 dto객체의 getter 메서드에 문제가 있기 때문에 발생한 문제라고 생각하고 dto객체를 살펴보는데 별 이상 없어 보였다.. 아래는 문제의 dto객체이다. @JsonAutoDetect(fieldVisibil..

오늘 새로 배운 내용 이펙티브 자바 아이템 4를 읽던 중 처음 알게 된 사실이 있다. 자바 클래스에 생성자를 명시해주지 않을경우에 컴파일러가 자동으로 매개변수를 받지 않는 public 기본 생성자를 만들어 준다는 사실을 전혀 모르고 있었다. public 한 기본 생성자가 있을 경우 의도치 않게 클래스가 인스턴스화될 가능성이 존재한다. 문제가 되는건 인스턴스로 만들어 쓰려고 설계한 클래스가 아닌데 인스턴스화가 되면 안 되기 때문에 인스턴스화를 막아야 한다. 인스턴스화할 필요가 없는 클래스들이 존재하는데 (예를 들어 java.lang.Math나 java.util.Array처럼 기본 타입값이나 배열 관련 메서드만 모아놓은 클래스들) 이러한 클래스들은 private 생성자를 추가해 인스턴스화를 막고 있다. 컴파..

Facts (사실, 객관) 현재 5, 6주 차 데브노트가 밀린 시점 이번 주 7주 차는 밀리지 않았다. 더 이상 밀리면 지옥뿐.. 기존 레거시 코드를 리팩터링 하기 위해 제네릭 상속, 와일드 카드에 대한 학습 시간을 많이 사용했다. 어찌어찌 추후 확장성을 고려해리팩터링을 하긴 했지만 제대로 했는지는 다음주에 코드 리뷰를 받아봐야 알 것 같다. 이펙티브 자바를 읽는 중이다. (차례대로 읽는 건 지루해서 목차보고 궁금한 거 위주로 읽는 중) Feelings (느낌, 주관) & Findings (배운 점) @EmbeddedId 어노테이션을 선언해 준 필드 객체는 Serializable 인터페이스를 구현해야 직렬화를 보장할 수 있다. 코드의 중복을 줄이고자 와일드카드를 이용해 추상 메서드를 만들어 추상 메서드를..

오늘 새로 배운 내용 테스트 코드에서 반복해서 생성되는 객체는 정적 멤버 클래스를 이용해서 중복을 줄이자. 테스트 코드에서 각각의 독립적인 테스트 케이스마다 객체 검증을 위해 반복적으로 객체를 생성해야 할 일이 있을 것이다. 예를 들어 아래와 같이 Post라는 객체를 검증하기 위해서는 각각의 테스트 케이스마다 post를 생성해줘야 한다. @Test void test1() { Post post = new Post(...); ... } @Test void test2() { Post post = new Post(..); ... } 테스트 케이스가 많아질 수록 Post 객체를 생성하는 작업은 귀찮고 코드도 중복되는 문제가 발생한다. 이런 문제를 해결하기 위해서 중첩 클래스의 한 종류인 정적 멤버 클래스를 이용할..