클린코더스 5강 Function Structure #1

💡백명석 님의 클린 코더스 강의를 듣고 요약한 자료입니다.

목차

1, 2강 OOP
3, 4강 Function
5강 Function Structure
6강 Form

Arguments

몇 개의 인자를 받을 것인가?

인자가 많아지면 함수의 복잡도가 증가한다. 인자의 개수는 많지 않은 것이 좋다. 3개를 넘지 않는 것을 권장한다.

특히 생성자에 인자가 많으면 실수할 확률이 매우 높아진다. 차라리 Java Bean의 setter를 방식으로 객체를 초기화하는 게 낫다. 하지만 setter로 객체를 초기화하는 동안 그 객체는 매우 불안정한 상태라는 단점이 있다.

setter보다 Builder패턴이 더 나은 선택일 수 있다. Builder패턴에서 Builder를 생성할 때 필수 인자를 받고 나머지는 빌더로 채울 수 있도록 설계하는 것이 좋다.

인자로 boolean 쓰지 마라

인자로 boolean값을 받아서 상태를 변경하고 true/false일 경우 각각 로직을 나누는 경우가 있다. 이렇게 해야 한다면 함수를 두 개로 분리해라. 이건 함수가 두 가지 일을 하는 것이다.

Argument를 변경해서 return하지 마라

인자는 함수로 전달되는 것이지 함수에서 변경되어 나오는 것이 아니다. 그렇게 해야 한다면 로컬 변수를 만들어서 그걸 return해라.

the null defense

public API의 경우는 어떤 값이 들어올 지 알 수 없기 때문에 null에 대비해야 하는 것이 맞다.

그걸 제외하고 팀원과 개발하는데 나 또는 팀원이 작성한 코드 때문에 null이 올 지 모른다고 신뢰하지 못하는 방어적 코드는 나쁘다. 이건 테스트를 통해 미리 검증해야 한다. null을 전달하거나 기대하는 함수는 boolean을 인자로 받는 함수만큼이나 잘못된 것이다. null인 경우의 행위, null이 아닌 경우의 행위를 나눠야 한다면 2개의 함수를 나눠야 한다.

절대 null을 반환하지 않도록 코드를 짜라. null체크로 로직 더럽히지 마라. 그게 안 되면 exception으로 처리해라.

Step-down rules

객체의 중요한 부분은 위로 올리고 상세한 구현부는 밑으로 내리려야 한다.

모든 public메서드는 위에 그 아래는 private메서드. public메서드 이름이 잘 지어졌으면 private메서드를 볼 필요 없다.

2가지 이점이 있다.

작성자는 읽는 사람이 오해하지 않도록 상세한 부분은 제거하고 위에 있는 코드만으로 전달 가능.

읽는 사람은 윗줄부터 읽고 알 것 같으면 private메서드까지 볼 필요가 없다.

switch and cases

switch는 객체지향 책에서 사용하지 말 것을 권장한다. 왜 사용하면 안 되느냐는 것에 대해 설명하지는 않는다. 단지 switch를 쓰는 것은 객체지향스럽지 않다거나 세련되지 않다거나 하는 것은 이유가 될 수 없다.

객체지향의 가장 큰 장점은 의존성 관리다. 의존성 관리를 통해서 상위 로직이 하위 로직에 의존하지 않을 수 있다.

객체지향은 다형적인 인터페이스를 통해 의존성을 관리한다. 의존하는 것은 같으나 의존을 거꾸로(DIP)함으로써 의존성 줄인다. 인터페이스만 변경되지 않으면 독립적인 배포가 가능해짐. 독립적인 컴파일도 가능하다는 얘기고 독립적인 개발도 가능하다는 것.

의존성이 강하게 결합되어 있음

DIP가 적용된 의존성

이렇게 설계되어야 TDD도 잘 된다.

스프링을 잘 쓰고 있으면 이런 구조로 코드가 나온다. HttpRequest, HttpResponse를 쓰지 않고도 개발할 수 있어! ORM을 매우 손쉽게 쓸 수 있어! 이런 것도 있지만 이런 구조를 가능하게 해주는 흐름을 제공한다는 것이 스프링의 가장 큰 장점이다.

테스트를 작성하기 어렵다는 것은 설계가 잘못되었다는 것. 이런 구조가 아니어서 테스트가 어려운 것. 이런 테스트라면 항상 테스트가 쉬워야 한다.

switch에는 case문이 있다. 만약 case문이 5개가 있다고 하면, 그 중 하나면 변경이 있어도 switch문은 영향을 받는다. 이건 switch문만의 문제는 아니다. switch문을 사용하는 모든 로직에 영향을 끼칠 수 있다.

변경하기 어려운 구조

switch문 제거 순서

1. switch를 다형적인 인터페이스 호출로 변환
2. case에 있는 문장을 별도의 클래스로 추출하여 변경 영향이 발생하지 않도록 한다.

참고 : https://github.com/msbaek/videostore

객체지향적으로 변경했을 때 구조