[로또] step2 - 로또(자동) - 최종 피드백 (22일차)

    static Lotto lotto = new Lotto();
    static ArrayList<ArrayList> issuedLottolist = new ArrayList<>();

해당 변수들은 생성자를 통해 초기화하고 있는데요
생성자를 통한다는 것은 인스턴스화를 한다는 것인데, 모든 인스턴스가 공유하는 자원을 생성자로 초기화하는 설계에 어떠한 문제가 있을지 고민해보면 좋겠습니다!

추후 해당 서비스를 웹서비스로 공개하여 실제 로또 서비스를 여러 유저들이 사용할 수 있게 구현한다는 생각으로 접근해보면 좋을 것 같아요 :)

생성자에서 초기화를 하는 것에 대한 문제는,
클래스를 사용할 때 무조건 해당 변수를 인자로 넣어야 한다는 부담감이 생기는 것에 대한 문제 일까요??
LottoMachine에 있던 lastWinningLottoNumberChecker 클래스를 밖으로 빼고, 생성자에서 초기화 하던 부분을 수정하였습니다.

static 변수를 생성자에서 초기화하는 것에 대해 고민해보면 좋겠다는 의미였는데요!
static의 경우 자바 메모리에 딱 한번 초기화되는데 생성자는 인스턴스 생성 시 호출이 됩니다
즉, static 변수를 생성자에서 사용하는 것은 여러 객체를 생성하여도 여러 값을 초기화 할 수 없다라는 것인데요
어떠한 상황에 static 변수를 사용하고, 어떠한 상황에 인스턴스 변수를 사용할 수 있을지 알아보아요 😄

---

import java.util.ArrayList;

 public class ResultView {

도메인 내에 View의 로직을 가지고 있다면 어떠한 문제가 있을지 고민해보아요

기능상에는 문제가 없을 것으로 판단이 되지만,
해당 도메인을 사용하기 위해서는 항상 ResultView라는 클래스가 존재해야 하는 문제점이 발생할 것 같습니다.
이러한 문제 때문에 분리를 하는 것이 옳다고 생각 됩니다.
멘토님은 어떻게 생각하시나요??

lotto 번호가 생성되자 마자 print 해주는 것이 더욱 효율적인 부분도 존재한다고 생각하는데... 아닐까요??
lotto 번호를 반환해서 다시 resultview에 print해줘! 이렇게 명령하는게 좀 비효율적인 부분도 있다고 생각합니다.
이러한 경우에도 꼭 분리해주는 것이 좋을까요??

맞습니다! 도메인이 View에 의존하게 된다는 문제가 존재합니다
시스템 리소스 상의 효율성은 높을 수 있지만, 그 차이는 미비하고 상대적인 단점은 크다고 생각하는데요
도메인은 비즈니스 로직을 담고 있는, 시스템에서 가장 중요한 부분입니다
반해 View의 경우 언제든 요구사항이 바뀔 수 있는 부분으로 우선순위가 낮고 변경될 확률도 높은데요

클린 아키텍처, 헥사고날 아키텍처, 어니언 아키텍처 등 많은 애플리케이션 아키텍처가 존재하지만 모든 아키텍처들의 공통점이 도메인과 View를 가장 멀리하여 도메인을 보호하는 점이라는 공통점이 같다는 사실을 중심으로 고민해보면 좋겠습니다 :)

---

class A {
    상수(static final) 또는 클래스 변수
    인스턴스 변수
    생성자
    팩토리 메소드
    메소드
    기본 메소드 (equals, hashCode, toString)
}

클래스 구현 순서는 위와 같습니다!

 

---

private static final int COUNT_OF_LOTTO_WINNING_NUMBER = 6;
private final ArrayList<Integer> lastWinningLottoNumberArray;

 

"규칙 3. 모든 원시값과 문자열을 포장한다."에 대해 열심히 적용해주셨네요 👍
지금은 전체적으로 static을 사용한 코드를 사용하고 있어 객체 자체가 자신의 역할을 제대로 못하는 경우가 존재하네요!
"규칙 3. 모든 원시값과 문자열을 포장한다."에서 핵심은 자기 자신의 형태와 역할을 분리하는 것으로 볼 수 있는데요

예를 들어 String 클래스가 문자열의 형태를 보장하고 기능을 제공하고,
Ineger 클래스가 정수형의 형태를 보장하고 기능을 제공하는 것 처럼,
LottoNumber가 1~45의 숫자임을 보장한다! 와 같은 방식으로 접근해보면 좋을 것 같아요 ㅎㅎ'

숫자임을 보장하기 위해 LottoNumber 라는 클래스를 만들어서 포장해 보았습니다.
멘토님도 저와 동일한 방법으로 진행하셨는지 궁금합니다! (멘토님이 의도하신 대로 제가 구현을 한 것이 맞는지 의구심이 드네요 ㅜㅜ)

LottoNumber를 잘 분리해주셨어요 👍
이제 Integer로 사용하지 않고 LottoNumber를 사용하여 처리할 수 있게 됐으니, Integer가 아닌 LottoNumber를 활용해보면 좋겠습니다 :)

 

---

도메인에는 핵심 비지니스 로직이 들어가는 곳이기 때문에, 뷰와는 최대한 분리를 하여 보호를 해주는 것이 좋을 것 같다.

모든 원시값과 문자열을 포장하여, 자기 자신의 형태와 역할을 분리하자.

 

오늘 받은 피드백을 잊지 말고, 같은 실수를 반복하지 않도록 하자.

 

천천히, 그리고 꾸준히.

할 수 있다.