DAY 4 ~ 5

🔖 오늘 읽은 범위 : 📚 3장. 함수

<aside> 😃 기억하고 싶은 내용 (복붙해도 상관없어!)

</aside>

함수 작성하기

읽고 이해하기 쉽게

• 작게 만들어라!
  • if / else / while 문 등에 들어가는 블록은 한줄 이어야 한다.
  • 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.
• 한 가지만 해라!
  • 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.
  • TO 문단으로 기술하기 ⇒ 추상화 수준을 하나로!
  • 한 가지 작업만 하는 함수는 자연스럽게 섹션으로 나누기 어렵다.
• 함수 당 추상화 수준은 하나로!
  • 함수 내 모든 문장의 추상화 수준이 동일해야 한다.
  • 내려가기 규칙: 위에서 아래로 코드 읽기 ⇒ 이야기처럼 읽혀야 좋다.
    • 짧으면서도 ‘한 가지’만 하는 함수 = 추상화 수준을 일관되게 유지하기 쉬워진다.
  • Switch 문
    • 함수가 길다.
    • 한 가지 작업만 수행하지 않는다.
    • SRP 위반 ⇒ 코드 변경의 이유가 많다.
    • OCP 위반 ⇒ 새로운 case 가 생길 때 마다 추가 되어야 한다.
    • 구조가 동일한 함수가 무한정 존재한다.
    • 해결책
      • switch 문 → 추상 팩토리 Abstract Factory 에 숨긴다.
      • 팩토리 내부에서 switch 문을 사용해 적절한 파생 클래스의 인스턴스를 생성하게 한다.
      • 함수는 인터페이스를 거쳐 호출되게 한다. ⇒ 다형성으로 인해 실제 파생 클래스의 함수가 실행되게 한다.
• 서술적인 이름을 사용하라!
  • 한 가지만 하는 작은 함수에 좋은 이름을 붙인다.
  • 함수가 작고 단순할수록 서술적인 이름을 고르기도 쉬워진다.
  • 길고 서술적인 이름이 제일 좋다.
  • 함수 기능을 잘 표현하는 이름.
  • 서술적인 이름을 사용하면 → 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다.
  • 이름은 일관성이 있어야 한다. ⇒ 짐작하는 대로 예상하기 쉽다.
    • 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.
• 함수 인수
  • 이상적인 인수 개수는 0개!!
  • 인수는 개념을 이해하기 어렵게 만든다.
  • 단항 형식
    • 인수에 질문을 던지는 경우 or 인수를 변환해 결과를 반환하는 경우.
    • 아주 유용한 단항 함수 형식 = ‘이벤트’ 함수.
    • 입력 인수를 변환하는 함수라면,
      • 변환 결과를 반환 값으로 돌려준다.
    • 입력 인수를 그대로 돌려주는 함수라도 변환 함수 형식을 따르는 편이 좋다.
  • 플래그 인수 ⇒ 최악!
  • 이항 함수
    • 인수가 2개인 함수
      • 2개가 한 값을 표현하는 두 요소는 자연적인 순서도 있기 때문에 적절하다.
      • 일반적으로 인수 순서를 인위적으로 기억해야 하는 단점이 존재한다.
    • 더 나은 함수로 바꿀 방법
      • 클래스 구성원 변수로 만들어 인수를 넘기지 않는다.
      • 새 클래스를 만들어 구성자에서 인수를 받아서 메서드를 구현한다.
  • 삼항 함수
    • 인수 3개인 함수 = 이해하기 어렵다.
      • 순서, 주춤, 무시 문제!
  • 인수 객체 활용하기
    • 독자적인 클래스 변수로 선언하자.
    • 변수를 묶어서 이름을 붙임으로써 개념을 표현한다.
  • 인수 목록이 있는 함수 ⇒ 사실상 이항 함수.
    • 인수 개수가 가변적인 함수가 필요할 때.
    • 가변 인수는 리스트형 인수 하나로 취급 가능.
    • 역시나 일정 수준을 넘어서는 경우 문제가 있음.
  • 동사와 키워드
    • 단항 함수: 함수와 인수가 동사/명사 쌍으로 이뤄야 한다.
    • 함수 이름에 키워드를 추가하는 형식: 인수 순서를 기억할 필요가 없다는 장점.
• 부수 효과를 일으키지 마라!
  • 시간적인 결합
    • 특정 상황에서만 호출 가능한 내용이 함수에 포함된 경우.
    • 필요한 경우, 함수 이름에 분명히 명시한다.
  • 순서 종속성
  • 출력 인수
    • 인수 = 함수 입력
    • 인수를 출력으로 사용하지 말자.
    • 객체 지향 언어에서 출력 인수 사용 설계
      • this 활용.
      • appendFooter(s) → report.appendFooter()
• 명령과 조회를 분리하라!
  • 함수가 하는 일 = 객체 상태를 변경하거나, 객체 정보를 반환하거나. ⇒ 함수는 한 가지 일을 해야 한다는 점.
  • 명령 함수와 조회 함수로 분리하자.
• 오류 코드보다 예외를 사용하라!
  • 오류 코드는 명령/조회 규칙을 미묘하게 위반한다.
  • 오류 코드는 반환하면 호출자가 오류 코드를 곧바로 처리해야 한다.
  • 예외를 사용하자.
    • 오류 처리 코드가 분리된다.
  • Try/Catch 블록 뽑아내기.
    • 별도 함수로 뽑아내는 편이 좋다.
    • 정상 동작과 오류 처리 동작의 분리.
  • 오류 처리도 한 가지 작업이다.
    • 오류 처리 함수는 오류 처리만 해야 한다.
  • 의존성 자석
    • 오류 코드를 정의한 클래스 or Enum or 기타 상수 등등.
    • 정의된 오류 코드가 변경되면 연관된 모든 부분이 변경되어야 하고 컴파일 및 재배치가 발생한다.
    • 예외 사용으로 새로운 예외 클래스 추가와 대응하는 것 외에 다른 변경점이 없다. ⇒ OCP
• 반복하지 마라! DRY Don’t Repeat Yourself
  • 중복은 문제다. 중복은 제거한다.
• 구조적 프로그래밍
  • 함수에 대한 구조적 설계
    • return 문은 하나 뿐이다.
  • 함수를 작게 만들면, 보다 유연한 구조적 프로그래밍 가능.
    • 의도를 표현하기 쉬워진다.
• 함수 잘 만드는 방법
  • 처음에는 그냥 코드를 작성한다. 그리고 빠짐없이 테스트 하는 단위 테스트 케이스도 만든다.
  • 코드를 개선한다.
    • 코드를 다듬고
    • 함수 만들고
    • 이름 바꾸고
    • 중복 제거하고
    • 메서드 줄이고
    • 순서 바꾸고
    • 클래스 쪼개기
  • 항상 단위 테스트를 통과한다.

결론

• 도메인 특화 언어 DSL
• 함수는 동사. 클래스는 명사.