Arguments

argument가 많아지면 복잡도가 증가합니다.

Boolean 인자 사용 금지

• flag 값으로 사용하는 boolean 값을 2개로 분리합니다. 2가지 일을 하기 때문에.
• if 조건문 밖으로 밀어낼 때 까지 이를 계속한다. 의도가 명확해짐!

Innies not Outies

the null defence

Step down rule

• 모든 public 위에, private 아래에 넣고, 설명을 할 때에는 private 없이도 설명 가능해야 한다.
• 중요한 부분은 위로, 상세한 부분은 아래로. public part만 사용자에게 전달하면 된다.
• backward reference 없이 top to bottom 으로 읽을 수 있다.
• 중요도 순으로 보다가, 그만 봐도 될 정도로 “편집”된 상태여야 한다!

Switch case

• switch문은 Object Oriented 같지 않다 (<?)

• 객체지향의 가장 큰 이점은 의존성 관리 능력이다

• 모듈A가 모듈B를 사용할 때 A → B

  • source code dependency : 소스코드 변경시 사용처 코드를 변경해야 하는 것
  • run time dependency : 실제로 메모리에 올라와서 실행할 때 호출되는 것
  • 독립적으로 컴파일이 불가능하다
  • C에서는 헤더파일이 변경되면, 해당 헤더파일을 갖고 있던 모든 파일이 다시 컴파일 되곤 했다.

• 하지만, 객체 지향을 사용하면 runtime 의존성을 그대로 둔 채, soure code 의존성을 역전 시킬 수 있다. (Dependency Inversion Principle)

  • polymorphic Interface를 삽입하여, 모듈 A는 인터페이스에 의존하고 모듈 B는 인터페이스로부터 derive 한다.
  • A → I ← B Inversion 소스코드 의존성
  • A ← B 소스코드 의존성 (역전)
  • A → B 런타임 의존성
  • B source code의 의존성은 run time의존성과 반대가 된다.
  • 독립적인 개발과 배포가 가능해진다 Independent Deployability
    • 병렬개발이 가능해진다: 유일하게 개발자를 추가했을 때 효율이 올라가는 Case

• 그러나 switch문장은 독립적 배포에 방해가 된다. 각 case에 해당하는 문장은 외부 모듈에 의존성을 갖는다. 다수의 다른 모듈에 의존성을 가질 수 있다. fan-out-problem

  • switch문장을 polymorphic interface호출로 변환하여 해결
  • case에 있는 문장들을 별도의 클래스로 추출하여 변경 영향이 발생하지 않도록 한다