-
Notifications
You must be signed in to change notification settings - Fork 464
[빙봉] 체스 웹/DB 미션 제출합니다. #143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Chess step1 머지
kingbbode
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
요구사항이 충분히 만족되었네요.
바로 머지하도록 하겠습니다 :)
간단한 코멘트 남겼으니 확인 부탁드려요!
고생많으셨습니다.
| pieceDBMapper.put("p", new Pawn(Color.WHITE, "p")); | ||
| pieceDBMapper.put("P", new Pawn(Color.BLACK, "P")); | ||
| pieceDBMapper.put("b", new Bishop(Color.WHITE, "b")); | ||
| pieceDBMapper.put("B", new Bishop(Color.BLACK, "B")); | ||
| pieceDBMapper.put("n", new Knight(Color.WHITE, "n")); | ||
| pieceDBMapper.put("N", new Knight(Color.BLACK, "N")); | ||
| pieceDBMapper.put("k", new King(Color.WHITE, "k")); | ||
| pieceDBMapper.put("K", new King(Color.BLACK, "K")); | ||
| pieceDBMapper.put("q", new Queen(Color.WHITE, "q")); | ||
| pieceDBMapper.put("Q", new Queen(Color.BLACK, "Q")); | ||
| pieceDBMapper.put("r", new Rook(Color.WHITE, "r")); | ||
| pieceDBMapper.put("R", new Rook(Color.BLACK, "R")); | ||
| pieceDBMapper.put("blank", Blank.getInstance()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
데이터 베이스에 저장되는 데이터 구조 선택으로 인해 위와 같은 Mapper 가 생긴 것이군요 :)
열거성 데이터 성격을 선택했다면 Enum을 사용하지 않은 부분이 아쉽네요.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
말씀대로 Enum을 사용하면 더 직관적인 코드가 됐을 것 같습니다. 조언 감사합니다!
| this.pieceViewMapper = new HashMap<>(); | ||
|
|
||
| pieceViewMapper.put("p", "pawn_white.png"); | ||
| pieceViewMapper.put("P", "pawn_black.png"); | ||
| pieceViewMapper.put("b", "bishop_white.png"); | ||
| pieceViewMapper.put("B", "bishop_black.png"); | ||
| pieceViewMapper.put("n", "knight_white.png"); | ||
| pieceViewMapper.put("N", "knight_black.png"); | ||
| pieceViewMapper.put("k", "king_white.png"); | ||
| pieceViewMapper.put("K", "king_black.png"); | ||
| pieceViewMapper.put("q", "queen_white.png"); | ||
| pieceViewMapper.put("Q", "queen_black.png"); | ||
| pieceViewMapper.put("r", "rook_white.png"); | ||
| pieceViewMapper.put("R", "rook_black.png"); | ||
| pieceViewMapper.put("blank", "blank.png"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
서버에서 처리하느냐, 클라이언트에서 처리하느냐는 시스템의 성격에 따라 달라 정답이라고 할만한 것을 말씀드리긴 어렵습니다 :)
ajax 통신을 한다고 가정할 때 클라이언트와 근접한 프론트 시스템에서 반드시 서버에서 처리해야하는 데이터의 예시만 드리자면,
클라이언트의 리소스가 새로고침 되지 않았지만, 새로운 piece 가 등장했을 때 이미지를 클라이언트에서 처리한다면 호환하는 이미지를 찾을 수 없겠지요. 이처럼 데이터의 성격이 클라이언트에 코드에 의존적이지 않게 설정할 때는 반드시 서버에서 데이터를 처리해주어야 합니다. :)
반대 케이스로는 앱 등과 같이 한번 배포되면 변경할 수 없는 클라이언트가 있다면, 응답이 신규버전용과 하위버전용이 나뉘게 되고 이렇게 했을 때 네트워크 레이턴시나 응답 속도를 높이기 위해 서버에서 데이터를 컨트롤을 할 필요는 없겠지요.
상황과 데이터의 성격에 따라 무수히 달라지기에, 서버에서 처리하느냐, 클라이언트에서 처리하느냐는 많은 경우로 나뉘게 됩니다 :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
답변 감사합니다. 예시를 들어주셔서 쉽게 이해할 수 있었습니다 👍
|
싱글턴을 사용하는 기준을 여쭈어보셨는데, 이 또한 매우 많은 상황과 경우가 있습니다 ㅎㅎ 싱글턴을 사용하는 객체는 객체에 대한 생성 비용이 크고, 고정적일 때 싱글턴을 사용하게 됩니다. 예를 들면, 데이터베이스에 대한 커넥션은 비용이 꽤 큰 편입니다. 이러한 커넥션 비용을 매번 생성하지 않고 재활용 하기 위해 싱글턴을 사용할 수 있습니다. 싱글턴을 사용하는 여부에서 멀티 스레드에 대한 고려는 없습니다. 싱글턴이든 매번 생성되는 객체이든, 공유되는 자원이 존재한다면 항상 멀티 스레드에 대한 접근을 고려하여(멀티 스레드 환경이라면) 작성이 되야하기 때문입니다. 스프링 프레임워크의 싱글 오브젝트(bean) 를 궁금해 하실 수도 있기에 추가해봅니다. 싱글 오브젝트는 위와 같은 경우가 접근이 조금 다르게 됩니다. 스프링에서는 객체들의 라이프사이클과 |
안녕하세요!
현재 요구사항은 만족하지만 아직 리펙토링과 CSS, 예외처리가 부족하기에 점진적으로 더 구현하도록 하겠습니다.
그리고 구현하다가 궁금한 점이 몇 가지 생겨 질문드립니다!
질문 1
현재 제 코드는 DB에 전송하기 위해, View에 전달하기 위해, GameManager와 각 Piece들을 이어줄 수 있는 PieceMapper 클래스가 있습니다.
DB에서 데이터를 가져오고나서 GameManager에서 계산을 해줘야하기 때문에 pieceDBMapper가 있으며 View에 각 img 파일 경로를 전달해주기 위해 pieceViewMapper 또한 있습니다.
DB에서 데이터를 가져오는 pieceDBMapper는 무조건 있어야 하지만 이미지 경로는 javascript를 통해 서버가 아닌 클라이언트에서 해줄 수도 있습니다. 서버와 클라이언트 중 어떤 환경에서 Mapping을 해주는 것이 좋은지 궁금합니다. 이외 Mapping 하는 저의 방식에 대해 피드백 주셔도 좋을 것 같습니다 :)
질문 2
현재 저의 체스미션 코드에서 DAO와 Service는 아주 간단한 싱글턴으로 관리되고 있습니다.
싱글턴을 사용하게된 배경은 현재 서비스는 사람이 많이 않아 멀티 스레드 환경이 갖추어지지 않을 거라는 생각이었습니다.
그리고 개인적으로 필드가 없는 클래스라면 멀티 스레드 환경에서도 공유할 필드가 없다고 생각했기에 더더욱 써도 될 거라고 생각했습니다.
저의 이러한 생각이 틀리지는 않았는지, 싱글턴을 사용하냐 마냐의 기준을 '서비스를 많은 사람이 사용하는가?'와 '필드가 있나? 없나?'로 판단해도 괜찮을지 궁금합니다.
읽어주셔서 감사합니다!