코딩 메모장

프리코스 끝났지만 어려웠던 4주 차 미션에 대해 다른 사람들로부터 피드백을 받고자 코드 리뷰 진행했고, Receipt 클래스에 대해 고민해볼만한 피드백을 받았다. 그 과정에서 책임 분리와 멤버 변수 관리에 대한 깊은 고민을 하게 되었다. 이 글에서는 받은 피드백에 대한 나의 생각을 정리해보고자 한다. 클래스 설계와 책임 분리에 대한 고민 ( Receipt 클래스 ) 첫번째 피드백 내용으로 "Receipt 클래스가 계산 로직을 포함하고 있으니, 이를 서비스 레이어로 옮겨 단일 책임 원칙(SRP)을 준수하는 것이 어떨까?"였다.  Receipt 클래스는 많은(4개) 상태 필드를 가시고 있고 멤버십 할인, 프로모션 할인 등 다양한 계산 로직을 포함하고 있다. 이는 Receipt 클래스가 다음과 같은 두 가지 ..

[목차]목표 달성일주일의 큰 계획과 하루의 작은 목표몰입: 시간이 빠르게 흐른 이유마무리 및 소감[ 일주일을 돌아보기 ][우아한테크코스] - "프리코스 22일차" 4주 차 미션 분석 및 기능 목록 작성, 일주일 plan 설정[우아한테크코스] - "프리코스 23일차" 유스케이스 시나리오와 MVC 구조 설계[우아한테크코스] - "프리코스 24일차" getter의 적절한 사용, products.md 파일 파싱 과정[우아한테크코스] - "프리코스 25일차" DTO 개념 학습, 테스트 코드에 대한 오해[우아한테크코스] - "프리코스 26~27일차" 프로모션 적용 알고리즘 설계, view 클래스의 정체[ 목표 달성 ]저는 프리코스를 통해 스스로 학습하는 습관을 기르는 것을 저의 최종 목표로 잡았고, 기대했던 것보다..

📝 오늘의 Todo 리스트 체크 왜 static final 대신 enum을? 🔺Enum의 내부 API 학습 🔺view 클래스에 대해 생각해보기 ✅코드 구현 마무리 ✅목차프로모션 상품 처리 알고리즘영수증 출력 형식view 클래스에 대해 생각해보기내일 Todo 리스트프로모션 상품 처리 알고리즘오늘 코드 구현하다 프로모션 상품 처리 과정에서의 나의 설계가 완전히 틀렸다는 것을 알게 되자 좌절감을 느꼈다.😭내가 생각했던 것보다 더 많은 경우의 수가 존재하고, 그것들을 내 코드로 구현하기 위해 설계를 다시 해야만했다. 이렇게 3시간 동안 나는 다시 설계했다. 크게는 총 4가지 경우의 수로 나누고 다음과 같은 순서로 조건문으로 확인하고 처리했다.1. 구매 수량이 프로모션 적용 수량보다 작으면 증정 상품 없이..

📝 오늘의 Todo 리스트 체크 코드 구현 ✅DTO 개념 학습 ✅목차DTO 개념 학습DTO(Data Transfer Odject)란?왜 DTO가 필요한가?DTO는 어디서 변환되어야 할까?테스트 코드에 대한 오해테스트 코드도 코드의 일환이다테스트 코드 리팩토링DTO(Data Transfer Object)란?DTO는 Data Transfer Object의 약자로, 계층 간 데이터 전송을 위해 사용되는 객체이다. 일반적으로 비즈니스 로직을 포함하지 않고 단순히 데이터를 담아 전달하는 역할을 한다. 이러한 이유로 DTO는 데이터를 저장하고, 데이터에 대한 getter, setter 메서드만을 가진다. 위키피디아에 따르면, DTO는 어떠한 비즈니스 로직도 가지지 않고, 단순히 저장, 검색, 직렬화, 역직렬화 로..

📝 오늘의 Todo 리스트 체크 getter의 적절한 사용 학습 ✅코드 구현 시작 ✅목차getter의 적절한 사용객체지향에서의 getter 사용에 대한 고찰무조건적인 getter 생성은 위험하다프리코스 2주차 경험: 잘못된 getter 사용의 오해적절한 getter 사용: 값 프로퍼티와 불변 컬렉션getter의 적절한 사용 결론products.md 파일의 문자열 내용을 출력 형식에 맞게 파싱 과정내일 Todo 리스트객체지향에서의 getter 사용에 대한 고찰 객체지향 프로그래밍(OOP)에서는 객체가 상태(멤버 변수)와 행동(메서드)을 통해 외부와 소통한다. 이러한 구조는 캡슐화라는 핵심 원칙을 따른다. 캡슐화는 객체의 내부 구현을 숨기고 외부에서는 메서드를 통해서만 객체와 상호작용하도록 만드는 것이다...

