[우아한테크코스] 4월 5일 TIL
오늘 배운 것
- 체스 피드백 적용
체스 피드백
-
connection 클래스 분리
connection을 담당하는 새로운 클래스를 새롭게 분리하여 사용하였다.
getConnection, closeConnection에 적용할 수 있었다. -
상수의 관리
enum에서 사용되는 상수들을 분리했는데 같은 패키지 내에서는 공개된다는 단점이 있었다.
가독성이냐 공개되는 것이냐를 생각했을 때 가독성을 고르는게 맞을까? -> 좋은 시도라고 받았다 :) -
stream에서 절대 오지 않는 orElse
findAny, findFirst를 사용하고 get을 하면 intellij에서 없는 경우의 경고를 발생하는데 IllegalArgumentException이 낫다고 추천받았다. -
VO에서 isSameAs와 equals의 혼용
단순히 값만 비교하면 되는 경우에 isSameAs를 사용해서.filter(direction -> direction.columnDirection.isSameAs(normalizeDifference(initialColumnDifference)))와 같이 구현했다. equals를 사용할 시에 다음과 같이 객체로 포장하는 것이 불필요하다고 생각했기 때문이다.filter(direction -> direction.rowDirection.equals(new PositionValue(normalizeDifference(initialRowDifference))))그런데 같은 메서드인 것 아니냐는 질문을 받아 다시 불필요한 객체 생성보다는 불필요한 메서드를 제거하는 것이 더 좋은 방식일까요? 라고 여쭈어보았다. - service와 controller의 역할
service에서 spark에 대한 의존성은 없는 것이 좋다.
request, response 객체에 대한 의존성을 없애도록 하자.- service의 역할
controller는 매개변수를 이용해 service 객체를 호출하는 역할을 하고, service는 누가 자신을 호출했든 통신을 상속받을 필요도 없이 순수 자바로 자신의 비즈니스로직을 처리한다.
service는 controller로부터 받은 변수를 이용해서 값을 조작하기만 하는 레이어라고 생각해서 controller에 render와 같은 작업을 넘겼다.
새로운 게임을 생성해야할때, user가 바뀔때와 같은 때에 현재의 상태를 가지고 있을 필요가 있다보니 이를 controller가 가져야만 했다.
따라서 controller가 chessGame, user 이렇게 세가지 멤버 변수를 가지게 되었는데 올바른 방식일까?
- service의 역할
- service는 무상태
- 컨트롤러 : 클라이언트에서 요청이 들어올 때, 해당 요청을 수행할 비즈니스 로직을 제어하는 객체다. 스프링에서는 컨트롤러에서 세부적으로 서비스 레이어를 만들어 해당 요청사항을 객체 지향적인 방식으로 좀 더 세분화하여 관리한다.
- 서비스 : 서비스 레이어단에서 세분화된 비즈니스로직을 처리하는 객체
DAO(Data Access Object) : DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 객체 - VO(Value Object) : 각 계층간 데이터 교환을 위한 자바 객체를 의미한다. 이 객체는 데이터를 각 레이어 간에 전달하는 목적을 가지고 있으며 객체의 속성과 getter, setter만 가지고 있다. DTO(Data Transfer Object)로 불릴 수도 있다.
- post/put
- put: 요청을 통해 새로운 resouce 생성 혹은 resouce 대체, put은 한 번을 보내도, 여러 번을 보내도 같은 효과를 주는 효과이다. 요청을 보냄으로써 오는 효과가 없다.
- post: html로 서버에 전송해 변경사항을 만드는 경우이다.
- get: 데이터를 가져올 때 사용한다.
location.replace('~~')는 무조건 get - post: 리소스 생성
- get: 리소스 조회, 정보 가져온다
- put: 리소스 수정
