TIL (2022.01.27)

DAY 7

🔖 오늘 읽은 범위 : 3장, 함수 (~p.65 결론)

😃 책에서 기억하고 싶은 내용을 써보세요.

• 부수 효과를 일으키지 마라!
  • 부수 효과는 거짓말이다. 함수에서 한 가지를 하겠다고 약속하고선 남몰래 다른 것도 하니까.
  • 많은 경우 시간적인 결합(temporal coupling)이나 순서 종속성(order dependency)을 초래한다.
    • checkPassword 함수는 이름 그대로 암호를 확인한다. 이름만 봐서는 세션을 초기화 한다는 사실이 드러나지 않는다. (...) 이런 부수 효과가 시간적인 결합을 초래한다. 즉, checkPassword 함수는 특정 상황에서만 호출이 가능하다.
    • 만약 시간적인 결합이 필요하다면 함수 이름에 분명히 명시한다. (checkPasswordAndInitializeSession)
  • 출력 인수
    • 어느 정도 프로그래밍 경력이 쌓였다면 인수를 출력으로 사용하는 함수에 어색함을 느끼리라.
    • 하지만 객체 지향 언어에서는 출력 인수를 사용할 필요가 거의 없다. 출력 인수로 사용하라고 설계한 변수가 바로 this이기 때문이다.
    • 일반적으로 출력 인수는 피해야 한다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.

      // 1. s를 출력 인수로 사용한 경우(X)
      appendFooter(s); 
      
      // 2. 객체 안에서 변경하는 방식(O)
      report.appendFooter();

• 명령과 조회를 분리하라!
  • 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다.

    // 1. 명령과 조회가 함께 있는 경우 (X)
    if(set("username", "unclebob")) // attribute 속성을 찾아 값을 value로 설정한 후 성공하면 true, 실패하면 false 반환
    
    // 2. 명령과 조회를 분리한 경우 (O)
    if(attributeExists("username")){
    	setAttribute("username", "unclebob");
    }

• 오류 코드보다 예외를 사용하라!
  • 반면 오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해진다.
  • Try/Catch 블록 뽑아내기
    • try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다. 그러므로 try/catch 블록을 별도 함수로 뽑아내는 편이 좋다.
    • 이렇게 정상 동작과 오류 처리 동작을 분리하면 코드를 이해하고 수정하기 쉬워진다.
  • 오류 처리도 한 가지 작업이다.
  • Error.java 의존성 자석
    • 위와 같은 클래스는 의존성 자석(magnet)이다. 다른 클래스에서 Error enum을 import해 사용해야 하므로, 즉 Error enum이 변한다면 Error enum을 사용하는 클래스 전부를 다시 컴파일하고 다시 배치해야 한다.
    • 오류 코드 대신 예외를 사용하면 새 예외는 Exception 클래스에서 파생된다. 따라서 재컴파일/재배치 없이도 새 예외 클래스를 추가할 수 있다. → OCP(Open Closed Priciple)
• 반복하지 마라! (→ DRY(Don’t Repeat Yourself) 원칙)
  • 그래도 중복은 문제다. (네 번의 중복이 있을 경우) 코드 길이가 늘어날 뿐 아니라 알고리즘이 변하면 네 곳이나 손봐야 하니까. 게다가 어느 한곳이라도 빠뜨리는 바람에 오류가 발생할 확률도 네 배나 높다.
• 구조적 프로그래밍
  • 구조적 프로그래밍의 목표와 규율은 공감하지만 함수가 작다면 위 규칙은 별 이익을 제공하지 못한다.
  • 그러므로 함수를 작게 만든다면 간혹 return, break, continue를 여러 차례 사용해도 괜찮다. (...)반면 goto문은 큰 함수에서만 의미가 있으므로, 작은 함수에서는 피해야만 한다.
• 함수를 어떻게 짜죠?
  • 처음부터 탁 짜내지 않는다. 그게 가능한 사람은 없으리라
• 결론
  • 모든 시스템은 특정 응용 분야 시스템을 기술할 목적으로 프로그래머가 설계한 도메인 특화 언어(Domain Specific Language, DSL)로 만들어진다. 함수는 그 언어에서 동사며, 클래스는 명사다.
  • 대가(master) 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다. 시스템에서 발생하는 모든 동작을 설명하는 함수 계층이 바로 그 언어에 속한다.
  • 하지만 진짜 목표는 시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심하기 바란다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 오늘 읽은 부분에서 가장 인상 깊었던 부분은 “예외”와 관련된 부분이었다.
  “예외”야 말로 좀 더 표현력이 강한 언어를 만들기 위한 노력의 결과물이라고 생각한다. 예외는 직접 코드를 짜서 처리하도록 해 버릇해서 그런지, 그동안 나는 예외 클래스를 잘 활용해 본 적이 없는 것 같다. 그래서 예외 클래스 없이 수많은 분기문으로 처리하는 경우의 복잡성을 이해한다. 어느 부분이 어떤 에러를 처리하는 지 명확하게 표현하기도 어렵고, 여기 저기 분산 되어 있어 한 곳에 모으는 것도 쉽지 않다. 오늘 이후로 “예외”와 좀 더 친숙해져 훨씬 아름다워질 내 코드들이 기대된다!

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 프로그래밍 방식의 변화
  • 절차적 프로그래밍 → 구조적 프로그래밍 → 객체 지향 프로그래밍
• 구조적 프로그래밍
  • 절차적 프로그래밍 방식의 개선된 형태
  • 프로그램을 함수단위로 나누고 함수끼리 호출하는 방식
  • 큰 문제를 해결하기 위해 문제를 작은 단위들로 나누어 해결하는 방식 (Top-Down)
• 객체 지향 프로그래밍
  • 구조적 프로그래밍 방식의 개선된 형태
  • 큰 문제를 작게 쪼개는 것이 아니라, 작은 문제들을 해결하는 객체를 만든다.
  • 객체들을 조합해 큰 문제를 해결하는 Bottom-Up 방식
  • 참고 링크: OOP의 5원칙과 4가지 특성

소감 3줄 요약

• 프로그래밍 언어에서 함수는 동사이며, 클래스는 명사이다.
• 함수는 시스템에서 발생하는 모든 동작을 숨김없이 표현한다.
• 한번에 좋은 함수를 만들 수 있는 사람은 없다.