clean code 제 3장 함수

함수를 clean하게 만드는 방법

 

1. 작게만들기

2. 블록과 들여쓰기

3. 한가지 기능만

4. 서술적인 네이밍

5. 함수 인수

6. 부수효과x

7. 명령조회

8. 오류예외

9. 구조적프로그래밍

 

 

우선 bad 함수 예시

 

두겹으로 중첩된 if문으로 

명확하지 않은 플래그, 문자열,함수 호출을 하고 있음.

 

-> 함수가 너무 길고, 어떤 일을 하는지 알기 힘듦.

 

 

 

1. 작게 만들기

한 함수의 길이는 20줄도 길다고 한다.

 

 

 

2. 블록과 들여쓰기는 한줄이어야 한다.

if, else, while 문에 들어가는 코드는 한줄이어야하고 대개 함수를 호출해야한다.

func rednerPageWithSetupAndTeardowns(pageData: PageData, isSuite: Bool) -> String {
	if (isTestPage(pageData)) {
		inlcudeSetupAndTeardownPages(pageData, isSuite)
	}
    return pageData.getHtml()
}

 

 

 

3. 한가지 함수에 한가지 기능만.

함수당 추상화 수준도 한가지로, 함수내 모든 추상화 수준이 동일해야한다.

 

getHtml() - 추상화 수준 높은편

.append("\n") - 추상화 수준 낮은 편

 

구현하다보면 한 함수에 같은 추상화 수준만을 가지긴 쉽지 않은데,

'한 가지'만 하는 함수로 구현하면 쉽게 구현 가능하다.

 

switch문을 사용하게될 경우 '한 가지'만 하는 함수를 구현하기 어려움. (N가지 일을 처리)

 

public Money calculatePay(Employee e) throws InvalidEmployeeType {
  switch (e.type) {
    case COMMISIONED :
      return calculateCommissionedPay(e);
    case HOURLY :
      return calculateHourlyPay(e);
    case SALARIED :
      return calculateSalariedPay(e);
    default :
      throw new InvalidEmployeeType(e.type);
  }
}

 

1. 새 직원의 유형 (case)가 추가 될 경우 더 길어진다.
2. e.type 에 따라 기능이 달라져서 한 가지 기능만을 하지 않음. SRP 원칙 (하나의 객체는 하나의 책임만) 위반
3. OCP 원칙(확장 open, 수정 close) 위반 - 새 직원 유형을 추가할 때 마다 코드를 변경해야함.
4. 위 구조와 동일한 함수가 무한정 존재함.

isPayday(Employee e, Date date);

deliverPay(Employee e, Money pay);

 

 

해결방안

- Employee의 인터페이스 Abstract Factory를 만들어 switch문을 숨김.

- 얻을 수 있는 효과: 위 4를 해결하고 1,2,3을 최소화 할 수 있음.

 

// 추상 클래스 Employee
public abstract class Employee {
  public abstract boolean isPayday();
  public abstract boolean calculatePay();
  public abstract boolean deliverPay(Money pay);
}

// Employee를 상속 받는 객체들을 생성할 수 있는 EmployeeFactory 인터페이스
public interface EmployeeFactory {
  public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}

// EmployeeFactory를 구현한 클래스
public class EmployeeFactoryImpl implements EmployeeFactory {
  public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
    switch (r.type) {
      case COMMISIONED :
        return new CommissionedEmployee(r);
      case HOURLY :
        return new HourlyEmployee(r);
      case SALARIED :
        return new SalariedEmployee(r);
      default :
        throw new InvalidEmployeeType(r.type);
    }
  }
}

 

이렇게 switch문을 employee의 impl로 따로 구현해주게된다면

하위 employee 객체에서 switch문을 여러번 사용하지 않게 코드를 작성할 수 있다.

 

Abstract Factory 는 객체 생성에 대한 추상화된 인터페이스를 제공하는 디자인 패턴

객체 생성을 담당하는 코드를 추상화하여 객체 생성 과정의 변화에 유연하게 대처할 수 있다.

추상 팩토리 패턴은 일반적으로 비슷한 기능을 가진 객체를 생성하는 경우 사용된다.

 

Abstract Factory 예제

만약 여러 종류의 GUI 컴포넌트(버튼, 텍스트 상자 등)를 만들어야 한다면, 

추상 팩토리를 사용하여 각각의 GUI 컴포넌트의 생성을 추상화하여 유연한 코드를 작성할 수 있다.

 

// button, textfield를 생성하는 Abstract Factory Protocol
protocol GUIFactory {
    func createButton() -> Button
    func createTextField() -> TextField
}

// button, textfield가 가져야 할 속성과 메서드를 정의 Abstract Product Protocol
protocol Widget {
    var backgroundColor: UIColor { get set }
    func display()
}

 

버튼과 텍스트필드의 생성을 추상화 하였으며,

 

// iOS용 구체적인 팩토리 클래스
class IOSFactory: GUIFactory {
    func createButton() -> Button {
        return IOSButton()
    }
    
