[우테코 프리코스 2주차] java-racingcar [🤔회고] (캡슐화, view에 데이터 넘기기, 무분별한 상수 처리)

📝 코드 & 설계

[자동차 경주] 김준형 미션 제출합니다. by JHZLO · Pull Request #304 · woowacourse-precourse/java-racingcar-7

 

[우테코 프리코스 2주차] java-racingcar 코드 설명 [🛠️설계] (일급 컬렉션, 원시값 포장, validate의

---

📢 공통 피드백

🔍 README.md를 상세히 작성한다.

🔍 기능 목록을 재검토한다.
정상적인 경우뿐만 아니라 예외 상황도 함께 정리한다

🔍 기능 목록을 업데이트한다.
기능을 구현하면서 문서를 지속적으로 업데이트하는 것을 목표로 한다.
→ 살아있는 문서로 유지될 수 있도록 노력하자.

🔍 값을 하드 코딩하지 않는다.

🔍 구현 순서도 코딩 컨벤션이다.
클래스는 상수, 멤버 변수, 생성자, 메서드 순서로 작성한다.

🔍 변수 이름은 자료형을 사용하지 않는다.
ex) CarNameList

🔍 한 메서드가 한 가지 기능만 담당하게 한다.

🔍 메서드가 한 가지 기능을 하는지 확인하는 기준을 세운다.
15라인이 넘지 않도록 구현하면 의식적으로 메서드로 분리하는 연습을 할 수 있다.

🔍 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리한다.
테스트를 작성하면 기능의 정확성을 점검함을 넘어 코드의 즉각적인 피드백을 받을 수 있다.
테스트 작성 과정을 통해 구현한 기능의 문제를 빠르게 발견할 수 있을 뿐만 아니라,
코드의 구조와 의도를 명확히 이해하는 데도 도움을 받을 수 있다

🔍 처음부터 큰 단위의 테스트를 만들지 않는다.
문제를 작게 나누어 핵심 기능부터 작게 테스트를 만들어 가는 것이 효과적이다.
→ 예외 처리 테스트부터 진행한다.

---

✅ 객체의 캡슐화 제대로 하고 있는가?

객체 지향적인 구조를 설계하면서 주의를 기울여야 하는 부분은 캡슐화이다.

이번 미션을 진행하면서 캡슐화가 제대로 이루어진 부분이 있었다.

☑️ Movable()은 어디에 있는 게 좋을까?

Movable의 위치

Random수를 추출하는 generator는 비즈니스 로직과 관련이 없다고 판단하였고,

random값을 추출하는 Generator를 위와 같이 따로 util 클래스를 분리하였다.

 

그리고 Random수를 추출함과 동시에 Movable()의 조건이 random 수와 밀접하기에, Movable도 같이 정의하였다.

Cars 메서드

그러고 나서 Movable() 메서드를 위와 같이 Cars 객체에서 사용하였다.

 

그런데, 이렇게 사용할 경우 다음과 같은 문제점이 생기게 된다.

 

🤔 Movable()은 핵심 비즈니스 로직이기에 util 클래스로 빼버리게 되면 캡슐화가 깨지게 된다.

 

Movable()은 자동차의 전진조건을 결정하는 핵심적인 비즈니스 로직이다.
따라서, 해당 조건이 util 클래스로 static으로 정의된다면, 
내부 비즈니스 로직이 외부로 빠져나오게 되고, 캡슐화가 깨지게 된다.

따라서 Movable()은 Cars 객체 내부에서 정의하고 Random 수를 추출하는 메서드를 static으로 정의하는 게 좋을 것 같다.

⭐비즈니스 로직이 외부로 유출되지 않게 하자!⭐

 

🤔 위와 같이 정의하게 되는 경우 전진한다는 조건에 대한 테스트 코드는 어떻게 작성할 것인가.

 

만약 위와 같이 RandomGenerator 클래스를 정의하게 된다면 테스트 코드는 다음과 같다.

class RandomGeneratorTest {

