전체 글

드디어 프리코스 과정이 끝났다. 과제 제출 기간까지 포함하면 총 6주에 걸친 여정이었다. 후련하면서도 한편으로는 아쉬움이 남는다.프리코스가 끝나자마자 발표 과제와 제출할 과제가 밀려왔다. 이것저것 처리하느라 정신없이 지내다 보니 회고를 이제야 쓰게 되었다. 주제 선정주제 선정에만 한 2~3일이 걸렸다. 무엇을 할지 정말 많이 고민했다. 리액트로 앱 만들어보기, JWT 직접 구현해보기, 소켓 활용해보기 등 여러 아이디어가 떠올랐다. JWT 직접 만들기는 세션과 토큰을 공부하다가 본 글에서 영감을 받았다. 개념만 가지고 다른 자료없이 직접 구현해보고 싶었다. 만약에 예상보다 일찍 끝나면 오픈 미션 설명회에서 언급했던 것처럼 하나씩 다른 것도 구현해볼 예정이었다. 소켓 활용은 최근에 들었던 김영한님의 실..

이번 주차 과제는 특히 재미있었다. 지난 주차가 여러 도메인을 단순히 묶어 하나의 큰 구조를 만드는 느낌이었다면 이번 과제는 도메인들이 서로 협력하면서 하나의 흐름을 완성하는 과정이 더 선명했다. 먼저 도메인을 만들고 테스트 코드로 각 규칙과 동작을 충분히 검증해둔 뒤, 이후에는 Controller에서 View와 소통하며 프로그램의 흐름을 조율하고, 필요한 비즈니스 로직은 Service가 도메인 객체들을 조합해 가져다 쓰는 방식으로 완성해 나갔다. 즉, View는 입력/출력만 담당하고, Controller는 흐름을 관리하며, Service는 도메인 간 협력을 수행하고, Domain은 핵심 규칙을 책임지는 구조가 제대로 맞물리는 것을 체감할 수 있었다. 코드가 단순히 돌아간다를 넘어서, 각 객체가 제자리..

다른 사람들의 리뷰에서 배운 점입력값에 대한 검증 책임입력값 검증의 책임을 어디에 두어야 할지 정말 많이 고민했었다. 처음에는 `InputValidator`을 통해 입력값이 비었는지를 검증했고, 이 검증은 `Controller`에서 수행하도록 했다. 이후 입력값은 모두 도메인 객체로 넘겼는데, 이는 원시값 포장을 위해서였다. "양수여야 한다" 같은 규칙은 비즈니스 로직으로 보고 도메인에서 처리했다. 파싱 과정도 비슷했다. 입력값을 문자열 그래도 생성자에 넘기고, 생성자 내부에서 해당 값을 알맞은 타입으로 변환하거나 형식을 검증하도록 했다. 다만, 입력을 `split`해야 하는 등 복잡한 파싱 로직의 경우에는 도메인 안에 넣는 건 책임이 과하다고 생각해 `InputParser` 클래스를 따로 분리했고, ..

NsTest전체 코드package camp.nextstep.edu.missionutils.test;import camp.nextstep.edu.missionutils.Console;import org.junit.jupiter.api.AfterEach;import org.junit.jupiter.api.BeforeEach;import java.io.ByteArrayInputStream;import java.io.ByteArrayOutputStream;import java.io.OutputStream;import java.io.PrintStream;import java.util.NoSuchElementException;public abstract class NsTest { private PrintStr..

Java 14 이전에는 보일러플레이트 필드와 메서드를 가진 클래스를 작성해야 했으며, 이는 사소한 실수와 혼란스러운 의도를 초래할 수 있었습니다.Java 14가 출시되면서, 이제 이러한 문제를 해결하기 위해 레코드를 사용할 수 있게 되었습니다. 보일러플레이트 : 최소한의 변경으로 여러 곳에 재사용되며 반복적으로 비슷한 형태를 띄는 코드, 강철로 찍어내는 것처럼 최소한의 수정으로 여러 곳에서 자주 반복되는 코드 목적데이터베이스 결과, 쿼리 결과 또는 서비스에서 받은 정보를 단순히 저장하기 위해 클래스를 작성하는데, 이 때 대부분의 경우에 불변 객체를 사용한다. 불변 객체를 사용하게 됨으로써 내부 필드 값의 불변성을 보장해 주어서 유지보수에서 많은 이점을 챙길 수 있다. 이를 달성하기 위해 다음과 ..

시작객체지향 프로그래밍이란 현실 속에 존재하는 사물을 최대한 유사하게 모방해 소프트웨어 내부로 옮겨오는 작업이다. 따라서 그 결과물인 객체지향 소프트웨어는 실세계의 투영이며, 객체란 현실 세계에 존재하는 사물에 대한 추상화라고 한다. 그러나 실세계의 모방이라는 개념은 객체지향의 철학적인 기반을 설명하는 데는 유용하지만 유연하고 실용적인 관점에서 객체지향 분석이나 설계를 설명하기에는 한계가 있다. 객체지향의 목표는 실세계를 모방하는 것이 아니라 오히려 새로운 세계를 창조하는 것이다. 즉, 소프트웨어 개발자의 역할은 현실을 복제하는 것이 아니라 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것이다. 그런데 왜 여전히 객체지향을 실세계와 비교하려 할까?이는 객체지향의 다양한 측면을 이해하고 학습하는 데 ..