    func createTextField() -> TextField {
        return IOSTextField()
    }
}

// iOS용 구체적인 버튼 클래스
class IOSButton: UIButton, Widget {
    var backgroundColor: UIColor = .white
    
    func display() {
        // 버튼을 화면에 보여주는 코드
    }
}

// iOS용 구체적인 텍스트 필드 클래스
class IOSTextField: UITextField, Widget {
    var backgroundColor: UIColor = .white
    
    func display() {
        // 텍스트 필드를 화면에 보여주는 코드
    }
}

 

이런식으로 위 프로토콜을 구현하는 구체적인 팩토리와 프로덕트 class를 구현해준 뒤,

 

 

// 클라이언트 코드
let factory: GUIFactory = IOSFactory()

let button = factory.createButton()
button.backgroundColor = .blue
button.display()

let textField = factory.createTextField()
textField.backgroundColor = .gray
textField.display()

클라이언트에서는 IOSFactory를 생성하고,

createButton(), createTextField() 메서드로 Button, TextField 생성.

 

공통된 속성 backgroundColor와 display() 메서드를 사용하여 화면에 출력해줌

 

 

 

4. 서술적인 이름 사용

저자는 함수 이름을 tesatableHtml -> SetupTeardownIncluder.render로 변경해줌

 

길고 서술적인 이름이 짧고 함축적인 이름보다 좋음.

-> 함수명만 읽고 함수 기능을 파악할 수 있게 해줌(한가지 기능 잘 수행한다면)

 

 

 

5. 함수 인수

 

5.1 함수 인수의 개수는 3개 이하로 해야함.

 

함수 인수는 적을수록 좋다.

includeSetupPageInto(newPageContent) 보다 includeSetupPage()가 이해하기 쉬움

 

private void inlcudeSetupAndTeardownPages() throws Exception {
	
    includeSetupPages();
    includePageContent();
    includeTeardownPages();
    updatePageContent();
    
}

 

저자는 함수 인수 4개부터는 특별한 이유가 있어도 사용하지 말라고함.

 

 

5.2 플래그 인수는 지양해야한다.

함수로 부울값을 넘기는 관례는 끔찍하다고 말하고 있음.

 

func rednerPageWithSetupAndTeardowns(pageData: PageData, isSuite: Bool) -> String {
	if (isTestPage(pageData)) {
		inlcudeSetupAndTeardownPages(pageData, isSuite)
	}
    return pageData.getHtml()
}

 

isSuite로 Bool 값을 넣어주는 대신 

rederForSuite()와 renderForSingleTest()라는 함수로 나눠서 사용하라고 함.

 

 

5.3 동사와 키워드

write(name) 대신 동사와 명사를 쌍으로 사용하여

wirteField(name) 이렇게 작성하면 좀 더 알기 쉽다.

 

함수 이름에 키워드를 추가해주면 인수 순서를 기억하지 않아도 된다고 함.

assertExpected() 대신 assertExpectedEqualsActual(expected, actual)

 

 

 

6. 부수 효과 일으키기x

userName과 password를 입력받아 true of false를 return 하는

암호 확인하는 함수에 Session.initialize() 호출 할  경우

사용자를 인증하면서 기존 세션 정보를 지워버리는 상황이 생길 수 도 있다.

 

 

 

7. 명령과 조회 분리

속성값을 찾아 value로 설정하고 성공하면 true를 반환하는 함수로

public boolean set(String attribute, String value); 가 있을 때

 

if (set("username", "unclebob")).. 이런식으로도 사용 될 수 있다.

 

1. username이 unclebob으로 설정되어 있는 경우인지

2. username이라는 속성값에 unclebob값을 성공적으로 넣었을 경우인지

 

if 문장만 봐서는 직관적으로 알기 어렵다.

 

if (attributeExist("username")) {

  setAttribute("username", "unclebob");

}

 

이런식으로 명령과 조회를 분리해서 작성하면 좋음.

 

 

 

8.오류 코드보다는 예외를 사용

오류코드를 반환하는 형태는 위 7번의 명령조회 분리 규칙에 어긋남.

 

if (deletePage(page) == E_OK) {

  if (registry.deleteRefrence(page.name) == E_OK) {

~~

  }

}

 

이렇게 작성하기 보다는

try {

  deletePage(page);

  registry.deleteReference(page.name);

}  catch {

}

 

이런식으로 Try/Catch로 추출해서 사용하면 좋음

 

 

public enum Error {

  OK,

  INVAILD,

  NO_SUCH,

  LOCKED

}

이런식으로 error enum을 사용할 경우

수정사항이 생기면 Error 클래스 전부 다시 컴파일하고 배치해야함.

 

오류 enum 대신 예외를 사용하면 좋음

새 예외는 Exception 클래스에서 파생됨

 

 

 

9. 구조적 프로그래밍

return은 하나여야하며 루프안에서 break, continue 사용x

goto 금지

 

 

여기까지가 clean code 제 3장

함수를 잘 만드는 기교

였습니다.