📝 오늘의 Todo 리스트 체크 유스케이스 시나리오 설계 기본 흐름, 대체 흐름, 예외 흐름으로 분리하기 ✅Activity 다이어그램 작성 🔺 MVC 구조 설계 ✅목차유스케이스 시나리오 설계MVC 구조 설계내일 Todo 리스트유스케이스 시나리오 설계 기본 흐름과 예외 흐름은 지난 과제들과 동일하게 구성했다. 한 가지 차이점은 예외 흐름 시나리오에서 단계 컬럼을 추가해서, 해당 예외가 기본 흐름에서 어디서 발생했는지 표시했다.  그리고 이번 미션의 가장 큰 특징이자 까다러운 부분이 바로, 대체 흐름이 존재한다는 것이다. 첫번째는 프로모션 상품 존재, 두 번째는 멤버십 회원을 위한 할인이 존재이다. 그래서 각각 대체 흐름에 대한 대체 흐름을 시나리오로 표현했다. 마찬가지로 단계에서는 이 대체 흐름이 기본..

목차애플리케이션 소개 및 구체적인 설명기능 목록 정리일주일 동안 plan내일 Todo 리스트애플리케이션 소개 및 구체적인 설명오늘 4주 차 미션이 올라오고 기능 요구 사항을 읽어보았을 때 실제 웹 서비스를 구현해야 될 것처럼 느껴졌다. 전에는 MVC 디자인 패턴에서 Model을 Domain 역할을 대신해서 사용했지만 이번 미션에서는 비즈니스 로직을 담당하는  Domain클래스들과 데이터를 관리하는 Model클래스로 분리해야되겠다라는 생각이 들었다. 왜냐하면 이번에는 데이터베이스의 역할을 하는 텍스트 파일이 추가 되었기 때문이다. 우선 오늘은 전체적인 애플리케이션 흐름, 기능적 요구 사항, 예외 발생 가능성, 추가 기능들을 생각해보고 리드미 파일에 작성했다.  지난 주 3주 차 미션부터 도입하게 된 애플리..

📝 오늘의 Todo 리스트 체크 오류 해결 ✅3주 차 미션 회고 작성  ✅마지막 검토 및 제출  ✅목차테코톡을 경험하기경험으로 배운 테스트 코드의 가장 큰 장점README.md를 더 상세하게메서드가 한 가지 기능을 하는지 확인하는 나만의 기준의존성 주입을 통해 높은 결합도 해결마무리 및 앞으로의 Plan[ 일주일을 돌아보기 ][우아한테크코스] - JUnit5와 AssertJ를 활용한 단위 테스트(Unit Test), TDD를 곁들인[우아한테크코스] - "프리코스 16일차" 2주 차 미션 피드백 숙지, 3주 차 미션 설계, 일주일 plan 설정[우아한테크코스] - "프리코스 17일차" 설계 방식에 대해 고민해보기, 3주 차 미션 MVC 구조 설계 완료[우아한테크코스] - "프리코스 18일차" 클래스 간에..

📝 오늘의 Todo 리스트 체크 코드 리팩토링모든 요구 사항 체크 ✅MVC 디자인 패턴 설계 업데이트 ✅클래스 다이어그램 설계/그리기 ✅  목차한 함수가 한 역할만 하기MVC 디자인 패턴 업데이트클래스 다이어그램예제 테스트 결과 : 예기치 못한 오류로 인하여 실행에 실패하였습니다.한 함수가 한 역할만 하기이번 3주차 미션 프로그래밍 요구 사항 중에 가장 힘들었던 것이 "함수(또는 메서드)의 길이가 15라인을 넘어가지 않도록 구현한다."가 였던 것 같아. 특히 로또 등수에 따라 몇개 당첨 됐는지 확인하는 로직에서 시간이 제일이 많이 소비됐다.  다음과 같이 처음에 구현했다. 하지만 이 메서드를 for문이든 collection이든 스트림 API든 어떤 방법을 사용해도 15줄 이내로 줄이기 힘들었다... 그..

📝 오늘의 Todo 리스트 체크코드 구현 마무리클래스 간에 강한 결합 분석 ✅팩토리 클래스를 도입 ✅(학습) 다양한 Exception의 유형 알아보기 ✅목차클래스 간에 강한 결합 분석 Lotto와 Lottos 클래스 사이의 관계메인 conrtoller 클래스의 합성 관계다양한 Exception의 유형 학습3 주차 미션에 다양한 Exception의 유형을 적용IllegalArgumentExceptionNumberFormatExceptionArithmeticException내일 Todo 리스트클래스 간에 강한 결합 분석 객체 간 참고 관계는 결합도가 가장 높은 관계 중 하나이다. 이것을 합성 관계라고도 부른다. 생명주기가 다른 클래스가 서로를 참조하면, 한 클래스의 수정이나 삭제가 다른 클래스에 영향을 미..