TIL (Today I Learned)

2022.02.23

오늘 읽은 범위

3장. 함수

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

• 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. (p42)

• 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. (p44)

• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. (p49)

• 최선은 입력 인수가 없는 경우이며, 차선은 입력 인수가 1개뿐인 경우다. (p51)

• 함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지다.

  하나는 인수에 질문을 던지는 경우다. boolean fileExists("MyFile")이 좋은 예다.

  다른 하나는 인수를 뭔가로 변환해 결과를 반환하는 경우다. InputStream fileOpen("MyFile")은 String 형의 파일 이름을 InputStream으로 변환한다. (p51)

• 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다.

  왜냐고? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! (p52)

• 이항 함수가 무조건 나쁘다는 소리는 아니다.

  하지만 그만큼 위험이 따른다는 사실을 이해하고 가능하면 단항 함수로 바꾸도록 애써야 한다.

  예를 들어, writeField 메서드를 outputStream 클래스 구성원으로 만들어 outputStream.writeField(name)으로 호출한다. (p52)

• 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어본다. (p53)

• 부수 효과는 거짓말이다. 함수에서 한 가지를 하겠다고 약속하고선 남몰래 다른짓도 하니까.

  때로는 예상치 못하게 클래스 변수를 수정한다.

  때로는 함수로 넘어온 인수나 시스템 전역 변수를 수정한다.

  많은 경우 시간적인 결합이나 순서 종속성을 초래한다. (p55)

• 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다.

  객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다.

  둘 다 하면 혼란을 초래한다. (p56)

• 오류 코드보다 예외를 사용하라! (p57)

• 오류 처리도 한 가지 작업이다. (p59)

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

• 플래그 인수는 추하다. 추하다. 추하다..... 이번 장에서 가장 머리가 띵 해지는 문장이었다.

  플래그 값에 따라 show/hidden 혹은 enable/disable 하는 함수들을 많이 작성했었다.

  하긴 나도 작성하면서 함수명은 enableXXX로 만들어 놓고 false를 받으면 disable 시키고 있으니 내심 꺼림직했던 것도 사실이다. 코드 중복을 줄여서 실용적인게 아니라 추했던 것이었다.

• 인수가 없는 함수는 중요한 함수가 아니라고 생각했었다. 어쩌다 불가피하게 필요해서 만들어진 함수라고 생각했었다. 인수를 줄여가는 노력을 해야겠다.

• 입력 인수로 String값을 두 개 받는 함수때문에 에러가 나서 수정한 적이 있다. 그리고 몇일 뒤 같은 함수때문에 에러를 또 발생시켰다. 그 아이는 클래스를 인수로 받는 것이 나을 것 같다.

• 오류 처리를 함수로 만든다면 가독성이 많이 좋아지겠다.

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

• 목록 3-5 Switch 수정 함수의 이점이 와닿지가 않는다.

• 추상화 수준이라는게 뭐지

• 부수 효과로 발생하는 시간적인 결합이나 순서 종속성의 예는 뭘까

• 출력 인수랑 return이랑 다른건가 this는 또 왜 나온거지