개발 공부를 하며 들었던 이야기 중 하나는, 필드 주입보다는 생성자 주입을 쓰라는 이야기였다. 심지어 인턴 당시 사수에게는 필드 주입들을 싹 다 생성자 주입으로 바꾸라는 조언도 들었다. 왜 생성자 주입을 써야할까? 필드 주입이 편하지 않을까? 우선 해당 두 방법의 차이를 알아보자. 1. 생성자 주입 public class OrderController { // final 변수로 선언 private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } } 2. 필드 주입 public class OrderController { @Autowired p..
이번에 과제를 진행하면서 테스트 코드를 작성하던 중 고민을 해볼 지점이 생겼다. 현재 내 테스트 코드는 DB에 값을 insert한다거나 update, delete 하는 등 DB에 접근하는 행위들이 있다. 테스트마다의 독립성을 보장하기 위해서, 나는 각 테스트마다 진행된 것들이 다른 테스트에 영향을 끼치지 않기 위해 끝나면 롤백해주고 싶다. 현재 코드에는 그런 기능을 하는 것이 두 개가 동시에 들어가고 있다. @Transactional , @AfterEach의 db.clear() 여기서 내가 조금 걱정이 되었던 부분은, 각 테스트가 실행될 때마다 db를 clear를 통해 다 지우는 것이 과연 합리적일까? 라는 생각이 들었다. 그냥 내가 수정한 부분들만 rollBack을 해주면 되는 것 아닐까? 라는 생각이..
지난 데브코스 도서 관리 과제를 하던 중 멘토님께 받은 코드 리뷰 피드백이 하나 있었다. public List read() { try (Reader reader = new FileReader(path)) { Type listType = new TypeToken() { }.getType(); List books = gson.fromJson(reader, listType); return Optional.ofNullable(books).orElse(new ArrayList()); } catch (Exception e) { e.printStackTrace(); } return new ArrayList(); } 저기 try안에 넣은 구문은 뭐죠? 현재 reader를 close하는 부분이 없는데 그럼 이 코드는 잘..
9월 19일에 시작한 프로그래머스 데브코스 합류가 곧 한 달을 맞이한다. 어떤 마음가짐으로 시작했고, 어떤 경험을 했으며 느낀 점들에 대해 간단히 회고 겸 남겨보려 한다. 어떤 마음으로 시작했는가 합격 후기에도 남겼다시피, 나는 협업에 대한 갈증이 많았다. 코딩을 마치 수능 시험 공부하듯 혼자 학습해나갔기에 물론 이점들도 많았지만 인턴으로 일을 하며 생각보다 단점이 많았음을 느꼈다. 문제 해결을 위해 소통하는 방법도 익숙치 않았고, 혼자 공부하며 생긴 고집은 인턴 초반 다른 사람들로부터 하여금 협업 능력이 부족한 사람으로 인식되었다. 다행히 회사 내 좋은 사람들이 많았고 나 또한 내가 협업 능력이 부족했던 걸 알았기에 적극적으로 질문하고 부족한 부분에 대해 과감없는 조언을 부탁드려 전보다는 사교성과 협업..
커스텀 예외를 작성하던 중 Error와 Exception 용어를 혼용하며 사용하는 내 모습을 보며.. 문뜩 두 용어를 한 번 제대로 정리해서 구분해야겠다라는 생각이 들었다. Error(오류): 시스템이 종료되어야 할 수준의 상황과 같이 수습할 수 없는 심각한 문제 개발자가 미리 예측하여 방지할 수 없다. Exception(예외): 개발자가 구현한 로직에서 발생한 실수 또는 사용자의 영향에 의해 발생하는 문제 개발자가 미리 예측하여 방지할 수 있기에 상황에 맞게 예외 처리를 해줘야한다. 오류 Error 객체의 상속 구조를 보면 Throwable과 Object를 상속받고 있음을 알 수 있습니다. 여기서 좀 알만한 Error는 이 정도인 것 같습니다. StackOverFlowError : 호출의 깊이가 깊어지..
이번 주 제시된 도서 관리 과제 중 해당 기능이 필요했다. ## 모드 번호를 입력해주세요. ## 도서 제목을 입력해주세요. ## 도서 저자를 입력해주세요. ## 페이지 수를 입력해주세요. 나는 단순히 이렇게 작성했다. private static final Scanner scanner = new Scanner(System.in); public static void main(String[] args) { int mode; String title; String author; int page; System.out.println("모드 번호를 입력하세요"); mode = scanner.nextInt(); System.out.println("도서 제목을 입력하세요."); title = scanner.nextLine..
* 앞으로는 공부한 목차 위주로만 정리하고 주요 공부내용은 따로 포스팅 합니다!! 오늘 한 일) 데브코스 3일차 여분 강의 및 4일차 강의 수강 SOLID 내용 포스팅 오브젝트 챕터 1 정독 데브코스 도서 관리 과제 도메인 설계 생각) 오늘은 스프링 공부하면서 어떻게 보면 대충 넘어갔던 의존성 부분이나, SOLID 원칙 등에 대해 다시 정리하는 시간을 가졌다. 확실히 스프링을 어느정도 공부한 상태에서 다시 해당 개념을 보니 이해가 더 잘 되었다. 오브젝트 책을 더 읽을까 하다가 오늘은 과제 도메인 설계를 했다. 오브젝트 책이 도움이 많이 되는 것 같아서.. 내일은 오브젝트 책을 읽는 것에 더 초점을 두려고 한다. 내일 챕터4까지 읽는 걸 목표로!!! tmi) 오늘 그래도 월요일치곤 시간 낭비 없이 하루를..
의존성이 잘못 관리될 경우, 변경하기 어렵고 재사용하기 어려운 코드가 작성이 된다. 그렇기에 우리는 의존성을 잘 관리된 코드를 작성하려 노력해야 한다. 그렇다면 의존성을 잘 관리하기 위한 기준은 무엇이 있을까? 바로 SOLID 원칙이 있다. 정처기 시험을 볼 때 꽤 자주 나왔지만, 말 그대로 정의만 있을 뿐 이를 단순히 정의만 보면 이해 하기가 어려우니 예시와 코드를 보며 이해해보자. ++ DIP(의존 역전 원칙)은 의존 관계를 설명하며 설명했기에 패스하겠다. SOLID SRP : Single Responsibilirty Principle OCP : Open Closed Principle LSP : Lskov Substitution Principle ISP : Interface Segregation Pr..
