[Study][CleanCode - 1] 3. 함수

📋 목차.

3. 함수
    .작게 만들어라!
    .한가지만 해라!
    .위에서 아래로 코드읽기:내려가기규칙
    .서술적인 이름을 사용하라.
    .함수 인수
    .많이 쓰는 단항 형식
    .플래그 인수 지양
    .인수 객체
    .인수 목록
    .동사와 키워드
    .부수 효과를 일으키지 마라!.
    .출력 인수
    .명령과 조회를 분리하라.
    .오류 코드보다 예외를 사용하라!.
    .try/catch 블록 뽑아내기
    .Error.java 의존성 자석
    .반복하지 마라.
    .함수를 어떻게 짜죠?
    .결론

---

✔️ 내용.

 

3. 함수

 

.작게 만들어라!

 

 함수를 만드는 첫째 규칙은 '작게!'이다. 블록과 들여 쓰기, if/else, while 문 등 블록은 한 줄이야 하는 의미다.

그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면, 코드를 이해하기도 쉬워진다.
 이 말은 중첩 구조가 생길 만큼 함수가 커져서는 안 된다. 그러므로 함수에서 들여 쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 그래야 함수를 읽고 이해하기 쉬워진다.

 

 

---

 

. 한 가지만 해라!
함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다.

 

---

 

.위에서 아래로 코드 읽기:내려가기 규칙

 

 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. 즉, 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한 번에 한 단계씩 낮아진다.

 

---

 

.서술적인 이름을 사용하라.

 

 길고 서술적인 이름일수록 함수가 하는 일을 좀 더 잘 표현하므로 좋다.
길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다.

 

---

 

.함수 인수

 

 함수에서 이상적인 인수 개수는 0개이다.
다음은 1개, 다음은 2개이다. 3개는 가능한 피하고 4개 이상은 특별한 이유가 필요하다.

 

---

 

.많이 쓰는 단항 형식

 

 함수에 인수 1개를 넘기는 흔한 이유는 두 가지이다.

 

1. 인수에 질문을 던지는 경우

 

boolean fileExists("MyFile") // MyFile 존재 여부

2. 인수로 뭔가로 변환하여 결과를 반환하는 경우

 

InputStream fileOpen("MyFile") // MyFile 을 InputStream으로 변환

 

그 외 흔하지 않은 사항으로 이벤트가 있다.

passwordAttemptFailedNtimes(int attempts) // 입력 인수로 시스템의 상태 변환

 

이 외의 단항 함수는 가급적 피한다.

 

// 변환 함수에서 출력 인수를 사용하면 혼란을 야기할 수 있다.
void includeSetupPageInfo(StringBuffer pageText) // X

// 입력 인수를 반환하는 함수라면 변환 결과는 반환 값으로 돌려준다.
StringBuffer transform(StringBuffer in) // O

 

---

 

.플래그 인수 지양

 

 플래그 인수는 true/false에 따라 함수가 할 일이 두 가지 이상이라는 것을 공표하는 셈으로. 앞서 계속 언급되는 '한 가지만 해라!'에 위배된다.

 

// X
void setUp(boolean isSet){
}

 

---

 

.인수 객체

 

 인수가 2~3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어본다.

 

Circle makeCircle(double x, double y, double radius); // before
Circle makeCircle(Point center, double radius); // after

 

 객체를 생성해 인수를 줄이는 방법이 눈속임으로 보일지 모르지만 그렇지 않다.
x와 y를 묶듯이 변수를 묶어 넘기려면 이름을 붙여야 하므로 결국 개념을 표현하게 된다.

 

---

 

.인수 목록

 

 때로는 인수 개수가 가변적인 함수도 필요하다. String.format 메서드가 좋은 예이다.

가변 인수를 취하는 모든 함수에도 '함수 인수' 원리가 적용된다. 단항, 이항 삼항 등의 이 이상을 사용할 경우 문제가 있다.

String.format("%s worked %.2f hours.", name, hours);

public String format(String format, Object... args)

 

---

 

.동사와 키워드

 

 함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수 이름이 필수다.

단항 함수의 경우 함수와 인수가 동사/명사 쌍을 이뤄야 한다. 예로 write(name)은 이해하기가 쉽다.
좀 더 좋은 이름은 writeField(name)이다. Field에 이름을 쓴다는 사실이 명확히 드러나기 때문이다.

 

 다음으로는 함수 이름에 키워드를 추가하는 형식이다. 즉 함수 이름에 인수 이름을 넣는다
예로 assertEquals보다 assertExpectedEqualsActual(expected, actual)이 더 좋다. 이럴 경우 인수의 순서를 기억할 필요가 없어진다.

 

 

---

 

