Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Spring 경로 조회 - 1단계] 연로그(권시연) 미션 제출합니다. #176

Merged
merged 17 commits into from
May 19, 2022

Conversation

yeon-06
Copy link

@yeon-06 yeon-06 commented May 17, 2022

안녕하세요 핀!
이번에 함께하게 되어 정말 영광입니다😆
1단계에는 요구사항이 비교적 적어 금방 PR을 보내게 되었어요!
고민하는 부분, 모르는 부분에 대해서는 코멘트 남기겠습니다 ~

private static final int CHARGED_UNIT_1 = 5;
private static final int CHARGED_UNIT_2 = 8;

private final DijkstraShortestPath<Station, DefaultWeightedEdge> dijkstraShortestPath;
Copy link
Author

@yeon-06 yeon-06 May 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

요번 요구사항의 핵심이 되는 클래스입니다😄
헌데 다양한 크루의 말을 듣다보니 외부 라이브러리를 필드로 두는건 어색한 것 같다라는 의견을 들었어요
이유를 여쭤봤는데 명쾌하게 설득되지는 않았기에 코드를 유지했습니다
핀은 외부 라이브러리를 어떤 식으로 관리/사용하시나요??

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

도메인을 외부 라이브러리를 직접 사용하여 구현하고나서 만약 최단 경로를 다른 라이브러리를 사용하고 싶을 때 라이브러리 인터페이스에 맞게 도메인을 수정해야하는 이슈가 있겠네요.
저라면 도메인이 의존할 최단 경로 구하기 인터페이스 직접 만들고 이를 구현하는 클래스는 외부 라이브러리를 이용하여 구현할 것 같아요. 다른 라이브러리나 구현을 사용하더라도 만들어둔 인터페이스를 구현하여 의존성 주입만 하면 되니 기존 코드에는 변경 없이 확장할 수 있는 유연한 구조가 될 수 있을 것 같아요. 관련 키워드로 OCP, 어댑터 패턴이라고 있는데 찾아보시면 좋을 것 같네요~


private static final int BASIC_COST = 1250;
private static final int CHARGED_COST = 100;
private static final int CHARGED_DISTANCE_1 = 10;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

거리 기준에 따라서 비용 계산법이 조금씩 달라지는데요
기준이 더 추가/삭제될 수 있어서 이름을 CHARGED_XXX_숫자 이런 식으로 통일했어요
마땅히 좋은 방법이 생각나지 않아서 확실하게 구분되게 짓기나 하자라는 생각으로 지었는데 핀이라면 어떤 이름을 지으실 것 같나요?
이름 짓기 너무 어렵네요😢

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이름 짓기 쉽게 설계를 바꾸면 어떨까요? 클래스내에 여러 구현이 존재하고 또 책임에 맞지 않는 일을 하게되면 변수명도 겹치기도 하고 여러 문제로 이름 짓기에 추가적인 어려움이 있을 것이라고 생각해요.

ShortestPath가 운임까지 계산을 해야하나요?! 최단 경로만 구하면 좋지 않을까요?

운임의 경우 운임 정책에 대한 인터페이스를 만들어서 기존운임 정책, 추가운임 정책을 구현해보면 어떨까요?
각 정책들이 구현에 필요한 거리/비용 등을 관리하게 되면 단순히 COST, DISTANCE라고 선언해도 문맥내에서는 이해하기 쉬워져 이름 짓기 고민도 줄어들 것 같아요~

gudonghee2000 pushed a commit to gudonghee2000/atdd-subway-path that referenced this pull request May 18, 2022
* feat: add cors configuration

* refactor: add generic type to ResponseEntity
Copy link

@lalize lalize left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

안녕하세요 연로그!
1단계 잘 구현해주셨네요 👍
몇 가지 리뷰 남겨두었으니 다음 단계 진행하면서 반영해주세요!
pr은 머지하도록 할게요~

Comment on lines +17 to +28
public Section(Long lineId, Long upStationId, Long downStationId, int distance) {
validSection(upStationId, downStationId, distance);
this.lineId = lineId;
this.upStationId = upStationId;
this.downStationId = downStationId;
this.distance = distance;
}

