3차 코드 구현 by dhlee128 · Pull Request #2 · CODE-CLEANERS/java-coordinate-playground

dhlee128 · 2023-10-14T14:42:04Z

1차 구현

2. 도형 계산 테스트

2. 입력 포맷 유효성 체크

ca1af

1차 리뷰 완료했습니다. 너무 멋집니다 👍 😄

ca1af · 2023-10-16T06:11:17Z

src/main/java/Figure/Line.java

+
+public class Line implements Calculator {
+
+    Points points;


접근제한자를 사용하지 않은 이유가 있을까요?

기본적으로 변수는 private 로 숨겨야하는게 맞는데 ㅎㅎ 수정하겠습니다.

ca1af · 2023-10-16T06:12:59Z

src/main/java/Figure/Square.java

+        List<Double> lens = new ArrayList<>();
+
+        for(int i=1; i<4; i++) {
+            lens.add(stand.getDifferDistance(points.getPoint(i)));


이경우 직선만이 아닌 대각선의 길이도 구해야 하는데, 직선만 구해서 계산하는 방법은 어떤 것이 있을까요?

넵,, 특정 한 점으로부터 나머지 세 점까지의 거리(getDifferDistance)를 구했습니다. 3개 중 가장 큰것이 대각선의 길이라서 나머지 두개만을 사용을 해봤는데 ㅎㅎ

이런식으로 계산하지않고 다른 방식이 있는지 고민해보겠습니다.

ca1af · 2023-10-16T06:13:30Z

src/main/java/Figure/Triangle.java

+        double area = 0.5 * (
+                pointA.getX() * (pointB.getY() - pointC.getY()) +
+                        pointB.getX() * (pointC.getY() - pointA.getY()) +
+                        pointC.getX() * (pointA.getY() - pointB.getY())
+        );


매소드로 나누는 것은 어떨까요?

요것도 너무 중복이 되어보이나요 ;;ㅎㅎ

아뇨! ㅎㅎ 너무 좋습니다.

삼각형 넓이 식이 좀 복잡해서(계산식이 복잡해서), 해주신대로 조금 과하다싶을만큼 매소드로 빼도 괜찮은 것 같아요! 최대한 매소드 그 자체에서 무슨 일을 하는지 알 수 있으면 좋은 것 같습니다 ㅎㅎ

ca1af · 2023-10-16T06:17:05Z

src/main/java/domain/Point.java

+    public static Point initPoint(int x, int y) {
+
+        if (x < 0 || x > 24 || y < 0 || y > 24) {
+            throw new IllegalArgumentException(Constants.INPUT_RANGE_CHECK);
+        }
+
+        return new Point(x, y);
+    }
+
+    public static Point inputStrSeparator(String inStr) {
+
+        String[] values = inStr.replaceAll("[()]", "").split(",");
+
+        return initPoint(Integer.parseInt(values[0]), Integer.parseInt(values[1]));
+
+    }


정적 팩토리 매서드 활용으로 용도를 나누신 점 너무 멋집니다.

다만 정적 팩토리 매서드는 몇가지 네이밍 패턴이 존재하는데요 (of, for 등)

해당 네이밍 패턴을 사용해보면 어떨까요?

오, 알겠습니다. 네이밍에 주의해볼게요!

ca1af · 2023-10-16T06:20:28Z

src/test/java/study/CalculatorTest.java

+    void 입력_좌표_포맷_Test() {
+
+        Throwable exception1 = assertThrows(RuntimeException.class, () -> {
+            InputView.validInputFormat("(3,4)");
+        });
+        assertEquals(Constants.INPUT_FORMAT_CHECK, exception1.getMessage());
+
+        InputView.validInputFormat("(3,4)-(3,5)");
+
+        Throwable exception3 = assertThrows(RuntimeException.class, () -> {
+            InputView.validInputFormat("(3,4)-(3,5)-(3,6)-(3,7)");
+        });
+        assertEquals(Constants.INPUT_FORMAT_CHECK, exception3.getMessage());
+
+        Throwable exception4 = assertThrows(RuntimeException.class, () -> {
+            InputView.validInputFormat("(3,4)-(3,5,8)");
+        });
+        assertEquals(Constants.INPUT_FORMAT_CHECK, exception4.getMessage());
+
+        Throwable exception5 = assertThrows(RuntimeException.class, () -> {
+            InputView.validInputFormat("(3,4)-(3,g)");
+        });
+        assertEquals(Constants.INPUT_FORMAT_CHECK, exception5.getMessage());
+
+    }


효율적인 테스트 코드 작성을 위해 FIRST 라는 원칙에 기반하여 테스트를 작성하는 경우가 많습니다. 참고 링크

한 테스트 매서드 내에서 여러개를 검증하게 되면 어떤 것이 안좋을까요?

하나의 메서드에서 테스트를 할 때에는 전체의 성공 여부가 나와서 어떤 부분부터 실패를 했는가 디버깅을 했었습니다. 이렇게 분리해서 케이스를 작성하니 훨씬 보기에도 편하고 어느부분에서 실패했는지 쉽게 찾을 수 있었습니다!

ca1af · 2023-10-16T06:21:50Z

src/test/java/study/CalculatorTest.java

+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.assertThrows;
+
+public class CalculatorTest {


관심사에 따라(Dot, Line, Triangle, Square) 테스트 클래스를 분리하면 어떨까요?

이렇게 하면 어떤 이점이 있을까요?

(직선, 삼각형, 사각형)=> 을 계산하다 라는 테스트 케이스를 작성을 했었는데,
아무래도 각 도형에 따른 계산법이 다양하게 있다면 각각의 테스크를 분리하면 훨씬 가독성이 좋아지겠지요 !?
디테일하게 테스트가 가능하고 변경이 쉬울 것 같습니다.

2. 접근제한자 3. 정적 팩터리 메서드 패턴 리네이밍

dhlee128 added 2 commits October 14, 2023 00:28

1. 도형 계산 구현

9054ebd

2. 도형 계산 테스트

1. View 구현

e47e4eb

dhlee128 changed the title Dh 1차 코드 구현 (리팩토링 예정, 추후 코드 리뷰 요청 예정) Oct 14, 2023

1. 메시지 정리

ed0e495

2. 입력 포맷 유효성 체크

dhlee128 changed the title ~~1차 코드 구현 (리팩토링 예정, 추후 코드 리뷰 요청 예정)~~ 2차 코드 구현 (코드 리뷰 요청) Oct 15, 2023

ca1af reviewed Oct 16, 2023

View reviewed changes

1. 테스트 케이스를 분리

a81aafc

2. 접근제한자 3. 정적 팩터리 메서드 패턴 리네이밍

dhlee128 changed the title ~~2차 코드 구현 (코드 리뷰 요청)~~ 3차 코드 구현 Oct 23, 2023

Conversation

dhlee128 commented Oct 14, 2023

Uh oh!

ca1af left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants