[🚀 사이클2 - 미션 (블랙잭 베팅)] 코로구 미션 제출합니다.

[korogoo]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?

아직 메서드의 길이가 길어서 리펙터링이 필요한 부분이 있습니다. 우선 기능만 빠르게 구현한 뒤 PR 보내고, 리뷰어님과 더 많은 의견을 나눠보고 싶습니다!

• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

UML

객체 간의 의존관계를 파악하기 위해서 UML 을 작성했습니다.
개인적으로 사용하려고 작성하였으나, 기능 추가로 인한 변경사항 파악에 도움이 될 수 있을까 하여 첨부합니다.
(아직 사용이 미숙해서 잘못된 표기가 있을 수 있습니다..!)

어떤 부분에 집중하여 리뷰해야 할까요?

변경가능한 프로그램 만들기의 적정선

사이클 1에서는 변경에 유연한 프로그램을 만드는 것을 목표로 두고,
변경 가능성이 있다고 판단한 부분에 전략 패턴을 적용하거나 의존성을 주입받는 방식으로 구현했습니다.

예를 들어 카드 생성 시 CardsGenerator 인터페이스를 주입받거나,
승패 판정을 GameReferee 인터페이스로 분리했습니다.

하지만 리뷰를 통해 YAGNI 원칙을 다시 생각해보게 되었고,
현재 요구사항 기준에서는 일부 추상화가 오버엔지니어링일 수 있다고 느껴 사이클 2에서는 제거했습니다.

아직 이러한 확장성을 고려한 설계와 YAGNI 사이의 적정선을 판단하는 것이 참 어렵게 느껴집니다.

보통 썬은 변경 가능성을 고려해 미리 추상화를 도입하는 편인지,
아니면 우테코에서 이야기하듯 현재 요구사항에 집중해 단순하게 구현한 뒤 필요할 때 리팩터링하는 방식을 더 선호하는지 궁금합니다!

상태를 가지지 않는 유틸성 클래스

객체 책임을 분리할 때 가장 어려웠던 부분입니다.

예를 들어 BlackjackGameReferee 같이 특정 규칙에 따라 값을 계산하거나 변환만 수행하는 클래스가 있을 때,
이런 클래스를 별도의 객체로 두는 것이 객체지향적으로 자연스러운지,
아니면 단순한 static 유틸 클래스로 두는 편이 더 적절한지 판단 기준이 아직 명확하지 않습니다.

저는 가끔 이런 클래스들을 만들 때 실제로 도메인 의미를 가진 객체라기보다,
자바에서 static 메서드를 만들 수 있게 열어뒀기 때문에 편의상 만들어지는 객체인 척(?) 하는 객체가 아닌지 생각이 듭니다.

이런 상태가 없는 유틸성 객체를 설계해도 건강한건지,
더 객체지향적으로 풀어나갈 수 있는 방식이 있다면, 어떤 사고 흐름을 학습하면 좋을지 썬의 조언이 듣고싶습니다!

[korogoo]

pr 본문 질문에 대한 코드입니다!

[korogoo]

변경가능한 프로그램 만들기의 적정선

사이클 1에서는 변경에 유연한 프로그램을 만드는 것을 목표로 두고,
변경 가능성이 있다고 판단한 부분에 전략 패턴을 적용하거나 의존성을 주입받는 방식으로 구현했습니다.

예를 들어 카드 생성 시 CardsGenerator 인터페이스를 주입받거나,
승패 판정을 GameReferee 인터페이스로 분리했습니다.

하지만 리뷰를 통해 YAGNI 원칙을 다시 생각해보게 되었고,
현재 요구사항 기준에서는 일부 추상화가 오버엔지니어링일 수 있다고 느껴 사이클 2에서는 제거했습니다.

아직 이러한 확장성을 고려한 설계와 YAGNI 사이의 적정선을 판단하는 것이 참 어렵게 느껴집니다.

보통 썬은 변경 가능성을 고려해 미리 추상화를 도입하는 편인지,
아니면 우테코에서 이야기하듯 현재 요구사항에 집중해 단순하게 구현한 뒤 필요할 때 리팩터링하는 방식을 더 선호하는지 궁금합니다!

[korogoo]

상태를 가지지 않는 유틸성 클래스

객체 책임을 분리할 때 가장 어려웠던 부분입니다.

예를 들어 BlackjackGameReferee 같이 특정 규칙에 따라 값을 계산하거나 변환만 수행하는 클래스가 있을 때,
이런 클래스를 별도의 객체로 두는 것이 객체지향적으로 자연스러운지,
아니면 단순한 static 유틸 클래스로 두는 편이 더 적절한지 판단 기준이 아직 명확하지 않습니다.

저는 가끔 이런 클래스들을 만들 때 실제로 도메인 의미를 가진 객체라기보다,
자바에서 static 메서드를 만들 수 있게 열어뒀기 때문에 편의상 만들어지는 객체인 척(?) 하는 객체가 아닌지 생각이 듭니다.

이런 상태가 없는 유틸성 객체를 설계해도 건강한건지,
더 객체지향적으로 풀어나갈 수 있는 방식이 있다면, 어떤 사고흐름을 학습하면 좋을지 썬의 조언을 구하고싶습니다!

[korogoo]

리뷰 요청 이후에 한 작업입니다!

- README.md 수정
- BlackjackConsoleBootstrap 클래스 패키지 이동
- record 클래스의 불필요한 getter 오버라이드 메서드 제거

DM 으로 푸시 양해를 구하려 했으나, 오밤 중이라서 몰래(?) 커밋 두개 더 푸시 했습니다.

이번 사이클2 리뷰도 잘 부탁드립니다! 감사합니다.ㅎ