💥 개요 JDK가 제공하는 제네릭 타입과 메서드를 사용하는 일은 일반적으로 쉬운 편이지만, 제네릭 타입을 새로 만드는 일은 조금 더 어렵다. 그래도 배워두면 값어치는 충분히 한다. public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { ensureCapacity(); elements[size++] = e; } public Object pop() { if (size =..
✨ 목표 마지막 4주차 프리코스에서 피드백과 코드리뷰를 통해 적용 및 공부하기로 마음을 먹은 부분은 1.Stream을 활용 심화 2.객체는 객체스럽게 사용 3.필드의 수를 줄이기 위해 노력 4.ParameterizedTest 5.함수형 프로그래밍 활용 5가지였다. 🔍달성 Stream을 활용 심화 stream의 경우에는 코드리뷰를 받았는데, Stream에 대해서 제대로 공부하지 않고 주먹구구 식으로 사용했기 때문에, 이를 공부해 더 자유롭게 Stream을 활용할 수 있도록 마음을 먹었다. stream의 장점이라고 생각하는건 언제든 병렬로 처리할 수 있도록 큰 노력없이 변경이 가능하고, 가독성과 간결성을 챙기기 위해서다. 그리고 컬렉션을 잘 활용하기 위해 stream을 사용해야 된다고 생각했다. 객체는 객체..
💥 개요 배열과 제네릭 타입에는 중요한 차이가 두가지 있다. 배열의 경우 Sub가 Super의 하위 타입이라면 배열 Sub[]는 배열 Superp[]의 하위 타입이 된다.(공변) 하지만 제네릭은 불공변이다. List가 List의 하위 타입이 아니다.(불공변) 그럼 제네릭이 더 안 좋은걸까? 배열의 문제점 Object[] objectArray = new Long[1]; objectArray[0] = "타입이 달라 넣을 수 없다."; // ArrayStoreException을 던진다. 위의 코드는 런타임에 실패한다. 하지만 다음 코드는 컴파일 시점에 실패한다. List ol = new ArrayList(); // 호환되지 않는 타입이다. ol.add("타입이 달라 넣을 수 없다."); 어느쪽이든 문자열을 넣..
❤️ 서로 PR하기를 원하시는분은 https://github.com/woowacourse-precourse/java-lotto-6/pull/818 여기에 남겨주세요! 👍3주차 목표 3주차는 2주차에서 계획했던 목표인 mvc 패턴에 맞게 유효성 검사하기 public 메소드만 테스트하기 이 두가지에 중점을 뒀다. 이번주에 적용하기 위해서 해당 내용을 정리하여 블로그에 포스팅했는데, 덕분에 이번주차 미션을 해결하는데 도움이 많이 됐다. 특히 private 메소드를 테스트해야 하는 경우라면, 해당 클래스가 너무 많은 책임을 가진것이 아닌지 확인하라는 말에 많은것을 깨달았다. [해리&션 발표 중, 많이 실수하는 부분] https://mntdev.tistory.com/90#%ED%95%B4%EB%A6%AC%26%E..
💥 개요 제네릭을 사용하면 수많은 컴파일러 경고를 보게 된다. 익숙해질수록 마주치는 경고 수는 줄겠지만 새로 작성한 코드가 한번에 깨끗하게 컴파일되리라 기대하지는 말자. 대부분의 비검사 경고는 쉽게 제거가 가능하고, 컴파일러가 이를 알려준다. 이대로 수정하기만 하면 경고가 사라진다. 하지만 제거하기 어려운 경고도 있다. 하지만 포기하지말고 할 수 있는 모든 비검사 경고를 제거하라. 모두 제거하면 타입 안정성이 보장된다.(런타임에 ClassCastException이 발생할 일이 없다.) 경고를 제거할 수 없지만 타입 안전한 경우 @SuppressWarnings("unchecked") 어노테이션을 달아 경고를 숨기자. 단, 타입 안전함을 검증하지 않은 채 경고를 숨기면 경고없이 컴파일되지만, 런타임 시점에 ..
테스트와 OCP의 관계 테스트를 작성하는 여러 이유 중 하나는 객체 지향 설계 원칙 중 OCP(Open-Closed Principle)와 관련이 있다. 이 원칙은 클래스는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 것을 의미한다. 이 원칙을 지키지 않을 경우, 테스트하기 어려운 코드가 발생할 수 있다. 예를 들어, 랜덤한 숫자를 가져와야 하는 로직이 있다면, 이 로직을 테스트하는 것이 어려울 수 있다. 랜덤넘버를 이용한 코드와 테스트 [문제 상황] 랜덤한 숫자를 이용해서 게임을 진행하는 코드가 있다고 가정하자. 이러한 로직은 직접 테스트하기 어렵다. public class RandomGame { public String play() { int randomNumber = (int) (Math..
1일차 개발에 들어가기 전 기능 목록 구현을 위해 1주차와 마찬가지로 하지만 1주차의 경험을 바탕으로 설계를 진행하였다. 플로우 차트는 요구 사항에 맞게 금방 구현했었는데, 문제는 역시 클래스 다이어그램을 설계하는 과정이었다. 이번에는 컨트롤러, 서비스, 뷰, 모델로 프로젝트를 구성하기로 생각을 했었다. 이유는 컨트롤러에서 프로그램을 제어하는 책임과, 비즈니스 로직까지 포함되어 있어 처음에 계획했던 것 이상의 책임을 가지게 되었기 때문에 비즈니스 로직을 처리하는 서비스를 만들기로 했다. 서비스에서는 모델에 접근하여 비즈니스 로직을 처리하고, 컨트롤러는 입출력과 서비스를 제어하는 역할을 맡겼다. 이렇게 하니 조금 더 코드가 간결해지고 테스트하기 용이해졌다고 판단했다. 그 다음 고민은, 유효성 검증과 메시지..
private 테스트 해야돼? private 메소드는 어떻게 하나요? 라는 질문이 우테코 단톡에 올라왔다. 리플렉션을 사용하는 방법(개인적으로 절대 사용하지 않는) 내가 답변했던 package-private을 사용하는 방법 테스트 자체를 하지 않는 방법(말도 안된다고 생각했다.) 말도 안된다고 생각 했던 이유는 가장 중요한게 내부 구현인데 그걸 테스트 하지 않는다고? 라고 생각했었기 때문이다. 그래서 나도 package-private을 사용해서 private을 해제하고 내부 구현의 개발을 진행하였다. 그런데 이게 진짜 맞을까? 라는 생각이 들었다. 처음에 이펙티브 자바 접근 제한자에 대해서 공부할 때 package-private(default)에 대해서 알게 되었고, 이를 테스트시에 풀어줘도 된다. 라는..