public Section(Long id, Long lineId, Long upStationId, Long downStationId, int distance) {
this(lineId, upStationId, downStationId, distance);
this.id = id;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

주생성자에서 유효성 검사와 모든 필드를 초기화하도록 수정하면 어떨까요?
지금 상태에서는 부생성자가 여러개 생긴다면 각 생성자들이 도메인 규칙을 잘 지켰는지 파악하기 어려울 것 같아요.

Suggested change
public Section(Long lineId, Long upStationId, Long downStationId, int distance) {
validSection(upStationId, downStationId, distance);
this.lineId = lineId;
this.upStationId = upStationId;
this.downStationId = downStationId;
this.distance = distance;
}
public Section(Long id, Long lineId, Long upStationId, Long downStationId, int distance) {
this(lineId, upStationId, downStationId, distance);
this.id = id;
}
public Section(Long lineId, Long upStationId, Long downStationId, int distance) {
this(null, lineId, upStationId, downStationId, distance);
}
public Section(Long id, Long lineId, Long upStationId, Long downStationId, int distance) {
validSection(upStationId, downStationId, distance);
this.id = id;
this.lineId = lineId;
this.upStationId = upStationId;
this.downStationId = downStationId;
this.distance = distance;
}

Comment on lines +54 to +64
private void reduceDistance(int distance) {
this.distance -= distance;
}

public void addDistance(Section other) {
addDistance(other.distance);
}

private void addDistance(int distance) {
this.distance += distance;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private 메서드 시그니처와 구현의 추상화 수준이 같은 것 같은데요 메서드로 추출할 필요가 있을까요? 👀

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getter를 통해 값을 가져오고싶지 않아서 해당 방식으로 구현을 하였습니다!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this.distance += other.distance 해도 되지 않나요?

}

public void updateUpStationId(Long id) {
this.upStationId = id;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

별도 유효성 검사가 없어도 괜찮을까요?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

어떤 유효성 검사를 말씀하시는걸까요 ?_?
도메인의 상태를 변경하는데 유효성 검사가 필요한가요!?
DB에 존재하는 id인지 확인하는 거라면 Service에서 검증했습니다

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

구간의 상행과 하행이 같으면 안되거나 하는 도메인 규칙이 있어야 하지 않을까요?

Comment on lines +20 to +27
public Sections(List<Section> value) {
this.value = value;
}

public List<Long> getSortedStationIds() {
if (CollectionUtils.isEmpty(value)) {
return new LinkedList<>();
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

객체 생성시 아래 예외 케이스를 무시하고 생성될 수 있는데 문제가 없을까요?

  • 상행역과 하행역 둘 중 하나도 포함되어있지 않으면 추가할 수 없음
  • 상행역과 하행역이 이미 노선에 모두 등록되어 있다면 추가할 수 없음
  • 역 사이에 새로운 역을 등록할 경우 기존 역 사이 길이보다 크거나 같으면 등록을 할 수 없음

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

덧붙여서 Line의 Section은 무조건 1개이상 있어야 하니 null과 빈 리스트를 허용하지 않도록 추가도 필요하겠네요!
도메인 규칙을 잘 지킨 완전한 상태의 객체는 메서드 내부에서 null 체크와 CollectionUtils.isEmpty로 NPE를 피하는 등 객체 상태가 훼손된 경우를 고려하여 작성한 불필요한 코드를 줄일 수 있지 않을까요?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Sections 객체를 생성하기 전 Service에서 검증된 부분입니다. 다만 핀 말씀을 들어보니 굳이 DB 호출하면서 확인할 필요 없이 도메인에서 검증할 수 있을 것 같아요!
  2. Sections.validNewSection()에서 모두 등록된 경우 Exception이 발생하도록 처리했습니다
  3. Section.reduceDistance()에서 거리가 0 이하로 변경될 여지가 있으면 Exception이 발생하도록 했습니다! Sections에서 검증할 수도 있지만 Section의 상태에 대한 검증이니 Section의 책임에 더 가깝다고 생각했어요

Line의 Seciton은 무조건 하나 이상 있어야하는 부분은 깜빡하고 있던 부분이라 수정하겠습니다😭

Comment on lines +72 to +80
if (newSection.isSameDownStationId(section)) {
throw new IllegalArgumentException(CREATE_CROSSROADS_LIST_ERROR);
}

if (newSection.isSameUpStationId(section)) {
section.updateUpStationId(newSection.getDownStationId());
section.reduceDistance(newSection);
return Optional.of(section);
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

뎁스를 1로 줄여볼 수 있을까요?


private static final int BASIC_COST = 1250;
private static final int CHARGED_COST = 100;
private static final int CHARGED_DISTANCE_1 = 10;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이름 짓기 쉽게 설계를 바꾸면 어떨까요? 클래스내에 여러 구현이 존재하고 또 책임에 맞지 않는 일을 하게되면 변수명도 겹치기도 하고 여러 문제로 이름 짓기에 추가적인 어려움이 있을 것이라고 생각해요.

ShortestPath가 운임까지 계산을 해야하나요?! 최단 경로만 구하면 좋지 않을까요?

운임의 경우 운임 정책에 대한 인터페이스를 만들어서 기존운임 정책, 추가운임 정책을 구현해보면 어떨까요?
각 정책들이 구현에 필요한 거리/비용 등을 관리하게 되면 단순히 COST, DISTANCE라고 선언해도 문맥내에서는 이해하기 쉬워져 이름 짓기 고민도 줄어들 것 같아요~

private static final int CHARGED_UNIT_1 = 5;
private static final int CHARGED_UNIT_2 = 8;

private final DijkstraShortestPath<Station, DefaultWeightedEdge> dijkstraShortestPath;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

도메인을 외부 라이브러리를 직접 사용하여 구현하고나서 만약 최단 경로를 다른 라이브러리를 사용하고 싶을 때 라이브러리 인터페이스에 맞게 도메인을 수정해야하는 이슈가 있겠네요.
저라면 도메인이 의존할 최단 경로 구하기 인터페이스 직접 만들고 이를 구현하는 클래스는 외부 라이브러리를 이용하여 구현할 것 같아요. 다른 라이브러리나 구현을 사용하더라도 만들어둔 인터페이스를 구현하여 의존성 주입만 하면 되니 기존 코드에는 변경 없이 확장할 수 있는 유연한 구조가 될 수 있을 것 같아요. 관련 키워드로 OCP, 어댑터 패턴이라고 있는데 찾아보시면 좋을 것 같네요~

Comment on lines +27 to +68
@DisplayName("최단 경로 찾아주는 객체를 초기화한다.")
@Test
void create() {
// given
ShortestPath shortestPath = new ShortestPath(stations, sections);

// when
List<Station> result = shortestPath.findPath(station3, station1);

// then
List<Station> expected = List.of(station3, station2, station4, station1);
assertThat(result).isEqualTo(expected);
}

@DisplayName("거리 계산하기")
@Test
void calculateDistance() {
// given
ShortestPath shortestPath = new ShortestPath(stations, sections);

// when
int result = shortestPath.calculateDistance(station3, station1);

// then
assertThat(result).isEqualTo(5);
}

@DisplayName("거리 계산하기")
@ParameterizedTest(name = "{0} km -> 요금 {1}원 예상")
@CsvSource(value = {"5,1250", "44,1950", "60,2250"})
void calculateScore2(int distance, int expected) {
// given
List<Station> stations = List.of(station1, station2);
List<Section> sections = List.of(new Section(1L, 1L, station1.getId(), station2.getId(), distance));
ShortestPath shortestPath = new ShortestPath(stations, sections);

// when
int result = shortestPath.calculateScore(station1, station2);

// then
assertThat(result).isEqualTo(expected);
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

요구사항에 비해 테스트 케이스가 충분하지 않은 것 같아요.

@lalize lalize merged commit ad60643 into woowacourse:yeon-06 May 19, 2022
TheDevLuffy pushed a commit that referenced this pull request May 20, 2022
* feat: default code

* chore: update package.json

* chore: adjust new specification (#174)

* refactor: remove frontend code

* refactor: flatten project structure

* docs: remove frontend guide

* refactor: remove unusable resources

* chore: Update versions

* feat: add cors configuration (#176)

* feat: add cors configuration

* refactor: add generic type to ResponseEntity

* [Spring 지하철 노선도 - 1,2단계] 써머(최혜원) 미션 제출합니다. (#240)

* feat: 존재하는 이름 입력 시 예외 발생

* feat: 예외 처리를 위한 ExceptionHandler 추가

* feat: 노선을 나타내는 Line 및 데이터 관리를 위한 LineDao 추가

* feat: 노선 생성 기능 추가

* feat: 노선 중복에 대한 검증 추가

* feat: 노선 조회를 위한 기능 추가

* feat: 단일 노선 조회 기능 추가

* feat: 노선 수정 기능 추가

* feat: 노선 삭제 기능 추가

* feat: 2단계 준비를 위한 세팅 추가

* feat: JDBC를 활용한 지하철역 저장 기능 추가

* test: 중복 지하철역 이름에 대한 예외 테스트 추가

* feat: JDBC를 이용한 모든 지하철역 조회 기능 추가

* refactor: StationController 기존 Dao 의존성 변경

* feat: JDBC를 활용하여 지하철역 삭제 기능 추가

* feat: JDBC를 활용하여 노선 저장 기능 추가

* test: 노선 중복 예외 검증 테스트 추가

* test: 존재하지 않는 노선 조회시 예외 검증을 위한 테스트 추가

* feat: JDBC를 활용하여 노선 수정 기능 추가

* feat: JDBC를 활용하여 노선 전체 조회 및 단일 삭제 기능 추가

* refactor: LineController 의존성 변경

* feat: 예외 처리 로직 분리

* refactor: 인수 테스트를 위한 schema 수정

* refactor: 불 필요한 메서드 제거

* style: 쓰이지 않는 import 문 제거

* refactor: 컨트롤러 @RequestMapping을 이용한 공통 매핑 value 단축

* feat: 500 상태 코드애 대한 에러 메세지 추가

* refactor: 테스트 코드에서만 사용하는 메서드를 운영 코드에서 제거

* feat: LineService 추가

* feat: StationService 추가

* refactor
: 테스트 코드 변수 명 변경 및 코드 단축

Co-authored-by: hyeonic <dev.hyeonic@gmail.com>

* feat: 도메인 기본 검증(필드값 존재여부) 추가

* refactor: 프로덕션에서 사용하지 않는 코드 테스트로 이동

* docs: 3단계 기능 요구사항 작성

* feat: 두 구간 간의 관계를 구한다

* refactor: 구간-구간 관계 계산을 구간 컬렉션-구간 으로 변경

* feat: 구간 컬렉션과 새 구간이 완전히 겹치거나 다를 때 예외 처리

* feat: 구간 컬렉션에 같은 방향 종착역을 공유하는 구간 추가

* feat: 구간에서 겹치는 구간을 빼는 기능

* refactor: 구간 간의  검증을 구간으로 이동

* feat: 상행역을 공유하는 경우의 노선 추가

* feat: 하행역을 공유하는 노선 추가

* feat: 두 구간 합치기

* feat: 노선 역 삭제 - 상/하행 종점역인 경우

* feat: 종점이 아닌 역 삭제 시 인접 노선 재설정

* refactor: 테스트 코드 개선

* feat: 노선에서 구간 추가, 역 제거

* feat: 노선 생성자에서 구간 정렬

* feat: 노선 간에 변경된 구간을 탐지

* refactor: 변경 구간 찾는 기능 삭제

* refactor: 구간 정렬 방식 변경

* jdbc 구간 저장

* feat: 특정 노선에 해당하는 모든 구간 조회

* refactor: LineDao가 LineDto를 사용하도록 변경

* feat: repository를 통한 새로운 노선과 구간 저장

* feat: 레포지토리로 노선 조회

* feat: 노선 생성 인수 테스트 수정과 컨트롤러 테스트 작성

* refactor: 반환형 변경에 따른 테스트 수정

* refactor: Sections의 메서드 반환형 변경

* feat: 단일 노선 조회 컨트롤러 테스트

* feat: 역 컨트롤러 역 생성, 모든 역 조회 테스트

* feat: 컨트롤러 단일 역 삭제 테스트

* feat: 역 생성 400 예외처리 테스트

* refactor: 존재하지 않는 pk값 조회 시 404 에러 반환 및 테스트 작성

* refactor: 메서드 변수 선언 제거

* refactor: 테스트 패키지 이동

* refactor: 메서드 시그니쳐 변경으로 깨지는 테스트 수정

* docs: api 요구사항 정리

* build: sql 생성문 수정

* style: 불필요한 import제거

* build: sql문 수정

* refactor:
인수 테스트 수정

* style: 불필요한 import와 클래스 제거

* refactor: 노선 삭제 시그니쳐 변경에 따른 리팩터링

* refactor: 외래키 지정에 따라 걔지는 테스트 정정

* feat: api 구간 등록 및 제거

* refactor: 사용하지 않는 dao 제거

* refactor: 사용하지 않는 import문 제거, 생성자 중복 제거

* fix: 구간이 하나뿐일 때 삭제 예외처리 하지 않는 오류

* feat: request에 대한 null 검증

* build: sql drop table 부분 주석처리

* fix: service에 transactional 어노테이션 추가

* refactor: 테스트용 sql문 분리 추가

* refactor: 메서드 파라미터 변경

* refactor: spring boot validation을 이용한 request 값 유효성 검증

* feat: 빈 데이터값에 대한 NOT_FOUND 응답에 바디 메세지 추가

* refactor: 생성자를 private 지정

* fix: valid 어노테이션을 숫자에 적합한 타입으로 변경

* refactor: 쿼리문 반복 실행을 한 번에 모든 값을 가져오도록 개선

* refactor: 쓰지 않는 생성자 파라미터 제거

* refactor: 메서드 분리 및 반환형 개선

* feat: 라인 컨트롤러 통합 테스트 작성

* feat: 역 컨트롤러 통합 테스트 작성

* fix: 구간 추가 오류 수정

* refactor: 크기 검증용 assert 메서드 변경

* refactor: Relation enum 클래스 제거, 메서드 통합

* feat: section 레포지토리 테스트 작성

* refactor: 레포지토리 - dao 계층 통일

* refactor: line 레포지토리 통합 테스트 작성

* refactor: 사용하지 않는 import문 제거

* refactor: 메서드 분리

* refactor: 테스트 케이스 displayName을 좀 더 상세히 작성

* fix: db 데이터 삭제가 필요한 테스트에 테스트용 sql문 실행

* build: 의존성 추가

* docs: 기능 요구 사항 작성

* test: 최단경로 라이브러리 학습 테스트 작성

* test: 최단경로 라이브러리 테스트

* feat: 최단 경로 찾기

* feat: 요금 계산 기능 추가

* feat: 요금 계산 기능 추가

* path 서비스 개발

* feat: 경로 조회 api 추가

* test: 최단경로 인수테스트 작성

* fix: getStations 로직이 순서를 보장하도록 개선

Co-authored-by: gracefulBrown <brown@woowahan.com>
Co-authored-by: 임동준 <im1@woowahan.com>
Co-authored-by: 브리 <buyong.jo@woowahan.com>
Co-authored-by: hyeonic <dev.hyeonic@gmail.com>
Co-authored-by: bomi <bonita9931@gmail.com>
choihz pushed a commit that referenced this pull request May 21, 2022
* feat: default code

* chore: update package.json

* chore: adjust new specification (#174)

* refactor: remove frontend code

* refactor: flatten project structure

* docs: remove frontend guide

* refactor: remove unusable resources

* chore: Update versions

* feat: add cors configuration (#176)

* feat: add cors configuration

* refactor: add generic type to ResponseEntity

* [Spring 지하철 노선도 - 1,2단계] 리버(구동희) 미션 제출합니다. (#248)

* docs: 기능 요구사항 작성

* feat: 지하철 역 관리 API 기능

* feat: 지하철 노선 등록 기능

* feat: 지하철 노선 목록 기능

* feat: 지하철 노선 조회

* feat: 지하철 노선 수정

* feat: 지하철 노선 삭제

* feat: Station 관리 Spring 애노테이션 적용

* feat: Line 관리 Spring 애노테이션 적용

* refactor: 불필요한 라이브러리 제거 및 공백 수정

* docs:기능 요구사항 업데이트

* refactor: StationController의 중복되는 API Mapping을 RequestMapping으로 변경

* refactor: LineController의 중복되는 API Mapping을 RequestMapping으로 변경

* refactor: 지하철역과 지하철 노선이 중복되는 경우를 잡는 로직 변경

* test: test 패키지의 schema.sql을 사용하여 Dao 객체 테스트

* test: Service 객체 테스트 조건 추가

* test: E2E테스트와 Dao 테스트에 @Sql을 통해 test Schema 연결

* test: E2E테스트에서 response body도 테스트하도록 변경

* test: Dao 테스트의 부모객체 생성

* refactor: 예외발생시 커스텀예외 추가

* feat: 지하철역 삭제요청시 지하철역 정보가 DB에 없으면 예외발생

* feat: LineService 예외 발생 추가

1. id를 통해 지하철 노선 조회시 id가 DB에 존재하지 않으면 예외발생
2. id를 통해 지하철 노선 삭제시 id가 DB에 존재하지 않으면 예외발생
3. id를 통해 지하철 노선 시 업데이트시 id가 DB에 존재하지 않으면 예외발생
4. 지하철 노선 업데이트시 중복되는 이름으로 업데이트시 예외발생

Co-authored-by: jaejae-yoo <wotj102@gmail.com>

* fix: Service 객체가 잘못된 예외를 잡아내는 오류 수정

* feat: 구간정보를 SectionDao를 통해 DB에 저장

오류가 나는 테스트 및 프로덕션 코드 주석처리

* refactor: 지하철 노선 등록시, 정보를 DB에 추가로 저장

1. 상행역 정보 저장
2. 하행역 정보 저장
3. 상행역과 하행역 사이의 거리 저장

오류가 나는 테스트 및 프로덕션 코드 주석처리

* refactor: 지하철 노선 조회시 노선에 등록된 지하철역 정보도 같이 전달

오류가 나는 테스트 및 프로덕션 코드 전체 수정

* refactor: 노선 정보 등록시 LineService 내부 로직 변경

* refactor: 노선 정보 조회와 관련된 로직 변경, 테스트 코드 수정

* feat: 구간 등록 시, 등록 할 구간의 노선에 상행역과 하행역이 모두 없으면 예외 발생

* feat: 구간 등록 시, 등록 할 구간의 노선에 이미 상행역과 하행역이 모두 등록되어 있으면 예외 발생

* feat: 노선 정보를 가져올 때, 구간 순서별로 정렬하여 데이터를 전달하도록 변경

* feat: Sections의 상태에 Section을 추가하고, Sections의 상태 변경

* feat: 구간을 추가 할 때, 기존 구간 길이보다 추가하려는 구간 길이가 짧거나 같으면 예외발생

* feat: 노선에 지하철 구간을 추가

* refactor: Sections의 함수 네이밍 변경

* feat: 역의 아이디 값에 따라 구간을 삭제

* feat: 종점 구간 제거 및 전체 구간이 한개 있을때 구간을 제거 하면 예외 발생

* refactor: 하행 종점이 삭제 되지 않는 오류 수정

* feat: 구간에 대한 커스텀예외 추가

* refactor: Controller 객체의 불필요한 () 제거

* refactor: LineService.save() 오류 발생시 DB에 데이터를 저장을 하지 않도록 변경

* refactor: SectionDaoImpl.findByLineId()의 쿼리문 소문자를 대문자로 변경

* refactor: Sections.addStationInSection() 메서드 반환값 변경

* refactor: LineService의 stationOnLine() 메서드명 변경

* refactor: LineService와 StationService의 불필요한 예외처리 제거

* refactor: LineService.updateLine() 로직 변경

* refactor: LineController의 잘못된 메서드명 변경

* refactor: Dao 객체의 hardDelete를 softDelete로 변경

* refactor: Sections의 몇가지 함수 지역변수 추가

* refactor: SectionDaoImpl.findByLineId() 쿼리문 변경

* refactor: StationService와 LineService의 함수 로직변경

* docs(README): 1단계 기능 요구사항 작성

* feat: 지하철 노선 추가요금 추가

* feat: 지하철 전체 경로 조회

* feat: 지하철 목적지 최단 경로 얻기 기능구현

* refactor:최단거리 계산을 위한 subwayGraph 생성

* feat: 지하철 경로 거리 계산 기능 구현

* feat: 지하철 경로 요금 계산 기능 구현

* refactor: 메서드 분리 및 매직 넘버 제거

* feat: 지하철 경로 조회 API 구현

* refactor: 경로 탐색 관련 객체 메서드 분리

* test: 경로 조회 테스트 작성

* refactor: 경로 조회 객체의 파라미터 final 키워드 추가

* refactor: 상태코드 별로 exception handle하도록 수정

* refactor: 불필요한 import문 수정

* refactor: 불필요한 생성자 파라미터 제거

* refactor: status code 200 shortcut 이용 및 상태코드 수정

* test: api 이용하여 데이터 삽입시, 불필요한 추출로직 제거

* refactor: SubwayGraph 변수 제네릭 수정

* refactor: dao 구현체 네이밍 수정

* refactor: Line id 타입 수정 및 생성자 오버로딩 적용

* test: 중복 로직 메서트 추출 및 assertAll 적용

* test: FareCalculator test 이름 수정 및 테스트 케이스 추가

* refactor: station 삭제 후, save되도록 수정

* feat: distance, extraFare 양수 검증 로직 추가

* refactor: soft delete 적용시 저장 로직 수정

* refactor: 예외 handler 및 불필요한 import문 제거

* refactor: final 선언 및 dto 정적팩토리메서드 설정

Co-authored-by: gracefulBrown <brown@woowahan.com>
Co-authored-by: 임동준 <im1@woowahan.com>
Co-authored-by: 브리 <buyong.jo@woowahan.com>
Co-authored-by: 구동희 <71062817+gudonghee2000@users.noreply.github.com>
Co-authored-by: jaejae-yoo <wotj102@gmail.com>
Co-authored-by: koo <gudonghee2000@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants