개발 기록

[Error] 일정 관리 트러블슈팅 3 - URI 설계 (User)

이전 트러블슈팅 [Error] 일정 관리 트러블 슈팅 1 - 제네릭제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았는데 그 과정에서 시행착오가 많았기 때문에 정리해보려고devz0.tistory.com [Error] 일정 트러블 슈팅 2- 양방향/단방향첫번째 트러블슈팅 [Error] 일정 관리 트러블 슈팅 1 - 제네릭제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았devz0.tistory.com문제 상황 처음에 User URI 설계를 다음과 같이 진행했다.PATCH /users/{userId}POST /users/{userId}/delete이때 서..

[Error] 일정 관리 트러블 슈팅 2- 양방향vs단방향

첫번째 트러블슈팅 [Error] 일정 관리 트러블 슈팅 1 - 제네릭제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았는데 그 과정에서 시행착오가 많았기 때문에 정리해보려고devz0.tistory.com문제제네릭이 문법적으로 가장 시간이 많이들어갔다면 양방향 단방향 연관 관계설정은 생각을 정리하느라 시간이 많이 소요됐다.리팩토링을 진행하며 User, Schedule, Comment 세 도메인 간 연관관계를 다시 보던 중, “단방향으로 유지할지, 양방향으로 전환할지” 판단이 애매했다. 특히, 단건 조회에서 일정과 댓글을 함께 보여주는 엔드포인트 설계를 하며 “일정 단건 조회시 댓글목록을 항상 참조하는데 Schedule ↔ Com..

제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았는데 그 과정에서 시행착오가 많았기 때문에 정리해보려고 한다.문제 1- 전역 validator validator를 앞으로 도메인 추가될 것을 생각해 전역으로 관리하고 싶었다. Schedule, User, Comment 다른 도메인에서도 거의 동일한 패턴의 검증 로직이 필요했는데 각각의 도메인명에 맞는 메소드를 계속 추가하자니 전역으로 관리하는 이유가 없었다.❌ 기존 코드public Schedule findScheduleOrException(Long scheduleId) { return scheduleRepository.findById(scheduleId) ..

어려웠던 부분1.JPA 관계 설정ERD도 그려봤고 엔티티에도 다대일 일대다 양방향 관계 설정도 했다. 문제는 DTO. 사실 그냥 내 문제잘못된 설계Comment comment = new Comment( request.getContent(), request.getUsername(), request.getPassword(), request.getTodo() // ❌ request에서 Todo를 직접 받음);이건 request DTO에 Todo 엔티티가 직접 들어있다는 전제인데, 클라이언트는 Todo 엔티티 구조를 모름 Todo의 id만 알고있음DTO는 엔티티를 몰라야함!!또한 JPA가 관리하지 않는(영속되지 않은) Todo 객체가 들어가면 연관관계가 깨질 수 있음DTO는 단순히 데이..

벌써 다시 개발을 시작한지 한달이 흘렀다. 이 소중한 시간을 어떻게 보냈는지 되돌아보려고 한다.들어가기이번 달은 본격적으로 Java 개발자를 목표로 공부를 시작한 첫 달이었다. ‘객체지향’이라는 말이 어렵게만 느껴졌지만, 직접 코드를 써보면서 조금씩 감이 오기 시작했다. 자바 기간 주요 목표는 기본 문법과 컬렉션 등, 그리고 객체 설계 감각을 익히는 것이었다.한달 동안의 학습은 커리큘럼 강의와 자바 문법은 프로그래머스 문제들로 익혀갔다.어려웠던 점 & 해결과정건강상의 이유로 개발을 그만둔지 너무 오래된 상태였어서 다시 기본으로 돌아가는 것 자체가 힘들고 어려웠다. 그전에 이만큼 했으니까 더 잘해야 할텐데 라던지 더많이해야할텐데 같은 내 현실을 직시하고 기본기를 다지는 그 시작부터 어려웠다.그래서 한달..

[Error] 키오스크 트러블 슈팅 1 - 상태 패턴enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가devz0.tistory.com [Error] 키오스크 트러블 슈팅 2 -책임 분리이전 글에서 이어지는 내용 [Error] 키오스크 트러블 슈팅 1enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기devz0.tistory.com오래되긴 했지만 API 만들어본 경험이 있어서 과제 로직 구현 자체는 어렵지 않았다. 객체 지향 적인 코드 흐름 문제 제외하고 가장 생..

이전 글에서 이어지는 내용 [Error] 키오스크 트러블 슈팅 1enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가devz0.tistory.com키오스크 프로그램을 작성하면서 상태패턴을 도입했다.Kiosk 클래스가 State를 관리하고, 각 상태(START, MAIN_MENU, SUB_MENU, CART, ORDER)는 사용자의 입력에 따라 다음 상태로 전이된다.초기 설계에서는 Kiosk 내부에서 상태 전이(currentState = State.MAIN_MENU)를 직접 수행했지만,점차 책임 분리의 중요성을 알게되며 로직을 수정하다 State와 Kios..

enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가 굉장히 길었는데 그 부분은 간략하게 생략되었지만 고려해봐야할 몇가지 문제가 생겼다. 그 과정을 정리해보려고 한다.목표기존 enum + switch 구조에서 상태 패턴(State Pattern)을 적용하여 Kiosk 클래스의 start 메소드 단순화 및 코드 재사용성 향상을 시도상태 패턴 적용 후 장점 start() 메소드가 간단해지고, 상태 전환 로직이 상태 객체로 분리됨.상태별 클래스(StartState, MainMenuState, ...)를 독립적으로 관리 가능 → 재사용성, 확장성 향상.새로운 ..

기능 구상Level1. 클래스 없이 만드는 계산기양의 정수 2가지 , 사칙연산기호 한가지 입력양의정수는 각각 하나씩 입력, 정규식 검사 후 int 타입으로 변수에 저장사칙연산 기호는 char 타입으로 변수 저장연산 진행switch문을 사용해 각 연산자에 맞게 진행나눗셈 연산에서 두번째정수에 0이 입력될 경우 오류 출력exit 문자열 입력 전까지 계산 진행각각의 인풋값 입력단계에서도 exit 입력시 연산 끝낼 수 있도록 로직 작성각각의 계산이 종료될때도 exit 입력할 수 있도록 작성대소문자 관계없이 비교하는 String.equlsIgnoreCase를 발견해서 적용Level2. 객체 지향 계산기기능으로 클래스 분리 Calculator 클래스사칙연산 수행인풋값 입력시 검증 메소드결과값 반환, 연산 결과 리..