ios 15일차

회고

오늘은 개인공부를 할 시간은 많지 않았다. 일정에 따라, 문법 Recap, 과제를 다시 수정하여 제출하는 시간을 가졌으며 해설 영상을 통해 크게 수정해야할 부분은 찾지 못했다. 때문에, 과제 재제출 시 요구조건으로 주어진 문항들 중 설명이 필요한 부분들을 작성하고자 한다.

과제 재제출

제출한 과제의 디렉토리는 아래와 같다.

구성

• Game : 시작 메뉴(게임 실행, 기록 관리, 종료)
• GameInput : 입력을 받고 오류 검증 및 출력
  - 입력에 관한 검사
• GameRule : 구현한 야구 게임의 규칙
  - 정답 생성, 저장
  - 스트라이크, 볼 결과 판정
• main : 실제 게임을 동작하기 위한 코드

아래는 요구사항을 읽고 필요설명에 대해 작성한 부분들이다.

[1.4] 검증 규칙이 변경될 때(예: 자리수 4자리로 확장), 수정 범위가 예상 가능하다

• 검증 규칙이 변경될 경우, 검증 규칙에 관한 로직이 구현되어있는 GameRule.swift의 randomAnswer || randomAnswer2의 함수 중 선택하여 수정이 가능하다. 만약, 문제의 기준사항처럼 만약 자리수를 확장하게 될 경우 2가지의 조건을 통해 구현할 수 있는데, 방법1로는 randomAnswer 함수와 randomAnswer2 함수 선언시 사용한 while 구문을 수정하면 된다. 또한, 현재의 코드에 적용되어 있지 않은 방법으로 shuffle을 통해 조건에 맞는 배열을 선언한 뒤 0~3까지의 인덱스를 잘라서 규칙을 생성하는 방법으로도 구현이 가능하다. 물론, 규칙의 변경에 따라 사용자의 입력을 확인받는 코드 또한 3자리가 아니라 4자리로 변경해야 한다.

[2.6] 아래 상황이 오면, 내 코드에서 “어디를 바꿔야 하는지” 바로 말할 수 있나요?

• 숫자 자리수를 3 → 4로 바꾼다 : [1.4] 해설을 참고할 수 있을 것 같다.
• 중복 허용 규칙이 생긴다/사라진다 : 현재는 중복 허용 규칙을 통해 만들어 둔 것이다. 중복을 검증하는 로직으로 2가지 방법을 사용했는데, randomAnswer에서는 저장되는 값을 Set으로 검증하여 count를 추가하기에 중복이 불가능하도록 구현되어있다. 이를 Set을 통해 검증하는 로직을 배제한다면 중복 구현도 가능할 것이다. 또한, randomAnswer2에서는 result에 contain되어있는지 확인 후 숫자를 넣도록 구현해두었다. 이로 인해 중복이 불가능하며, 위 사항을 제거한다면 중복 허용 기능을 추가할 수 있다.
• “Nothing” 대신 “0S 0B”로 출력 포맷이 바뀐다 : Game.swift의 hint 함수를 수정하여 else if를 사용할 필요가 없어질 것 같다. 현재 구현되어 있는 방식은 조건을 strike가 3일 경우를 제외하고 나머지의 경우를 총 4번의 조건을 확인하여 출력을 하는데, Nothing을 출력할 필요없이 0S 0B로 출력할 것이라면, 정답을 맞히는 상황을 제외하면 모든 상황에 nS mB로 출력하도록 구현하는게 낫지 않을까 생각한다. (ex. 2스트라이크 1볼일 경우 : 2S 1B로 형식을 맞춰서 출력)
• 난이도 선택(자리수/허용 범위)을 메뉴에서 받는다 : 허용 범위에 관해서는 생각해본 적이 없다. 정확히 어떤 기능을 예시로 드는 것인지 잘 모르겠다. 다만 자리수를 입력받아서 확인해보는 시스템은 생각해 본 적이 있다. 사용자에게 입력받는 것과 마찬가지로 숫자 자리수를 입력받아서 GameRule.swift의 정답 생성용 함수를 수정한다. 현재는 count가 3보다 작은 경우로 하드코딩되어 있지만, 이 부분을 사용자에게 입력받은 n을 이용하도록 구현한다면 자리수에 관한 기능 수정도 가능할 것이다.

[2.7] 고차함수(map/filter/reduce)를 “가독성 향상” 목적으로 자연스럽게 사용했거나, 사용하지 않았다면 그 이유를 설명할 수 있다

• 기본적으로 이번 과제에서는 고차함수만을 사용해서 구현하도록 노력하지는 않았다. 다만, 사용하지 않은 경우 코드의 길이가 길어지는 경우와 구현하던 당시의 상황에 본인의 실력을 테스트해보고자 했던 경우에는 무리해서 사용한 감도 없지 않아 있다. 예를 들어, 사용자의 입력을 검증하는 구문을 구현할 때 guard let 구문에 한번에 입력값에 관한 조건을 넣어보고자 했다. 무리해서 사용하였기에 다른 방도를 찾지 못하고 결국 Optional로 처리하여 묶어주는 방법밖에 생각하지 못했으나, 튜터님의 피드백을 통해 map과 compactMap을 통해 구문을 보다 깔끔하게 처리하는 방법을 알게 되었다.

[2.9] 에러 처리를 do-catch + 커스텀 에러로 정리했거나, 사용하지 않았다면 “이 과제에선 과했다/단순 Bool이 더 적절했다” 등 판단 근거가 있다

• 에러 처리와 프로그램 실행 시 나타나는 게임 선택화면 구현 시, 열거형으로 케이스를 구분하여 작성하는 방법도 생각해보았지만, 본인은 현재 프로젝트에서 달리 해야할 이유를 찾지 못했다. 단순하게, 요구사항을 충족하고자 했던 생각도 있지만, 선택할 수 있는 케이스가 많지 않았으며 관리에 요구되는 조건들도 없었기에 열거형보다 기본적인 switch문을 통해 이용하고자 했으며 사용자의 입력값에 관한 에러 처리에 대해서도 조건에 걸릴 경우로 처리하는 게 편하고 나을 것이라 판단했다.