함수의 구조 (function Structure) - 1

작성일 | In |

함수의 구조

클린코더스 - 백명석님 강의를 보고 작성한 글입니다.

————————————————————————————————————————————————————-

목차

————————————————————————————————————————————————————-

Arguments

  • 인자가 많아지면 복잡도가 증가한다.

  • 인자를 최대 3개

    생성자의 많은 수의 넘겨야한다면?

    Java Bean Pattern을 사용(Getter & Setter)
Builder 패턴을 적용하는 것이 더 좋은방법!!

    Boolean 인자 사용 금지

    Boolean 이라면 true, false 두가지 일을 한다는 것이기 때문에 'Method는 한가지 일만 해야한다.' 를 위반한다.

Innies not Outies

  • Parameter는 입력으로 작용해야지 출력으로 작용하면 안된다.

————————————————————————————————————————————————————-

Null defense

  • null을 전달/기대하는 함수는 boolean을 전달하는만큼 잘못된 것
  • public api의 경우는 defensive하게 프로그래밍하는 것이 맞지만 같은 팀 내에서 defensive programming을 하는것은 잘못됨. => 팀원이나 단위테스트를 못 믿는다는 말
  • null을 boolean처럼 사용하지마라
  • null체크를 한다는 것 자체가 무언가 잘못되었다는 단서
  • null여부를 지속적으로 체크할 것이 아니라 단위테스트에서 검증을 해라.

————————————————————————————————————————————————————-

The Stepdown Rule

  • 코드 상 public은 위로 private는 아래로
  • public 필드만 보고도 이해할 수 있을정도로
  • public part만 사용자들에게 전달하면 됨.
  • 중요한 부분은 위로, 상세한 부분은 밑으로

———————————————————————————————————————————————————–

Switches and cases

  • switch문장 사용을 왜 꺼리나 => OO(Object-Oriented) 스럽지않아서?

    그럼 OO(Object-Oriented)는 뭐가 좋을까?

  • OO의 가장 큰 이점 중 하나는 의존성 관리능력이다.
  • 예시

switch

  • 이상태에서는 독립적으로 배포/컴파일/개발 불가하다.
  • runtime 의존성은 그대로 둔 채로 의존성을 역전시킨다.(Dependency Inversion Principle)

switch2

  • A와 B사이에 interface를 두면 source code 의존성은 runtime 의존성과 반대가 된다.
  • Unit테스트도 잘된다 => 설계가 잘된 것.
  • TDD도 잘된다. => TDD가 잘 안된다, 어렵다 싶으면 설계가 잘못된 것.

switch case

  • 각 case는 외부 모듈에 의존성을 갖는다.
  • 독립적 배포에 방해가 됨.
  • fan-out problem
  • 외부모듈 중 하나라도 변경이 일어나면 switch문 문제생김.

제거하려면?

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

———————————————————————————————————————————————————–

Temporal Coupling

DB연결처럼 Connection을 열고, 닫고, 이런 코딩을 할 때 순서가 중요한 상황을 말한다.

  • 함수들이 순서를 지키며 호출되어야한다.
  • Passing a Block
  • Strategy Pattern

temporal

  • 사용자에게 ‘주의해서 사용하라’가 아니고 위의 사진처럼 구현
0%