프로그래밍 초창기에는 시스템을 루틴과 하위 루틴으로 나눴다. 예전 시절에는 시스템을 프로그램, 하위 프로그램, 함수로 나눴다. 지금은 함수만 살아남았다.
어떤 프로그램이든 가장 기본적인 단위가 함수다.
일단 먼저, 정리되지 않은 함수를 보고 가보자.
정리 안된 함수
public static String testableHtml(PageData pageData, boolean includeSuiteSetup) throws Exception {
WikiPage wikiPage = pageData.getWikiPage();
StringBuffer buffer = new StringBuffer();
if (pageData.hasAttribut("Test")) {
if (includeSuiteSetup) {
WikiPage suiteSetup = PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_SETUP_NAME, wikiPage);
if (suiteSetup != null) {
WikiPagePath pagePaht= ...
}
}
WikiPage setup = ...
if (setup != null) {
..
}
}
...
if () {
..
}
if () {
...
}
...
}
}
}
...
return pageData.getHtml();
}따라치기도 너무 힘들다...
읽기도 따라치기도 힘든 메서드를 어떻게 정리할 것인가
작게 만들어라!
public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception {
boolean isTestPage = pageData.hasAttribute("Test");
if (isTestPage) {
WikiPage testPage = pageData.getWikiPage();
StringBuffer newPageContent = new StringBuffer();
includeSetupPages(testPage, newPageContent, isSuite);
newPageContent.append(pageData.getContent());
includeTeardownPages(testPage, newPageContent, isSuite);
pageData.setContent(newPageContent.toString());
}
return pageData.getHtml();
}위 코드와 비교했을 때 이 코드는 어떠한가? 한 눈에 봐도 가독성이 좋아보이지 않나?
그렇다면 이 함수가 읽기 쉽고 이해하기 쉬운 이유는 무엇일까? 의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까? 함수에 어떤 속성을 부여해야 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까?
함수를 만들 때 최대한 ‘작게!’ 만들어라.
첫 째도 작게 둘 째도 더 작게다.
저자는 100줄도 넘어서는 안된다고 한다. 심지어 20줄도 작다고!
위 코드도 길다. 되도록 한 함수당 2~5줄 이내로 줄이는 것을 권장한다.
public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception {
if (isTestPage(pageData))
includeSetupAndTeardownPages(pageData, isSuite);
return pageData.getHtml();
}블록과 들여쓰기
if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다.
해당 블록에서 함수를 호출하기 때문에 한줄로 끝맺고 함수 네이밍이 적절하다면 이해하기도 훨씬 쉬워진다.
즉, 중첩 구조가 생길만큼 함수가 커져서는 안된다.
함수에서 들여쓰기 수준은 2단을 넘어서면 안된다.
한 가지만 해라
함수는 한가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한가지만을 해야 한다.
지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 하는 것이다.
(어쨌거나 우리가 함수를 만드는 이유는 큰 개념을(함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가)
함수 내 섹션
함수를 여러 섹션으로 나눌 수 있다면 그 함수는 여러작업을 하는 셈이다.
책 속 example.java
public static int[] generatePrimies(int maxValue) {
if (maxValue >= 2) { //유일하게 유효한 경우
int s = maxValue + 1;
boolean[] f = new boolean[s];
int i;
//배열 true로 초기화
for ( i =0; i < s; i++) {
f[i] = true;
}
//소수가 아닌 알려진 숫자 제거
f[0] = f[1] = false;
//체
int j;
..
//소수 개수는?
int[] primes = new int[count];
//소수를 결과 배열로 이동한다.
for (i = 0, j=0; i < s; i++) {
if (f[i]) {
...
}
}
return primes; //소수 반환
else {
return new int[0];
}
}(예제를 그대로 따라 치다가 손목 나갈 것 같아서 각설한다..)
주석만 보다 싶이 declarcations, initiailzations, sieve라는 3개의 섹션으로 나눠진다. 한 함수에서 여러 작업을 한다는 증거다. 한 가지 작업만 하는 함수는 자연스럽게 섹션으로 나누기 어렵다.
함수 당 추상화 수준은 하나로!
함수가 ‘한가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 된다.
만약 한 함수 내에 추상화 수준이 섞이게 된다면 읽는 사람이 헷갈린다.
특정 표현이 근본 개념인지 아니면 세부사항인지 구분하기 어려운 탓이다. 이 두 가지가 뒤섞기 시작하면, 깨어진 창문처럼 사람들이 함수에 세부사항을 점점 더 추가한다. -> 복잡도가 올라가고 가독성이 내려가는 상황 발생
추상화 수준이란?
큰 개념을 a,b,c로 분해했다면, 이 세가지가 {}로 만들고 연결시켜줬다고 가정해보자.
그럼 이 세가지가 추상화 수준이 되는 것이다.
빠른 이해를 위한 이미지 첨부
- 함수 도식화
- 추상화 수준
- 추상화 수준의
높음, 중간, 낮음
참조 : https://sosimhan-dev.tistory.com/4
위에서 아래로 코드 읽기:내려가기 규칙
코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
함수 추상화 부분이 한번에 한단계씩 낮아지는 것이 가장 이상적이다.(Top-Down)
Switch문
switch문은 작게 만들기 어렵다. 또한, '한 가지' 작업만 하는 swtich 문도 만들기 어렵다. 본질적으로 switch문은 N가지를 처리하기 때문이다.
public Money calculatePay(Employee e) throws InvalidEmployeeType {
switch (e.type) {
case COMMISSIONED:
return calculateCommissionedPay(e);
case HOURLY:
return calculateHourlyPay(e);
case SALARIED:
return calculateSalariedPay(e);
default:
throw new InvalidEmployeeType(e.type);
}
}위 함수는 4가지의 문제점이 있다.
- 함수가 김 (새 직원 유형을 추가하면 더 길어짐)
- '한 가지' 작업만 수행하지 않음
- SRP(단일 책임 원칙) 위반
- OCP(개방 폐쇄 원칙) 위반 (새 직원 유형을 추가할 때마다 코드를 변경하기 때문)
이 때, 다형성을 이용하여 switch문을 abstract factory에 숨겨 다형적 객체를 생성하는 코드 안에서만 switch를 사용하도록 한다.
public abstract class Employee {
public abstract boolean isPayday();
public abstract Money calculatePay();
public abstract void deliverPay(Money pay);
}
-----------------
public interface EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}
-----------------
public class EmployeeFactoryImpl implements EmployeeFactory {
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
switch (r.type) {
case COMMISSIONED:
return new CommissionedEmployee(r) ;
case HOURLY:
return new HourlyEmployee(r);
case SALARIED:
return new SalariedEmploye(r);
default:
throw new InvalidEmployeeType(r.type);
}
}
}하지만 switch문은 불가피하게 써야될 상황이 많으므로, 상황에 따라서는 사용 할 수도 있다.
서술적인 이름을 사용하라!
“코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다” - 워드
작은 함수는 그 기능이 명확하므로 이름을 붙이기가 더 쉽다.
일관성 있는 서술형 이름을 사용한다면 코드를 순차적으로 이해하기도 쉬워진다.
함수 인수
함수에서 이상적인 인수 개수는 0개(무항). 인수는 코드 이해에 방해가 되는 요소이므로 최선은 0개이고, 차선은 1개뿐인 경우이다. 출력인수(함수의 반환 값이 아닌 입력 인수로 결과를 받는 경우)는 이해하기 어려우므로 왠만하면 쓰지 않는 것이 좋겠다.
많이 쓰는 단항 형식
인수에 질문을 던지는 경우
boolean fileExists(“MyFile”);
인수를 뭔가로 변환해 결과를 변환하는 경우
InputStream fileOpen(“MyFile”);
이벤트 함수일 경우
passwordAttemptFailedNtimes(int attempts)
대신, 이벤트 함수라는 사실이 코드에 명확히 드러나야 한다.
위의 3가지가 아니라면 단항 함수는 가급적 피하는 것이 좋다.
StringBuffer transform(StringBuffer in)이void transform(StringBuffer out)보다 좋다.
플래그 인수
플래그 인수는 추하다.(ㅋㅋ) bool 값을 넘기는 것 자체가 그 함수는 한꺼번에 여러가지 일을 처리한다고 공표하는 것과 마찬가지다.
이항 함수
단항 함수보다 이해하기가 어렵다. Point 클래스의 경우에는 이항 함수가 적절하다. 2개의 인수간의 자연적인 순서가 있기 때문이다. Point p = new Point(x,y);
무조건 나쁜 것은 아니지만, 인수가 2개이니 만큼 이해가 어렵고 위험이 따르므로 가능하면 단항으로 바꾸도록 한다.
삼항 함수
이항 함수보다 이해하기가 훨씬 어려우므로, 위험도 2배 이상 늘어난다. 삼항 함수를 만들 때는 신중히 고려하라.
인수 객체
인수가 많이 필요할 경우, 일부 인수를 독자적인 클래스 변수로 선언할 가능성을 살펴보자 x,y를 인자로 넘기는 것보다 Point를 넘기는 것이 더 낫다.
Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);인수 목록
때로는 String.format같은 함수들처럼 인수 개수가 가변적인 함수도 필요하다. String.format의 인수는 List형 인수이기 때문에 이항함수라고 할 수 있다.
public String format(String format, Object... args)동사와 키워드
함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수 이름이 필수다.
단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야한다.
writeField(name);
함수이름에 키워드(인수 이름)을 추가하면 인수 순서를 기억할 필요가 없어진다.
assertExpectedEqualsActual(expected, actual);
부수 효과를 일으키지 마라
부수효과는 거짓말이다. 함수에서 한가지를 하겠다고 약속하고는 남몰래 다른 짓을 하는 것이므로, 한 함수에서는 딱 한가지만 수행하자
public class UserValidator {
private Cryptographer cryptographer;
public boolean checkPassword(String userName, String password) {
User user = UserGateway.findByName(userName);
if (user != User.NULL) {
String codedPhrase = user.getPhraseEncodedByPassword();
String phrase = cryptographer.decrypt(codedPhrase, password);
if ("Valid Password".equals(phrase)) {
Session.initialize();
return true;
}
}
return false;
}
}위 코드에서 Session.initialize();는 함수명과는 맞지 않는 부수효과이다.
즉, checkPassword 함수는 세션을 초기화해도 괜찮은 경우에만 호출이 가능하다.
만약 시간적인 결합이 필요하다면 함수 이름에 분명히 명시해야 했다.
-> checkPasswordAndInitializeSession이라는 이름이 훨씬 좋다. (물론 한 가지만 한다는 규칙을 위반하지만)
출력인수
일반적으로 출력 인수는 피해야 한다.
함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택하라.
번외)
객체 지향 프로그래밍이 나오기 전에는 출력 인수가 불가피한 경우도 있었다. 하지만 객체 지향 언어에서는 출력 인수를 사용할 필요가 거의 없다. 출력 인수로 사용하라고 설계한 변수가 바로 this이기 때문이다.
명령과 조회를 분리하라
함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다. 둘 다 하면 안된다
객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다.
public boolean set(String attribute, String value);
같은 경우에는 속성 값 설정 성공 시 true를 반환하므로 괴상한 코드가 작성된다.
if(set(“username”, “unclebob”))...
그러므로 명령과 조회를 분리해 혼란을 주지 않도록 한다.
오류코드보다 예외를 사용하라!
try/catch를 사용하면 오류 처리 코드가 원래 코드에서 분리되므로 코드가 깔끔해 진다.
Try/Catch 블록 뽑아내기
try/catch 블록은 원래 추하다. 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞는다.
if (deletePage(page) == E_OK) {
if (registry.deleteReference(page.name) == E_OK) {
if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
logger.log("page deleted");
} else {
logger.log("configKey not deleted");
}
} else {
logger.log("deleteReference from registry failed");
}
} else {
logger.log("delete failed"); return E_ERROR;
}try/catch 블록을 별도 함수로 뽑아내는 편이 좋다.
아래와 같이 정상 작동과 오류 처리 동작을 뒤섞는 추한 구조이므로 if/else와 마찬가지로 블록을 별도 함수로 뽑아내는 편이 좋다.
public void delete(Page page) {
try {
deletePageAndAllReferences(page);
} catch (Exception e) {
logError(e);
}
}
private void deletePageAndAllReferences(Page page) throws Exception {
deletePage(page);
registry.deleteReference(page.name);
configKeys.deleteKey(page.name.makeKey());
}
private void logError(Exception e) {
logger.log(e.getMessage());
}오류 처리도 한가지 작업이다.
함수는 '한 가지' 작업만 해야 한다. 오류 처리도 이에 속한다. 그러므로 오류를 처리하는 함수는 오류만 처리해야 마땅하다.
Error.java 의존성 자석
public enum Error {
OK,
INVALID,
NO_SUCH,
LOCKED,
OUT_OF_RESOURCES,
WAITING_FOR_EVENT;
}오류 코드를 반환한다 ? 클래스든 열거형 변수든 어디선가 오류 코드를 정의한다는 뜻
오류를 처리하는 곳곳에서 오류코드를 사용한다면 enum class를 쓰게 되는데 이런 클래스는 의존성 자석이므로, 새 오류코드를 추가하거나 변경할 때 코스트가 많이 필요하다. 그러므로 예외를 사용하는 것이 더 안전하다.
반복하지 마라!
중복은 모든 소프트웨어에서 모든 악의 근원이므로 늘 중복을 없애도록 노력해야한다.
구조적 프로그래밍
다익스트라의 구조적 프로그래밍의 원칙을 따르자면 모든 함수와 함수 내 모든 블록에 입구와 출구가 하나여야 된다.
즉, 함수는 return문이 하나여야 한다.
루프 안에서 break나 continue를 사용해선 안되며 goto는 절대로, 절대로 안된다.
그런데 구조적 프로그래밍의 목표와 규율은 공감하지만 함수가 작다면 위 규칙은 별 이익을 제공하지 못한다. 함수가 아주 클 때만 상당한 이익을 제공한다.
그러므로 함수를 작게 만든다면 간혹 return, break, continue를 사용해도 괜찮다. 오히려 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다. 반면 goto 문은 큰 함수에서만 의미가 있으므로, 작은 함수에서는 피해야한다.
함수를 어떻게 짜죠?
처음에는 길고 복잡하고, 들여쓰기 단계나 중복된 루프도 많다.
인수목록도 길지만, 이 코드들을 빠짐없이 테스트하는 단위 테스트 케이스도 만들고, 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 때로는 전체 클래스를 쪼개기도 한다.
처음부터 탁! 짜내지는 않는다.
