[WEAV-329] 이전 채팅메시지 조회 API 구현 #239
Conversation
waterfogSW
commented
Apr 13, 2024
waterfogSW
commented
- 설계 문서
|
|
||
| fun getScrollList(query: ScrollListQuery): ScrollListResult | ||
|
|
||
| data class ScrollListQuery( |
There was a problem hiding this comment.
p3) 이거 상속 말고 그냥 제너릭만 써서 하면 좀 그럴까요?
딱히 여기서 문제는 아님
There was a problem hiding this comment.
상속말고 제너릭만 사용하면 어떤 방식으로 코드가 작성되나요?
There was a problem hiding this comment.
이런 느낌으로 제너릭만 설정해주면 해당 값만 잘 맞춰서 넣어줄 수 있도록?
| data class ScrollListQuery( | |
| interface GetChatMessage { | |
| fun getScrollList(query: ScrollRequest<UUID>): ScrollResponse<ChatMessage, UUID?> | |
| } |
There was a problem hiding this comment.
음 그렇게 하면 roomId같은 속성은 추가로 파라미터 더 만들어줘야하는데 그게 더 낫다고 생각하시나요?
There was a problem hiding this comment.
잘 이해를 못 했어요! UUID가 chatRoomId 아니에요? 어차피 들어오는 cursor 역할 하는 친구의 타입만 바뀌는 거 같아서요!
There was a problem hiding this comment.
제가 제안하고 싶은 건 지금은 거의 사실 Scroll관련 요청에서 next조건이 되는 타입 필드만 정의해서 쓰는 정도라 굳이 상속 안하고 제너릭으로 하고 클래스에 잘 미리 정의해서 재활용하는게 낫지 않나에요!
There was a problem hiding this comment.
밑에 ScrollListResult도 그냥 ScrollResponse<CHatMessage, UUID?> 를 그대로 써도 될 것 같아서요!
There was a problem hiding this comment.
어 근데 다른 ScrollResponse, ScrollRequest 활용케이스들은 모두 상속해서 정의하고 있는데, 이부분에 대해서만 예외적으로 적용하는게 일관성이 좀 깨질것같은데, 어떻게 생각하시나요?
There was a problem hiding this comment.
네네 맞아요 그래서 괜찮으면 한번에 리팩토링 할까 생각했어요!
There was a problem hiding this comment.
아하 요거는 나중에 조금더 논의하면 좋을거같아요
...on/src/main/kotlin/com/studentcenter/weave/application/chat/service/GetChatMessageService.kt
Show resolved
Hide resolved
waterfogSW
force-pushed
the
feat/WEAV-329
branch
from
35298a2 to
f7599b6
Compare
|
