[2주차]객체지향 코드 연습(yunjin1213) #29
Conversation
yunjin1213
requested review from
Hoya324,
KoSeonJe and
TaetaetaE01
as code owners
| @@ -0,0 +1,52 @@ | |||
| package lotto.constant; | |||
|
|
|||
| public class Constant { | |||
There was a problem hiding this comment.
클래스의 이름이 너무 광범위 한 것 같습니다. 어떤 상수들의 집합인지 구체적으로 이름을 바꿔주면 좋을 것 같아요
| } | ||
|
|
||
| public static Rank findRank(int matchCount, boolean matchBonus) { | ||
| for (Rank rank : values()) { |
There was a problem hiding this comment.
stream을 활용하면 가독성이 더 좋아질 것 같습니다.
|
|
||
| public static Rank findRank(int matchCount, boolean matchBonus) { | ||
| for (Rank rank : values()) { | ||
| if (rank.matchCount == matchCount && rank.matchBonus == matchBonus) { |
There was a problem hiding this comment.
인스턴스의 필드를 직접 접근하는 건 좋지 않은 방법입니다. get 메소드를 활용해주세요
| import lotto.view.LottoKiosk; | ||
| import lotto.repository.Memory; | ||
|
|
||
| public class KioskStart { |
There was a problem hiding this comment.
클래스 명에 동사가 들어가는 건 의미를 명확하게 전달하는 데 방해가 됩니다.
kiosk를 시작하는 주체가 클래스인데 해당 클래스명이 KioskStart라면 어색할 것 같습니다.
| public class KioskStart { | |
| public class KioskStarter { |
위 이름은 예시인데, 명사로만 구성되는 것이 좋을 것 같습니다
There was a problem hiding this comment.
View라는 패키지 이름을 봤을 때, 입출력을 담당하는 클래스를 집합시켜 놓은 것이라 예측할 수 있습니다.
하지만 해당 클래스는 입출력 이상의 책임을 지고 있는 것 같아, 입출력의 책임을 해당 클래스와 분리시키면 좋을 것 같습니다
| } | ||
|
|
||
| private int requestAmount(Scanner scanner) { | ||
| while (true) { |
There was a problem hiding this comment.
변수를 사용하여 반복문을 통제하는 것이 코드의 의도를 더 쉽게 파악할 수 있을 것 같습니다
| winningSystem.checkWinning(tickets, winningNumbers, bonusNumber); | ||
| } | ||
|
|
||
| private int requestAmount(Scanner scanner) { |
There was a problem hiding this comment.
Scanner를 모두 매개변수로 받아 사용하고 있는데, static 멤버 변수로 선언해도 괜찮지 않을까요?
There was a problem hiding this comment.
해당 클래스가 전혀 사용되고 있지 않은 것 같습니다.
데이터를 저장하는 용도로 사용되고 있는 것 같은데, 좋은 생각입니다.
하지만 저장을 하고 다시 사용하지 않는 것이 아쉽습니다. 다시 사용하는 코드를 생각해본다면 더욱 좋은 결과물이 되지 않을까 생각합니다.
There was a problem hiding this comment.
Main 메소드를 가진 클래스는 보통, 해당 프로젝트의 최상단 패키지에 위치하는 것이 좋습니다.
lotto 패키지에 위치시켜주세요.
There was a problem hiding this comment.
전반적으로 코드의 완성도가 높아진거 같아요! 이제는 객체지향의 원칙에 대해 공부해볼 때가 된 것 같습니다.
객체 지향 설계의 5원칙 S.O.L.I.D
이를 학습하고
적용방법 이를 통해 직접 적용해보시길 바랍니다.
| import lotto.repository.Memory; | ||
|
|
||
| public class KioskStart { | ||
| public static void main(String[] args) { | ||
| LottoSeller lottoSeller = new LottoSeller(); | ||
| Memory memory = new Memory(); | ||
| WinningSystem winningSystem = new WinningSystem(memory); | ||
| LottoKiosk kiosk = new LottoKiosk(lottoSeller, winningSystem); | ||
|
|
||
| kiosk.start(); | ||
| } |
There was a problem hiding this comment.
Main에서 객체를 초기화해서 WinningSystem winningSystem = new WinningSystem(memory); 처럼 의존성을 직접 주입하고 있네요!
만약 이런 의존성이 굉장히 많아진다면 어떻게 될까요? 분명 이 또한 관리하기 어려워질 것입니다.
또한 지금 Application에서는 구현체를 직접 참조하고 있기 때문에 DIP를 위반하고 있습니다. 그럼 어떻게 해야할까요?
SOLID 규칙 지키는 법
간단하게 예를 들자면 아래와 같이 적용할 수 있을거예요!
꽤나 어려울 수 있는 내용이니 꼭 이해하고 넘어가시길 바랍니다.
아래는 WinningSystem을 interface로, WinningSystemImpl을 구현체로 둔 상태입니다.
class AppConfig {
public Memory memory() {
return new Memory();
}
public WinningSystem winngSystem() {
return new WinningSystemImpl(memory());
}
}| private final LottoSeller lottoSeller; | ||
| private final WinningSystem winningSystem; | ||
|
|
||
| public LottoKiosk(LottoSeller lottoSeller, WinningSystem winningSystem) { | ||
| this.lottoSeller = lottoSeller; | ||
| this.winningSystem = winningSystem; | ||
| } |
There was a problem hiding this comment.
LottoSeller와 WinningSystem은 구현체이므로 만약 요구사항이 변경된다면 이 LottoKiosk는 모두 변경되야합니다.
만약 LottoSeller와 WinningSystem가 interface라면 어떻게 될까요?
전체 프로젝트의 변동이 있지 않은 한 변경될 일이 없을겁니다.
이를 참고해서 아래에 OCP와 DIP를 지키는 방법에 대해 고민해보세요!
2주차 과제 제출합니다.
구조도는 다시 깔끔하게 작성해서 올리겠습니다!
LottoStructureFinal .pdf