Assignment1

설계

핵심 개체 3가지: 블로그, 글, 댓글

유저 스토리를 바탕으로 설계

블로그

역할
- 복수의 글들에 대한 참조를 가지는 컨테이너
  - 광의의 컴포지션
- 글들을 관리하고 필터링, 정렬 등의 비즈니스 로직을 캡슐화햐여 사용자에게 제공
상태
- 필터, 정렬 방법
  - 캡슐화(블로그에 필요한 데이터는 블로그의 상태로 저장)

글

역할
- 글과 관련된 정보 관리
  - 캡슐화
- 블로그 개체에서 필요한 정보를 노출
  - 필터링, 정렬에 필요한 정보
상태
- 글과 관련된 정보
  - 제목
  - 본문
  - 작가 id
  - 태그
  - 생성, 수정시간
  - 댓글
  - 리엑션
리엑션 구현 세부 사항
- 유저는 리엑션 중 하나만 선택할 수 있음
- 어떤 유저가 리엑션을 하면 그 리엑션의 숫자는 증가하고, 반대로 리엑션을 취소하거나 다른 리엑션으로 수정하면 감소
글에 대한 접근 제한
- 접근 제어자로 해결할 수 없는 문제
- 상태에 작가 id를 기록해, 글을 수정할 때 매서드의 인자로 유저 id를 받아 권한을 검사하도록 구현
- 제목, 본문, 태그는 작가 권한이 필요
- 글이 수정되면 수정 시간을 갱신
글을 생성할 때 수정시간은 생성시간과 동일한 값(상태)를 가지도록 구현
- 동일한 OffsetDataTime 개체를 참조해야함

역할
- 댓글과 관련된 정보 관리
  - 캡슐화
- 글, 상위 댓글에 필요한 정보를 노출
  - 정렬에 필요한 정보
    - 추천 수 - 비추천 수
상태
- 댓글과 관련된 정보
  - 댓쓴이 id
  - 추천자 id 목록
  - 비추천자 id 목록
  - 하위 댓글(답글) 목록
댓글에 대한 접근 제한
- 접근 제어자로 해결할 수 없느 ㄴ문제
- 상태에 댓쓴이 id를 기록해, 댓글을 수정할 때 매서드의 인자로 유저 id를 받아 권한을 검사하도록 구현
- 본문은 댓쓴이 권한이 필요
추천/비추천
- 중복 추천을 방지 하기 위해 유저의 집합(set)으로 구현
- 동일한 유저가 추천한 상태에서 비추천으로 변경되면 추천 집합에서 유저를 제거하고, 비추천 집합에 추가하도록 구현

유저

식별자를 어떻게 지정할 것인가?

수강생분들이 택한 여러 가지 유저 설계를 보고 유용하겠다 싶어 이 글을 씁니다.

유저 설계에서 가장 중요한 것은 각 사용자를 식별하는 고유한(unique) 값이 있어야 한다는 겁니다. (고유 식별자)

서로 다른 유저의 고유 식별자가 동일하면 안 됩니다.
같은 유저인데 실행할 때마다 식별자가 바뀌면 안 됩니다.
고유 식별자로 사용할 수 있는 데이터와 데이터형은 몇 가지 됩니다.

블로그에서 유저를 생성하려면 어떤 정보가 필요한가요?

어떤 정보를 사용하든 간에 최소 그중 하나는 고유 식별자여야 합니다.
시스템에 따라 고유 식별자 그 자체가 유저가 될 수도 있습니다.

유저를 클래스로 만든다면 다음의 것들도 고려해보세요.

코드에서 유저의 고유 식별자를 생성하는 위치가 어디어야 할까요?
어떤 메서드에 유저 정보를 전달할 때 어떤 형태로 전달하는 게 “올바른” OOP일까요?

결론: 고유 식별자로 email을 사용하자!

Archiving

블로그 유저 권한

[타사 제품 리서치] 블로그 주인이 아닌 사용자(유저)가 블로그 글을 게재할 수 있는가? 이것도 수강생분들의 여러 가지 설계/구현 방법을 검토하다가 알려드리면 좋을 것 같은 내용이 있어서 공유합니다. 일단 이런 질문에 대한 답을 찾는 가장 좋은 방법은 타제품을 베끼는 리서치하는 겁니다. :손으로_입을_가린_얼굴:

