• 작은 많은 함수들로 쪼개야 한다. 언제까지? 추상화 수준이 변하지 않을 때 까지.
• 작은 많은 함수들은 추상화 수준이 한단계 높은 서술적인 이름을 가져야 한다.
• Extract Object Method (IDE 지원 방법인가보다)
  • 큰 함수는 Object로 쪼갤 수 있다.
  • 변수(variables), 인자(arguments) → field variables
  • 기능 블록 (indentation들을 갖는) → method

인상 깊었던 것

• 함수를 최대한 쪼개라고 했을때, 진짜 그것이 효과가 있었나? 오히려 depth가 깊은 함수를 만들게 되어 불편해지지 않을까? 생각했다. 하지만, 경험에 기반해보면 큰 함수를 쪼개기는 어려워도 작은 함수를 조립하는 것이 훨씬 쉬웠기 때문에 최대한 함수를 쪼개라는 내용이 이해가 잘 갔다.
• 나는 OOP가 효과적으로 현실세계를 본뜬 모델링 하여, 복잡한 세상의 서비스들을 잘 묘사하고 이들의 관계를 정의하기 위해서 태어났다고 생각했다. 그래서, OOP의 정수는 객체간의 관계, 더 나아가 상속이라고 생각했다. 상속을 잘 쓸 수 없다면 클래스로 만드는 것이 의미가 있나? 라는 생각이었는데 Extract Object Method를 사용한다는게 생소하게 느껴졌다. 왜냐하면, Class가 없는 언어들 (C, Rust, GO,..)도 이런 기능을 하는데에는 부족함이 없다고 판단하여 Class 문법을 넣지 않은것이 아닐까라고 생각했기 때문이다.
• Class문법이 없는 이들은 구조체와 인터페이스를 사용해 객체지향적 설계를 구현한다고 한다. 이것이 “조합Composition” 하는 방법을 통해 기능을 필요에 따라 구현하고자 함이 아니었을까? 잘 모르겠다.

질문?

세미나랑 관계없긴 한데, 선언형과 객체지향형이 관계가 있는 프로그래밍 패러다임이라고 생각해서 검색을 냅다 해봤습니다. 그런데 이상한 그림이 많이 목격되는 것 같았어요

• characterization vs approval test

  • characterization: 기존 코드가 어떤 결과를 반환하는지 몰라 “개똥이”

  • asset. “goodhart’s law” 라는 결과를 알게됨. assert

  • apporval: 어떤 것을 기대한다는것을 먼저 정의하고 시작.

  • one pile, orthogonal

    • 의도, 읽는 이유

  • ↔ one thing. re-phrase

    • 함수 이름: 추상화1, 함수 내의 문장: 추상화2
    • 함수 내의 문장들은 같은 수준의 추상화
    • extract till you drop. rephrase, slap

  • naming as a process, continuos naming.

객체지향

• OOP는 실세계가 잘 묘사되지 않는다. 메타포에 불과한다면 ok. is-a 관계가 아닐 수 있다
• 이건 유지보수를 하기 위한 좋은 방법일 뿐이다.
• 다른 언어에서는 이렇게 클래스를 만들어서 사용하는 방법이 어렵기 때문에, 이런 방식을 사용하는 것
• 의존성 관리를 통해/모듈화를 통해 유지보수가 좋게 만들기 위한 수단 중 하나이다