전체 글

이번에는 처음 해 보는 문제였으나, 나름 추측했던 (?) 문제였던 로또 문제였습니다. Enum에 대해 더 깊은 관찰과 고민을 하게 됨 1주 차 때 이펙티브 자바를 보며 공용 상수는 Enum으로 관리하는 것이 좋을 것 같다는 글을 썼었는데요, 이번 미션에서는 아예 요구사항으로 Java Enum을 적용하는 게 있었습니다! 그래서 이펙티브 자바에서 Enum에 대해 미처 알지 못했던 부분들을 읽거나, 다른 자료를 더 찾아보곤 하였습니다. 언제 Enum을 쓰고 언제 private static final을 써야 할까? (feat. 응집도) 1주 차 때 작성된 글을 보면, 객체에 private 하게 사용되는 상수는 후자 방식을 쓰고, 그렇지 않다면 Enum을 통해 관리하도록 하는 게 좋다고 했었는데요. 아쉬운 점은 ..

서문 마틴 파울러의 객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점 개념 관점 (Conceptual Perspective): 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현 도메인 (domain): 사용자들이 관심을 가지고 있는 특정 분야나 주제 명세 관점 (Specification Perspective): 소프트웨어 안에서 살아 숨 쉬는 객체들의 책임에 초점을 맞춤 객체의 인터페이스 (interface)를 바라본다. 구현 관점 (Implementation Perspective): 객체들이 책임을 수행하는 데 필요한 동작하는 코드를 작성 위 관점들이 순서대로 개발되는 게 아니라, 클래스에서 이 관점들이 모두 관찰될 수 있도록 작성해야 한다. 커피 전문점 도메인 커피 전문점 도메인을 정의해 ..

서문 길을 찾는 두 가지 방법 지나가는 사람에게 물어보는 방법 기능적이고 해결책 지향적인 접근법이다. 일반적이지도, 재사용 가능하지도 않다. 지도에 표시된 길을 따라가는 방법 구조적이고 문제 지향적인 접근법이다. 현재의 목적뿐만 아니라 다양한 목적을 위해 재사용될 수 있다. (집으로 가려고 할 때 등) 지도를 사용하는 사람들의 요구사항은 계속 바뀐다. 따라서 기능이 아니라 구조를 기반으로 해야 변경에 안정적이다. 지형은 거의 변하지 않기 때문에 과거의 지도는 현재에도 여전히 유용하게 사용될 수 있다. 기능 설계 대 구조 설계 소프트웨어 제품의 설계 또한 기능 설계와 구조 설계로 구분된다. 기능 설계 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 둔다. 구조 설계 제품의 형태가 어떠해야 하는지에 초점..

서문 참가자와 다른 사람의 이야기를 하는 과정에서의 실험 > 다른 사람의 소리는 녹음된 것이었음 다른 사람이 갑자기 발작을 일으킬 경우 자신밖에 없다고 생각했던 참가자는 85%가 심리학자들에게 도움을 요청 그러나 자신 말고도 또 다른 사람이 있다고 생각했던 참가자는 31%만 도움을 요청함 그 이유는 자신이 도움을 요청하지 않아도 된다고 생각했기 때문 - 사건에 대한 목격자가 많으면 많을수록 개인이 느끼는 책임감은 적어진다 - 따라서 객체지향에서도 명확한 책임과 역할을 부여해야만 객체가 자신의 책임이라고 느낄 것이다. 자율적인 책임 4장: 역할, 책임, 협력에서 작성하였듯이 적절한 책임을 적절한 객체에게 할당하는 것부터 실행되어야 한다. 또한 객체는 자신에게 부여된 책임을 충분히 자율적으로 수행할 수 있어..

다소 늦은 프리코스 2주 차 후기를 올립니다! 현재 진행 중인 미션이 꽤 걸리는지라 이제야 올리게 됐네요 🥲 이번 미션은 학교 선배 분께 리뷰를 받으며 미리 해 본 자동차 경주 미션이었습니다. 그렇기에 1주 차 때처럼 핵심 로직은 쉽게 이해되었었습니다. JUnit5에 대해 깊게 파보게 됨 (ParameterResolutionException) 이번 미션에서는 요구사항으로 테스트를 해 보라는 것이 아예 요구사항에 정의되어 있었습니다. 그래서 우아한 테크코스의 단위 테스트 테코톡 영상을 보며 제대로 테스트를 익혀보고 싶었고, 이 과정에서 @ParameterizedTest를 쓰면 같은 테스트이면서 다른 입력값을 검증할 경우를 축약할 수 있음을 배웠습니다. 그런데 우연히 @Test와 @ParameterizedT..

우아한 테크코스 2주 차 프리코스 미션을 하면서 JDK17의 특징을 살릴 수 있는 레코드 (record)에 대해 접해볼 수 있었습니다. 사용하면서 느낀 점은, 기존에 작성했던 DTO를 쉽게 대체할 수 있겠다는 생각이었습니다. (DTO가 무엇인지를 보시려면 이 글을 참고해주세요!)기존의 DTO먼저, 기존에 사용했던 DTO 코드의 예시를 보겠습니다.public class CarResponse { private final String name; private final int position; private CarResponse(final String name, final int position) { this.name = name; this.position = ..