    @Test
    void testMovableTrue() {
        // generateRandomNumber가 4 이상일 때 true를 반환해야 합니다.
        RandomGenerator generator = mock(RandomGenerator.class);
        when(generator.generateRandomNumber()).thenReturn(5);  // 5는 MOVABLE_MIN_NUMBER 이상입니다.

        assertThat(generator.Movable()).isTrue();
    }

    @Test
    void testMovableFalse() {
        // generateRandomNumber가 4 미만일 때 false를 반환해야 합니다.
        RandomGenerator generator = mock(RandomGenerator.class);
        when(generator.generateRandomNumber()).thenReturn(3);  // 3은 MOVABLE_MIN_NUMBER 미만입니다.

        assertThat(generator.Movable()).isFalse();
    }
}

 

위와 같이 RandomGenerator를 Mocking 하여 가짜 객체를 만들고 thenReturn을 활용하여

Movable의 조건이 제대로 수행되는지 확인할 수 있다.

 

그러나 RandomGenerator의 코드가 

캡슐화를 고려해 수정된 RandomGenerator 클래스

 

위와 같이 수정된다면, Cars에 대한 메서드는 다음과 같을 것이다.

Cars 메서드 변경

 

이렇게 된다면 테스트 코드에서 RandomGenerator를 Mocking 하는 과정이 필요할 것이다.

 

그러나 RandomGenerator는 static 메서드만을 가지고 있는 util 클래스이기에 크게 문제가 될 건 없어보인다.

따라서 테스트 코드는 다음과 같이 구성할 수 있다.

class CarsTest {

    private Cars cars;

    @BeforeEach
    void init() {
        cars = new Cars("CarA,CarB,CarC");
    }

    @Test
    void 이동가능_차량_전진() {
        RandomGenerator generator = mock(RandomGenerator.class);
        when(generator.generateRandomNumber()).thenReturn(5);

        cars.moveCars();

        cars.getCars().forEach(car -> assertThat(car.getDistance()).isEqualTo(1));
    }

    @Test
    void 이동불가_차량_정지() {
        RandomGenerator generator = mock(RandomGenerator.class);
        when(generator.generateRandomNumber()).thenReturn(3);

        cars.moveCars();

        cars.getCars().forEach(car -> assertThat(car.getDistance()).isEqualTo(0));
    }
}

 

이외에도 이러한 고민에 대해 자세하게 다룬 글이 있어서 참고용으로 남겨놓고자 한다.

 

☑️ 비즈니스 로직이 controller에 있는 것은 아닌지 확인해 보자.

Controller StartRacingGame 메서드

위와 같이 코드를 작성한 이유는 다음과 같다.

 

매 라운드마다 결과를 view에게 넘겨줘야 하기에 
(컨트롤러 -> 모델로부터 라운드 결과 가져오기 -> view)
위의 로직을 반복해야 하였고, 이는 for 문을 통해서 정의해야지 그때그때 view에게 넘겨줄 수 있었다.

 

view에게 모델을 넘겨주지 않고 controller에서 view에게 출력할 값만 전달하기 위한 선택이었다.

 

 

그러나, 어느 한분이 위와 같은 의견을 주셨다.

"각 객체가 가지고 있는 데이터들에 대한 로직은 직접 수행하게 하여 객체가 스스로 자율성을 가지게 하라"

 

이 분의 말씀대로 gameRound.getRound로 값을 가져와서 위와 같은 로직을 수행한다는 것은 결국

GameRound 객체의 필드값을 이용해 비즈니스 로직으로 처리할 수 있다는 것이다.

해당 메서드는 결국 객체지향적인 관점에서 벗어나는 것이고 객체와 협력하는 것을 제대로 구현하지 못한 것이다.

 

차라리 GameRound 내에서 비즈니스 로직으로 처리하여, 각각의 SnapShot을 가지고 있다가 최종 String 값으로 return 하는 것이 좋아 보인다..!

 

⭐추가로 객체와 협력하지 않음을 판단하는 기준을 Getter를 사용할 때 생각해 보는 것이 좋은 것 같다.
해당 메서드를 객체가 할 수 있는지 판단하자!!!⭐

(참고:https://tecoble.techcourse.co.kr/post/2020-04-28-ask-instead-of-getter/)

번외) getter로 가져올 때 변수로 변환 후 집어넣자.

---

✅ view에 모델을 전달해도 될까?

고민되는 부분 - <RacingCar 코드 설명>

 

코드를 설계하면서 위와 같은 고민이 있었다.

 

일단 View에 데이터를 전달할 수 있는 방법은 다음과 같다.

(출처:https://velog.io/@dlguswl936/)

 

1. Model값을 View에게 보낸다.

장점:

- 원시값이 오고 가므로 데이터에 대한 안정성이 생긴다.

 

단점:
- View가 Model을 의존한다?

2. 컨트롤러에서 값을 풀어서 View에게 보낸다.

장점:

-View가 Model을 의존하지 않는다.

단점:
- View의 인자값에 아무 값이나 넣을 수 있으므로 안정성 문제가 생길 수 있다.

- 컨트롤러가 Model에 접근하게 되므로 컨트롤러와 Model 간의 깊은 관여가 생긴다?

 

3. dto를 view에게 넘겨준다.

장점:

- 원시값을 보내므로 데이터 안정성이 생긴다.

- 복잡도를 줄여줄 수 있다.

 

>> 이렇게 많은 방법 중 어떤 방법이 가장 좋을까..?

 

어느 한 분이 다음과 같은 근거를 들어 의견을 남겨주셨다..!

 

view에 모델을 바로 전달하였을 때의 단점은 다음과 같다.

• 유연성이 떨어진다.
• 캡슐화 원칙이 위배될 수 있다.
• 불필요한 데이터가 전달된다.

model을 바로 넘기게 된다면, 유연성이 떨어질 뿐만 아니라 view에서 비즈니스 로직을 알 수 있고,
극단적으로 view에서 모델의 값을 조정할 수 있는 일이 생길 수 있다.

이는 캡슐화 원칙에 위배되는 것이다..!!

 

따라서 변수로 받거나 위처럼 String으로 반환하는 getWinner()를 넘겨주는 게 좋아 보인다.

⭐view에 모델을 넘겨주지 말고, 필요한 정보만 넘겨주자⭐

 

그러나!!!!!!!!!!!

☑️ MVC 패턴 - View가 도메인에 의존해도 된다?

내가 공부했던 MVC 패턴에서 View는 자기 자신 이외에 아무도 알아서는 안된다.

그런데 View가 도메인에 의존해도 된다고..?

이는 View가 도메인을 알아야 한다는 것 아닌가?

 

출처: [10분 테코톡] 제리의 MVC 패턴 https://www.youtube.com/watch?v=ogaXW6KPc8I

 

위에서 다룬 MVC 패턴의 법칙은 이와 같은 주제를 다루고 있다.

위와 같은 내용이라면,

결국 Model에서는 View와 관련된 코드는 다루지 않고,

Model을 View에 전달함으로써 View에서 처리하도록 해야 한다는 것이다.

 

따라서 View가 Model에 의존해야 하는 이유에 대해 다시 공부해 보았다.

⭐View가 Model에 의존해야 하는 이유는 화면에 표시할 데이터의 원천이 Model이기 때문이다!⭐

 

그러면 다시 View에 Model을 전달하였을 때의 단점에 대해 다루어보자.

 

🤔 유연성이 떨어진다?

결국 객체를 View에 직접 전달하게 되면 결합도가 생기게 되고,
이는 객체의 변화가 있을 때 View에서도 수정이 필요할 수도 있다는 것이다.

 

그렇다면, Model을 전달하는 대신, Model이 변경되었을 때 View에서도 수정을 할 필요가 없이 구한다면?

만약 getter와 같은 메서드를 View에서 활용한다고 하면, 이는 오히려 Model이 수정됨에 따라 View도 반영되는 것이다

 

즉 이는 Model이 변경되어도 View가 변경되지 않도록 구현할 수 있다는 것이다!!

 

🤔 캡슐화 원칙이 위배될 수 있다 & 불필요한 데이터가 전달된다?

과연 Model값을 넘겨준다고 해서 캡슐화의 원칙에 위배되는 것일까?

내가 구현했던 방식이다.

 

이렇게 구성한 것이 과연 View가 Cars에 내부구조를 아는 것일까?

=> "그렇지 않다"

 

내부 구조가 노출되지 않는 이유

• 제공하는 데이터가 추상화되어 있음:
  getWinner()는 Cars 객체 내부의 복잡한 로직이나 데이터를 숨기고, 오직 필요한 데이터(우승자 이름)를 외부에 제공하도록 추상화되어 있다.
  getWinner()는 우승자 이름을 반환할 뿐, Cars 객체의 내부 상태나 데이터 구조를 View에 직접적으로 노출하지 않는다.

View는 getWinner()가 어떻게 우승자를 결정하는지에 대해 알 필요가 없고, 단지 결과만 사용한다.

 

즉 내부 구현의 변경이 View에 영향을 미치지 않으며, 

오히려 직접 데이터를 가공하거나 변경하지 않기 때문에 MVC의 역할 분리와 캡슐화가 잘 유지되는 것이다!

 

또한 이를 방지하여 구현할 수 있는 다양한 방법이 있다!

1. DTO를 활용하여 필요한 데이터만 넘겨준다.
2. Observer 패턴을 이용하여 간접적인 의존성으로 구현하자.
3. ISP 원칙을 적용하여 Model이 View에게 필요한 최소한의 정보만 제공하도록 인터페이스를 설계할 수 있도록 하자.

이렇게 진행한다면 결국 View는 Model에만 의존했을 때 이점은 극대화된다!

 

 

• 데이터 제공의 일관성:
  • Model은 애플리케이션의 핵심 데이터를 보관하고 관리한다.
    View는 화면에 표시할 데이터가 필요할 때 Model에서 직접 데이터를 가져와야 한다.
  • 이를 통해 View는 항상 최신 데이터를 가져올 수 있고, Model과 View 간의 데이터 흐름이 명확해진다.
• 역할의 분리:
  • Model은 데이터와 비즈니스 로직을 관리하고, View는 데이터를 화면에 표현하는 역할을 담당한다.
    View가 Model에 의존하는 구조를 통해, View는 오직 데이터를 표현하는 데만 집중하고, 데이터 자체나 로직의 상태 변경은 Model이 처리하도록 역할이 분리된다.
  • 이로 인해 View는 불필요한 비즈니스 로직을 가지지 않고, 화면에 필요한 데이터 표현에만 집중할 수 있다.
• 변경된 데이터를 자동으로 반영:
  • Model에 의존하는 View는 Model에서 데이터가 변경될 때 자동으로 화면을 갱신할 수 있다.
    예를 들어, Model의 데이터가 업데이트되면 해당 변경 사항을 View에서 즉시 반영하여 사용자에게 최신 정보를 제공한다.
  • 이를 통해 View는 지속해서 사용자에게 최신 상태를 표시할 수 있으며, 데이터의 일관성을 유지한다.
• 재사용성과 유지보수성 향상:
  • View가 Model에 의존하도록 설계하면, View는 Model의 데이터를 화면에 표시하는 데만 관여하게 되므로, Model의 내부 구현이 변경되더라도 View는 해당 데이터 인터페이스에만 의존하기 때문에 변경의 영향을 덜 받는다.

 

⭐View가 Model에 의존하도록 구현하자! 단, Model과 View 간의 데이터 흐름을 명확하게 하자.⭐

---

✅ 무분별한 상수 처리..

이번에 상수에 대한 지적을 정말 많이 받았다..

 

이렇게 지적을 받고 나서 상수의 사용에 대한 기준을 명확하게 세우는 것이 중요하다고 생각했다.

 

그러고 나서 상수화를 하는 이유를 다시 곰곰이 생각해 보았다.

 

매직 리터럴을 상수화 하는 내가 내린 결론은 다음과 같다.

매직 리터럴 그 자체로 쓰이면 해당 리터럴이 어떻게 쓰이는지 알 수 없다.
즉 매직 리터럴에 의미를 부여하는 상수로 처리하여 가독성을 높이고 유지 보수성을 높이자!

 

그러면 과연 나는 의미 부여를 목적으로 상수화를 하였는가?

☑️ 무분별한 상수의 사용, 어떻게 기준을 세울 것인가?

 

위의 코드는 내가 이번 미션동안 대표적인 symbol을 클래스로 관리한 목록이다

 

콜론, 콤마, 스페이스 등등.. 

단순히 구분자만 보고도 알 수 있는 symbol인데 이를 매직 리터럴이라고 할 수 있는가?

 

곰곰이 생각해 보니 이렇게 사용하는 것은 너무 무분별하게 상수를 처리한 것 같다..

 

실제로 위와 같이 너무 무분별하게 상수를 사용해서 오히려 가독성이 떨어지는 것이다.

 

이에 대해서도 다양한 리뷰가 달렸는데

 

위와 같이 실제로 Junit5에서 쓰이는 메서드조차 콜론과 스페이스에 대해서는 상수처리를 하지 않는 것이다.

 

따라서, 의미를 부여할 수 있는 리터럴에만 상수 처리하는 것이 더 좋아 보인다!

 

☑️ 같은 속성의 값이라도 의미가 다르다면 상수를 각각 선언하자.

 

또한 이번에 같은 값을 사용하는 ZERO에 대해서 의미는 다른데 같은 속성의 값이라고 같게 사용한 경우가 있었다..

 

하지만 위에서도 다루었듯이 상수를 사용하는 이유는 결국에 의미를 부여하는 것이다.

 

그러나, 같은 속성의 값이라고 단순 ZERO라는 상수를 사용하게 돼버리면 상수 처리를 하려는 본래의 목적을 잃어버리게 되는 것이다.

 

그러므로, 같은 속성 값 0이라도 다른 의미로 쓰인다면 각각의 의미에 맞게 상수를 선언하여 사용하자!

☑️ 상수 선언의 위치?

 

또한 이번 미션을 수행하면서 errorMessage를 한 곳에다가 관리하였는데,

실제로 사용된 것을 확인해 보면, 각각의 클래스에서 static으로 import 하는 과정에서 1번, 실제로 쓰는 과정에서 1번

총 두 번 사용되었다.

 

즉 클래스 내에서 선언해도 충분하다는 이야기이다.

 

이렇게 클래스 내에서 선언해도 충분한데, 따로 클래스로 빼게 돼버린다면 컨텍스트 이해 비용이 크게 발생한다.

 

각각의 사용에 대한 컨텍스트 이해 비용을 정리해 보자.

 

🤔 리터럴 값 그대로 사용

컨텍스트 이해 비용 : 한 단계

- 장점 : 이해 비용이 한 단계이다. 바로 보면 되니가

- 단점 : 의미를 부여할 수 없으므로 어떤 의미인지 확인하기 어렵다.

 

🤔 클래스 내에서 상수처리

컨텍스트 이해 비용 : 상수값 => 필드 선언 상수값

- 장점 : 매직 리터럴에 의미를 부여할 수 있다.

- 단점 : 두 단계의 이해 비용 (but 감당할만하다.)

 

🤔 따로 상수 클래스로 처리

컨텍스트 이해 비용 : 상수값 => static import 한 클래스 => 클래스 내부로 들어가 확인

- 장점 : 여러 곳에서 사용하는 경우 유지보수성에 용이하다.

- 단점 : 총 세 단계의 이해 비용이 발생하므로 가독성이 떨어진다.

 

즉 클래스 내에서만 사용되는 매직 리터럴이라면 클래스 내에서 상수처리를 진행하고,
여러 군데에서 반복적으로 사용되는 경우라면 따로 상수 클래스 만드는 것을 고려하자!

 

 

⭐⭐⭐⭐⭐
🔍 무분별한 상수 사용
콜론, 스페이스, 줄 바꿈 등등 굳이 의미를 부여하지 않아도 되는 문자에 대해서 하는 상수처리는 오히려 가독성을 해치고 유지보수성을 어렵게 한다.
=> 의미를 부여할 수 있는 매직 리터럴에만 상수 처리하자!

🔍 같은 속성 값 = 같은 상수?
상수를 사용하는 이유는 의미를 부여하는 행위이다.
즉, 같은 속성 값이라도 다른 의미를 내포하고 있다면 각각의 의미에 맞게 상수를 선언하여 사용하자!

🔍 상수 선언 위치
해당 클래스 내에서 쓰이는 상수들은 해당 클래스 내에서 선언하자
그럼에도 불구하고 중복적으로 사용되는 상수가 있다면 클래스나 enum을 활용하여 상수처리를 고려하자.
⭐⭐⭐⭐⭐

---

✅ int와 Integer의 차이

Car 객체 내부

이번에 미션을 진행하면서 int와 Integer의 사용에 대한 지적을 받은 부분이 있다.

 

이번 미션에서 각각의 메서드의 역할과 int와 integer의 필요성을 관련지어서 깔끔하게 리뷰를 남겨주셨다!

 

그리고 int와 integer의 차이점에 대해 한 번 다시 정리해 보았다.

int와 integer의 차이점은 다음과 같다.

 

즉 int는 메모리와 성능이 중요한 경우에, 단순히 숫자 값을 저장하고 연산할 때 유리하다.

 

반면, Integer는 객체가 필요하거나 컬렉션과 함께 사용해야 할 때, 또는 null 처리가 필요할 때 유리하다.

 

따라서 다음과 같이 사용 기준에 대해 정해보았다.

⭐
int : 단순히 숫자 값을 저장하고 연산할 때 사용
Integer : null 처리가 필요하거나 컬렉션과 함께 사용해야 할 때 사용
⭐

---

✅ 자주 사용되는 로직, 비즈니스 로직과 관련이 없다면 util로 빼자

 

이번 미션을 진행하면서 아무래도 가장 중요하게 처리했던 점은

"모델 내에서 validate  처리" 였던 것 같다.

 

따라서 valdiate 검증을 기준으로 모델을 나누기도 하였다.

 

 

그러는 과정에서 model에 parserInt를 집어넣어서 try -catch 구문을 이용하여 예외처리 메시지를 출력하도록 구현하였다.

 

그런데 위와 같은 리뷰를 받고 나서, 이러한 생각이 들었다

 

"과연 parseInt는 비즈니스 로직인가? 

비즈니스 로직이 아니라면 따로 util 클래스로 빼어서 처리하는 것이 재사용성 측면에서 더 좋지 않을까?"

 

해당 객체에서 parseInt는 주요 비즈니스 로직이 아니다.

따라서 util 레이어에서 static으로 처리한다면 다음과 같은 이점이 있다.

 

• 1️⃣ 모델은 비즈니스로직에 더 집중할 수 있어진다!
  
  
• 2️⃣ 또 다른 모델이나 입력 값을 처리하는 부분에서 정수로 변환하는 로직을 쉽게 재사용할 수 있다.
  
  
• 3️⃣ 정수 변환 로직과 에러메시지를 한 곳에서 관리하므로 유지보수성에도 용이하다.

 

따라서 위와 같이 util 클래스로 따로 빼어 사용하는 것이 더 좋아 보인다..!

⭐자주 사용되는 로직이고, 비즈니스 로직과 관련이 없다면 util 클래스를 고려해 보자⭐

---

✅ 중복되는 네이밍은 피하자.

이번에 네이밍과 관련해서 지적받은 부분들이 있다.

 

 

이번 미션에서 중복되게 네이밍을 한 부분이 많았다.

 

대표적인 예시로 Car 객체에서 carName으로 정의하였다.

1주 차 공통 피드백에도 나왔듯이

 

"문맥을 중복하는 이름을 자제하자"

 

이처럼, 문맥이 중복된다면 CarName name으로 네이밍을 하는 것도 의미전달에 있어서 충분하다고 생각이 든다!

⭐문맥을 중복하는 네이밍은 자제하자⭐