아마 흔히들 사용하시는 네*버 블로그는 주인 외에 다른 사람이 글을 게재할 수 없을 겁니다.
티스토리에는 여러 명의 유저가 글을 쓸 수 있는 팀블로그란 기능이 있습니다.
역시 구글 블로거에도 팀블로그란 기능이 있습니다.
회사 자체에서 운영하는 블로그도 보통 여러 명의 직원들이 글을 올립니다. (예: 마이크로소프트 사의 블로그) 따라서 충분히 블로그 주인이 아닌 유저가 블로그 글을 게재할 수 있습니다. 실무에서 팀블로그를 구성할 때는 특정 유저들을 초대해서 작성자 권한을 줍니다. 그리고 누군가 글을 쓰려고 할 때마다 그 사람이 권한이 있는지 확인하겠죠. 하지만 이 과제에서는 권한을 체크하는 코드까지 요구하지는 않습니다.

필터링

이미 아시겠지만 빌드봇은 여러 가지 블로그 글 목록 필터링 방법을 허용합니다. (설계 중심의 과목이기 때문에 딱 한 가지 방법을 강요하지는 않음) 빌드봇이 허용하는 방법들은 모두 실무에서 충분히 볼 수 있는 방법들이지만 그중에서도 그다지 훌륭하지 않은 설계들도 있습니다. 다음의 것들을 고민해보면 더 훌륭한 설계를 찾을 수 있지 않을까요?

복수의 태그 필터를 적용할 때, 어떻게 적용하는 것이 더 자연스러울까?
- addTag() 메서드를 통해 한 개씩 추가
- setTags() 메서드를 통해 모든 태그를 한 번에 설정
다른 프로그래머가 filter setter 메서드 시그내처를 보고 단번에 ‘아, unset도 가능하겠구나’라고 알 수 있을까? 고민해보시면 더 나은 방법이 보일 겁니다.

본인의 구현에서는 블로그에서 필터링을 담당
- 복수의 태그 필터를 적용할 때, Vaargs 사용

public void setTagFilter(String... tags) {
    this.tagFilter.clear();
    this.tagFilter.addAll(List.of(tags));
}

하위 댓글 구조

[아마도 마지막 힌트] 댓글(Comment)과 하위 댓글(Subcomment) 댓글 및 하위 댓글 설계를 시도하다가 아직 깨달음의 순간(Eureka moment :목욕:)을 못 겪으신 분들을 위한 두 가지 팁입니다. 둘 다 일반화(따라서 재사용성)와 관련이 있습니다. I. 누가 누구를 참조해야 하는가? ‘상위 댓글 vs 하위 댓글’ 개념에서 더 나아가서 ‘대대댓글’, ‘대대대댓글’을 지원하려면 누가 누구를 참조해야 할까요? (A가 B를 참조한단 의미는 A 개체 내부에 B 개체를 저장한다는 말)

상위 댓글이 하위 댓글을 참조 (상위 ⇒ 하위)
하위 댓글이 상위 댓글을 참조 (하위 ⇒ 상위)
서로서로 사이좋게 참조 (상위 ←> 하위) 이 중에 한 가지 방법은 정말 불필요하고 나쁩니다. :작은_도깨비: 나머지 둘은 모두 나쁘지 않은 방법인데, 그중 특히 한 가지 방법을 택하면 재사용성을 확실히 높일 수 있습니다. :결백: II. 댓글 설계의 일반화 정도 이건 아마 거의 정답을 알려드릴 것 같네요. :윙크하며_혀를_내민_표정: 과제 1의 사용자 스토리를 보면 댓글과 하위 댓글을 구분해서 설명하고 있습니다. 이것을 그대로 설계로 옮기면 다음과 같을 겁니다.
‘나는 Post 클래스. 나에게 달리는 댓글은 Comment 클래스’
‘나는 Comment 클래스. 나에게 달리는 댓글은 Subcomment 클래스’ 처음에는 이 설계가 괜찮아 보이지만 다음과 같은 여러 의문들이 남습니다.
‘그럼 Subcomment 클래스에 달리는 댓글은 Subsubcomment 클래스로 만들어야 하나?’
(위의 I. 누가 누구를 참조해야 하는가? 에서 올바른 결정을 내렸다면) ‘Post 클래스에 달리는 댓글이든 Comment에 달리는 댓글이든 그 클래스 속에 들어가는 데이터가 달라지나?’ 이 정도면 충분히 팁을 드린 것 같죠?

과제 3과 똑같은 문제

Questions and Discoveries

A specification in the form of user stories

A user story is a software feature written from the perspective of the end user.

Reference: https://www.atlassian.com/agile/project-management/user-stories

POCU 노트

탐색기

2409solution