뒤로 이동 버튼을 눌러 페이지 전환이 잘 되었음을 검증하고 싶으면 history web api 등을 이용해서 검증하는게 더 올바르지 않나요??왜 useNavigate 의 반환 함수의 인자로 검증하는지 궁금합니다~

이 코드에서 Game은 GameLoop만 알지만Cui, Gui는 GampLoop와 Game을 동시에 알죠.즉 Gamp과 Cui, Gui은 쌍방향 참조로 봐야하지 않을까요. 실제 Game을 수정하면(exe로 메소드명을 바꾼다던가) Gui, Cui도 수정해야하니까요.

astractreader인데...

parser.. 

parser..

이 그림 자체의 문제라기보다 도출되는 과정의 문제인데요.과정을 보면JsonReader와 CsvReader의 코드를 관찰한다.공통점을 발견한다.상위모듈에 그 공통점을 기술한다.이렇게 했단 말이죠.헌데 이건 하위모듈의 구현상의 공통점으로 xml리더나 html리더를 만들 때도 그 공통점이 일어난다고 보장할 수는 없을 거에요. 특히 이 코드는 전적으로 로컬파일시스템에서 읽을 때나 readLines가 일치하지 원격파일 리소스에서 읽어 들일 때는 그렇지도 않죠.즉 하위 구현에서 얼마든지 공통점은 달라질 수 있는데 그걸 단단한 상위모듈에 모아서 정의해도 되냐는 것입니다. 저는 인터페이스까지는 몰라도 추상클래스는 하위모듈에 있어야한다고 생각이 듭니다.

이걸 정말 실무에서 실현하시는지 궁금해요.이건 뭐랄까 정말 이론적인 얘기 같아요.이 예제가 아주 적절한데, 보통 저런 구조의 별도 모듈에 구현되는 하위수준의 기능은 라이브러리이거나 스탠드얼론 생태계를 갖는게 일반적이죠.이건 실무적으로 보면 잭슨이 우리회사 인터페이스에 따라서 만들어져야한다 라고 말하는 것에 가까운 느낌이랄까,저는 실무적에서 기능 모듈의 인터페이스가 도메인 모듈에 소속되게 만든 경험이 아예 없는 거 같아요. 소시적에 이론 따라 몇 번 해봤는데 완전 별로였거든요.

자바 클래스 라이브러리들 조차도 대부분의 명령에 boolean을 반환하죠. 이게 고민인데 명령인 메소드는 반드시 void인가 하는 점입니다.

player.currentRoom() 까지는 디미터 위반이 아니지만player.currentRoom().name()이나 description()은 디미터 위반인거 같아요.특히 그 다음 장표에서 player의 내부 생태계에 Room을 포함한 그림이 나오는데 Room의 변화가 Game의 수정을 유발하니까요.

안그래도 영상이 뭔가 갑자기 슬라이드 몇장이 잘못넘어간 느낌으로 재생되다가 11:25초를 보면 코드가 다시 디미터 법칙 위반 상태로 왼쪽이 되돌려져있어요

오버엔지니어링인거 같은데 굳이 sealed에 record를 동원할 필요가 있는가 해서요.아 그냥 딴지거는 건 아니고 평소 개발자들에게서도 쓸데없는 클래스 구조물 생성을 너무 자주 보다 보니 ^^; 직렬화할 때도 어려워지고 그래서요.

의문이 드는게 어디냐면 calc에서Money.won( (long) Math.ceil( money.doubleValue ))을 통해서 Money를 만들어내잖아요.일단 설명의 용이성을 위해 static won이나 메소드 doblueValue 생략하신건 문제 없습니다만..1. money.doubleValue는 환률과 무관한 컨텍스트로 토해지는 값인거 같은데2. 그 값을 바탕으로 won을 통한 Money를 만들어도 되는거냐싶은 생각이 너무 들어요 ^^;아예 값과 참조에 집중하려면 Money.value(long)같은걸로 했어야 하지 않았나 싶은...실제 이어지는 ceil의 메소드화에서는 아예 won의 도움없이 Money를 숫자기반으로 만들기도 했구요.

왠지는 모르겠으나 4-2강만 음량이 다른 강의 대비 80%수준으로 낮아지는.. 죄송 별걸다..=.=

void반환인데 if안에 쓰이고 있는듯 해요.boolean isRoomExist(int x, int y){ return rooms[x + y * width] != null;}이렇게 되야할 거 같은데..

메서드가 한가지 이유로 변경될 때까지라는 기준이 모호하기도 하고 약간 실무상으로 반대하는 입장이기도 합니다.우선 한가지 이유라면 이미 run도 한가지 이유(실행하기 위해)welcome도 인사말하기 위해이기 때문에 매우 모호합니다. 반대로 showRoom조차도 일종의 템플릿 메소드 파트와 Room이 처리하는 부분으로 나뉜 것으로 되어있죠.그런 면에서 저는 실무에서 메소드 추출을 멈추는 실제적인 기준을 변화율로 두고 있어요. 그 동네가 한꺼번에 변하냐 아니냐로 보는 방식입니다.만약 welcome수준이 한꺼번에 팀장 회의에서 갈려나가는게 일반적이라면 거기서 멈추고 showRoom에서도 room자체의 설명을 보여주는 부분만 자주 바뀌면 다시 추출하는 방식인거 같아요.

지역변수를 필드변수로 승격하는 것에 대한 문제를 생각하게 됩니다.기존에는 running이 지역스코프라 확실하게 문제 범위를 play라고 안심할 수 있었던 것에 비해 필드로 옮겨지면서 왠지//이건 play()에서만 사용됨boolean running;이라고 해야 할 거 같은 느낌이네요.저는 이 경우 스코프 제한을 더 우선 시 하는 편입니다만 이는 이 메소드에서는 괜찮지만 동시성이나 여러가지를 고려하면 더욱 안좋은 습관이지 않냐라는 생각도 듭니다.

1-1에서 미래를 예측할 수 없어 실제로 변경이 발생했을 때 적합한 설계로 개선한다고 했는데 이게 약간 도돌이표 느낌이에요.왜냐면 설계를 선택할 때 변경될 가정을 기반으로 한다고 했기 때문입니다.즉 1. 변경 방식에 따라 설계를 선택2. 변경이 발생하면 설계를 변경아니 이러면 변경에 대응하기 위한 설계가 아니라 변경 시 마다 설계를 바꾼다는 것인데애당초 설계를 왜 한 건가 싶은 생각이 맴도는 느낌이네요.저는 설계를 코드를 변화율에 따라 재배치한다고 생각했는데 변화가 일어날 때마다 설계를 변경할 거면 그건 그냥 설계가 아니라 변경에 따라 코드를 수정한 것 같은..

30개 정도 되는 repo를 하나하나 클론해서 여는게 진짜 너무 불편합니다.폴더 하나에 다 넣어 주시거나 브랜치로 나눠서 제공해주시면 안될까요?

아니면 강의 설명 동영상에프로젝트 초기버전 세팅 등 각종 프로젝트 설정을 자력으로 해야한다. 라는 안내문구라도 존재하면 좋겠습니다. 문제 해결을 할수는 있지만 초기 세팅에 시간이 많이 드는건 사실입니다.