2022년 8월 11일 TIL

 

주간 과제 마카오 레터 과제의 중간에 추가된 요구사항 중 선택한 페이지 번호에 따라 어떤 게시글들을 리스트업해서 보여줄지 결정하는 구조를 작성한 과정을 정리해보고자 한다.

 

해당 과정은 일단 PageGenerator 구현체에서 직접 구현을 시도했으며, Repository의 저장된 게시글들이 담긴 컬렉션 전체가 들어오고, 게시글의 개수에 따라 페이지 번호는 적절히 출력된다고 가정한다.

 

 

1. 요구사항에서 규칙을 찾아 규칙화

1. 각 페이지마다 게시글이 최대 5개가 보여져야 한다는 점을 파악했다.

 

2. 각 페이지가 컬렉션에서 최대 어느 인덱스 범위만큼을 보여야 할지 생각해보았다. 페이지 1은 인덱스 0~4, 페이지 2는 5~9, 페이지 3은 10~14, 페이지 4는 15~19, ... 이런 식으로 인덱스 범위가 정해져야 할 것이라고 생각했다.

 

3. 찾은 인덱스 범위의 묶음에서 반복적인 규칙이 있는지 살펴봤다. 자세히 살펴보니 다음과 같은 규칙이 보였다.

 

1페이지: 0부터 4까지	2페이지: 5부터 9까지	3페이지: 10부터 14까지	... n페이지
0 = 5 - 5,    4 = 5 - 1	5 = 10 - 5,    9 = 10 - 1	10 = 15 - 5,   14 = 15 - 1	(5 * n) - 5  ~  (5 * n) - 1

 

 

즉 n이라는 페이지 번호가 주어질 때, 게시글들 중 (5 * n) - 5부터 (5 * n) - 1 인덱스에 해당하는 게시글들이 주어져야 함을 파악했다. 이를 토대로 컬렉션에서 해당 인덱스에 해당하는 게시글들을 어떻게 가져올지를 고민했다.

 

 

2. 규칙을 가장 잘 맞게 보여줄 수 있는 메서드 찾기

1. 컬렉션의 각 글을 리스트로 변환해 보여주는 것은 PageGenerator 구현체에서 내부적으로 정의해뒀던 메서드에서 이뤄지고 있었다. 메서드에서는 List를 stream으로 전달하는 방식을 사용하도록 했는데, stream의 map을 이용해 각 게시글 객체를 <li> 마크업 형태로 변환하기 전에 먼저 위에서 설정한 인덱스만큼의 stream만을 전달해줄 수 있는 방법이 있을지 stream API의 메서드를 찾아보았다. 안타깝게도 특정 인덱스로 stream의 내부 요소를 걸러낼 수 있는 방법은 찾아지지 않아 관두었다.

 

2. 이번에는 List에서 인덱스의 범위만큼을 잘라내어 새로운 인덱스로 가져올 수 있을지 찾아보았다. 찾아본 결과 List의 메서드인 subList(startIndex, endIndex)가 있었다. subList는 인자로 시작 인덱스, 끝 인덱스가 주어지는데, 시작 인덱스는 포함하지만 끝 인덱스는 포함하지 않는 (즉 끝 인덱스 바로 앞 인덱스까지를 포함하는) 특징이 있었다. subList를 이용해 위에서 정한 인덱스만큼을 별도의 리스트로 떼내어 <li> 마크업으로 변환하도록 전달하도록 했다.

 

 

3. 중간에 놓쳤던 부분

생각해보니 게시글의 인덱스에서 (5 * n) - 1 인덱스까지 무조건 다 가져오게 할 경우 오류를 범하는 케이스가 있었다.

 

예를 들어 게시글이 7개가 있다고 하면 페이지 번호는 2까지 있을 것인데, (5 * 2) - 1 = 9이므로 컬렉션의 범위를 초과하는 문제가 발생했다. 이럴 때에는 범위를 다르게 선정해줄 필요가 있어 고민했다. 고민한 결과 컬렉션의 크기만큼까지를 범위로 주는 것을 생각해보았는데, 언제 (5 * n) - 1을 주고, 언제 컬렉션의 크기만큼까지를 뒷범위로 줄 것인지를 결정해야 했다.

 

결정 방식으로 (5 * n) - 1과 컬렉션의 크기 값 중 작은 값을 선택해서 주게 하는 것을 시도해보았다. (5 * n) - 1은 가장 마지막 페이지 번호가 주어지지 않는 이상은 항상 컬렉션의 크기 값보다는 작을 것이고, 마지막 페이지 번호일 때만 컬렉션의 크기 값이 (5 * n) - 1보다 작을 것이기 때문이었다. 적용시켜본 결과 그제서야 조건에 맞게 잘 적용하는 것을 확인할 수 있었다.

 

 

4. 그래서 중요한 것은?

이런 과정들을 머릿속으로 완전히 구조를 짜서 코드로 옮겨야지 생각했을 때에는 '이렇게 되면 이렇게도 되야 할 것 같은데? 저렇게도 되야 할 것 같은데? 복잡해!' 하면서 정리가 되지 않았다. 머리에서 막 떠오르는 이런 저런 방법들을 글로 옮겨서 눈에 보이는 구조로 정리도 해 보고, 혼잣말로 막 설명하면서라도 구조를 짜 맞춰본 결과 내용이 정리됨을 느낄 수 있었다.

 

생각컨대 강의의 전개 방식 또한 사례를 직접 하나 둘 부딪혀가며 만들어가고, 공통되는 부분이 확인이 될 때마다 중복 제거와 추상화를 진행해주는 식이다. 귀납법이라고도 하는 하나하나의 구체적인 사례들을 모아 규칙을 만들어가는 과정, 앞으로 마주칠 많은 문제들을 풀어나가기 위해 문제들에 많이 부딪혀보면서 부딪힌 사례들의 규칙을 나름대로 정립해볼 수 있어야 할 것이다.