.부수 효과를 일으키지 마라!.

 

 부수 효과는 거짓말이다. 함수에서 한 가지 일을 하고자 해 놓고 다른 일을 하게 되는 것이니 말이다.

만약 필요한 부수효과일 경우 함수 이름에 분명히 명시하는 게 좋다. 물론 함수가 '한 가지만 해라!'라는 규칙을 위배하게 되지만.

 

---

 

.출력 인수

 

 일반적으로 출력 인수는 피해야 한다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.

public void appendFooter(StringBuffer report) // X
report.appendFooter(); // O

 

---

 

.명령과 조회를 분리하라.

 

 함수는 수행하거나  답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안 된다.
객체의 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나이다. 둘 다 할 경우 혼란을 초래한다.

 

public boolean set(String attribute, String value); // X 상태 변경과 , exists 여부

public boolean attributeExists(String name): // O exists
public void setAttribute(String name, String value); // O 상태 변경

 

---

 

.오류 코드보다 예외를 사용하라!.

 

 명령 함수에서 오류 코드를 반환하는 방식은 앞서 말한 '명령과 조회를 분리하라' 규칙을 미묘하게 위반한다. 자칫 if문에서 명령을 표현식으로 사용하기 쉬운 탓이다.

 

// X
if(deletePage(page) == E_OK){
	error~~
}

// O	
try{
	deletePage(page);
	...
}catch(Exception e){
	error~~
}

 

---

 

.try/catch 블록 뽑아내기

 

 try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞인다. 따라서 try/catch 블록을 별도 함수로 뽑아내는 편이 좋다.

 

오류 처리도 한 가지 작업이다.

// X
public void delte(Page page) {	
	try{
		deletePage(page);
		...
	}catch(Exception e){
		error~~
	}
}

// O
public void delete(Page page) {
	try{
		deletePageAndAllReferences(page);
	}catch(Exception e){
		logError(e);
	}
}


private void deletePageAndAllReferences(Page page) throws Exception {
	deletePage(page)
	...
}

private void logError(Exception e){
	error~~
}

 

---

 

.Error.java 의존성 자석

 

 오류 코드를 반환한다는 이야기는, 클래스든 열거형 변수든, 어디선가 오류 코드를 정의한다는 뜻이다.

 

public enum Error {
	OK,
	INVALID,
	...
}

 

 위와 같은 클래스는 의존성 자석이다. 다른 클래스에서 Error enum을 improt 하여 사용해야 하므로, 즉 Error enum이 변하면 Error enum을 사용하는 클래스 전부를 다시 컴파일하고 재배치해야 한다.
그래서 Error 클래스 변경이 어려워진다. 따라서 새 오류 코드를 추가 하기보다는 기존의 오류코드를 재 사용한다.

 

 오류 코드 대신 예외를 사용하면 새 예외는 Exception  클래스에서 파생된다. 따라서 재컴파일/재배치 없이 새 예외 클래스를 추가할 수 있다. -> 에러 코드를 사용하지 말고 Exception으로 사용. 굳이 ErroCode를 선언하여 의존성을 높일 필요가 없다.

 

---

 

.반복하지 마라.

 

 관계형 데이터베이스에 정규 형식이 있듯이. 객체 지향 프로그래밍은 코드를 부모 클래스로 몰아 중복을 없앤다.

 

---

 

.함수를 어떻게 짜죠?

 

 처음부터 완벽한 규칙을 가진 함수를 짜기는 어렵다. 처음에는 길고 복잡하며 중복도 많을뿐더러 앞서 말한 규칙 대부분을 위배한다. 하지만 이러한 코드를 빠짐 없애 테스트하는 단위 테스트 케이스를 만든다.

 

 다음으로는  코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서도 바꾸며. 때로는 전체 클래스를 쪼개기도 한다.
 이 모든 작업 중에는 항상 단위 테스트는 통과해야 한다. 최종적으로는 앞서 말한 규칙을 따르는 함수가 얻어진다.

 

---

 

.결론

 

 모든 시스템은 특정 응용 분야 시스템을 기술할 목적으로 프로그래머가 설계한 도메인 특화 언어(Domain Specific Language, DSL)로 만들어진다. 함수는 그 언어에서 동사며, 클래스는 명사이다. 프로그래밍의 기술은 언제나 언어 설계의 기술이다.

 

 프로 프로그래머는 시스템을 (구현할) 프로그램이 아니라. (풀어나갈) 이야기로 여긴다. 앞서 말한 규칙들을 사용하는 이유는 이야기를 풀어가는 데 있다는 사실을 명심하길 바란다.

 

---

 

📝 느낀점.

- 다양한 규칙들이 제시되었지만. 마지막 결론에서의 프로그래밍 구현을 생각하기보다는 이야기를 풀어나가는 것으로 생각하라는 말에서 모든 규칙들이 설명이 된 것 같다.