상태를 변경하는 메서드가 일반 멤버와 어드민이 달라야 할까?

[kssumin]

AttendModel 클래스에서는 참석 상태를 변경할 수 있는 메서드를 아래와 같이 2개를 제공하고 있습니다.

	public AttendModel changeStatus(String afterStatus) {
		validateChange(afterStatus);
		this.status = AttendStatus.find(afterStatus);

		return this;
	}

	public AttendModel changeStatusByManager(String beforeStatus, String afterStatus) {
		validateChangeByManager(beforeStatus);
		this.status = AttendStatus.find(afterStatus);

		return this;
	}

각 메서드가 언제 사용되고 있는가?

제가 코드를 이해한 바로는

• changeStatus : 유저가 해당 행사가 수집하고 있는 참석 상태에 따라 자신의 참석 상태를 변경한다.
• changeStatusByManager : 어드민이 유저가 출석체크를 할 수 없을 때 유저에 대해서 참석 상태를 변경한다.

로 이해했습니다.

그럼 두 메서드의 시그니처가 다른 이유가 뭔가?

• changeStatusByManager의 경우에는 changeStatus와 달리 isSameBeforeStatus메서드를 호출하고 있으며 이는 이전의 참석 상태가 같은지를 확인하고 있습니다.

	private void isSameBeforeStatus(String status) {
		if (!AttendStatus.isSame(status, this.status)) {
			return;
		}
		throw new NotSameBeforeAttendStatusException(memberId);
	}

왜 어드민이 참석 상태를 변경할 때는 이전의 상태 정보를 검증해야 하는 건가요?

• 어드민이 해당 유저에 대한 이전 상태 정보를 DB에서 가져왔을 텐데 이를 클라이언트에게 넘겨받은 이전 상태 정보와 비교를 하는 이유가 궁금합니다.
• DB에서 가져온 정보가 이전의 유저 상태일 테니 이를 클라이언트와 비교를 해야하나..? 라는 궁금증입니다.

이전에 제가 참석 상태를 업데이트할 때 이전 상태 정보를 확인한 이유

EEOS 버전1의 경우 어드민과 유저의 개념이 없었고 이때는 회원에 대한 개념 조차가 없었습니다.
그래서 유저1이 유저2,3의 상태를 변경 가능했고
마찬가지로 유저2가 유저 2,3의 상태 변경도 가능했습니다.
따라서 이때는 "동시 수정"의 가능성이 있다고 보았고

유저 2가 유저3의 상태를 브라우저에서 봤을때는 불참이였지만 그 사이에 유저3가 자신의 상태를 참석으로 변경할 수 있었습니다.
당시에 SSE, Socket과 같은 방식을 사용하지 않아 실시간으로 유저의 참석 정보를 보여주지 않았고

위 같은 프로토콜을 사용하는 대신 클라이언트가 지금 보고 있는 유저의 상태를 같이 서버에 넘겨주어 유저가 올바른 참석 정보를 알고 있나?에 대해서 검증하고자 이전 상태값을 전달받았습니다.

[kssumin]

초기 설계에서는 유저1의 요청을 실패시키기 위해 이전 상태값을 확인하는 방식을 채택했습니다. 하지만 다시 생각해보니,

• 결국 두 유저 모두 특정 유저의 참석 상태를 변경하고자 하는 동일한 목적을 가지고 있습니다.
• 유저가 변경 대상의 이전 참석 정보를 정확히 알지 못한다고 해서 문제가 발생할 요인이 없다는 생각이 듭니다.

배달 앱과 같은 상황이라면 이전의 상태값을 비교하는 게 맞을 것 같습니다.

장바구니에 담은 상품의 가격과 실제 주문 시점의 가격이 다른 경우, 이는 사용자의 구매 결정에 직접적인 영향을 미치는 중요한 정보입니다.
이 경우 가격 변동을 사용자에게 알리고, 변경된 가격으로 주문을 계속할지 확인하는 것이 적절합니다.
이는 재무적 영향이 있는 중요한 불일치이므로, 예외를 발생시키고 사용자의 확인을 받는 것이 타당합니다.

참석 정보는 이전 상태가 그다지 중요하지 않을 것 같다.

참석 상태 변경의 경우, 이전 상태와 새로운 상태 사이의 불일치가 배달 앱의 가격 변동만큼 중요하지 않습니다.
사용자의 궁극적인 목적은 단순히 참석 상태를 특정 상태로 변경하는 것이며, 이전 상태는 그다지 중요하지 않습니다.
따라서 이전 상태 확인으로 인해 요청을 거부하는 것은 불필요한 제약일 수 있습니다.

이전 상태 확인 없이 단순히 요청된 상태로 변경을 수행하는 방식을 제안합니다.

[Daae-Kim]

수민님이 이해하신대로, 이전의 상태값을 확인하고 바꾸려는 값과 다르면 상태를 변경하고 아니면 그대로 두기 위해 isSame을 작성했던것 같습니다!
개발을 위해 로직을 생각해보았을때, 바꾸려는 값과 현재의 값이 같다면 바꿀 필요가 없으니까요 ㅎㅎ
그런데 수민님이 제안해주신대로 사용자의 목적은 특정상태로 변경하는것이므로 현재의 값과 바꾸려는 값을 비교하지 않아도 된다는게 납득이 되네요!
isSame 에 제가 모르는 다른 목적이 있는지 벨민님 의견을 여쭤보고, 특별한 이유가 없다면 수민님 제안에 동의합니다 :) 👍🏻

[rlajm1203]

현재 EEOS 3.0 관리자 기능이 추가되고 나서 출석 체크가 진행 중일 때, 시스템 정책 상으로 출석 상태에 관한 동시성 문제를 해결하기 위해서 "출석이 진행 중일 때, 관리자는 수정 페이지에서 유저의 출석 상태를 변경할 수 없다."라고 정책을 설정하였습니다. 하지만 현재는 출석 체크가 진행 중일 때 관리자와 유저 동시에 출석 상태 변경이 가능합니다. (시스템 정책 미구현) 그래서 일단 임시 방편으로 기존에 있던 함수를 재활용 하였습니다. 생각해보니 출석체크가 진행 중인 상태에서는 관리자가 출석 상태를 수정하더라도 출석이 되지 않게끔 구현을 해놓는 게 맞았던 것 같네요..ㅎㅎ 조만간 수정하겠습니다! 수민님 디스커션 통해서 하나 더 배워갑니다!