🤔 Chapter 5: 구부러지거나 부러지거나

현대의 미친 듯이 빠른 변화 속도를 따라가려면 모든 수단을 동원하여 가능한 한 느슨하고 유연한 코드를 작성해야 한다.

🍭 Topic 28. 결합도 줄이기

결합도가 높으면 이리저리 연결되어 있어서 여러 가지를 동시에 바꿔야 한다. 그래서 바꾸기 더 어려워진다. 여러분의 운명은 둘 중 하나다. 바꿔야 하는 곳을 모두 찾아내느라 시간을 들이거나, 아니면 "딱 하나만" 바꾸고 결합된 다른 것들은 잊은 채 왜 프로그램이 죽는지 고민하느라 시간을 들이거나.

소프트웨어 구조는 유연해야 한다. 그리고 유연하려면 각각의 부품이 다른 부품에 가능한 한 조금만 연결되어야 한다.

Tip 44. 결합도가 낮은 코드가 바꾸기 쉽다.

🥕 열차 사고

public void applyDiscount(customer, order_id, discount) {
  totals = customer
    .orders
    .find(order_id)
    getTotals();

  totals.grandTotal = totals.grandTotal - discount;
  totals.discount = discount;
}

이 코드는 합계까지 다섯 단계의 추상화를 오간다. 결국 최상위 코드가 모든 것을 알아야 한다. 코드를 쓰거나 이해하기 위해 알아야 하는 것이 너무 많다. 설상가상으로 이 코드를 계속 지원하기 위해서 앞으로 바꾸면 안 되는 것도 너무 많다.

Tip 45. 묻지 말고 말하라(Tell, Don't Ask)

이 원칙은 다른 객체의 내부 상태에 따라 판단을 내리고 그 개체를 갱신해서는 안 된다는 것이다. 객체의 내부 상태를 묻는 것으로 인하여 캡슐화의 장점은 완전히 사라지고, 또 그 과정에서 구현에 대한 지식이 코드 여기저기로 퍼져 버린다. 따라서 우리 열차 사고를 고치는 첫 발짝은 할인 처리를 totals 객체에 위임하는 것이다.

public void applyDiscount(customer, order_id, discount) {
  customer
    .orders
    .find(order_id)
    .getTotals()
    .applyDiscount(discount);
}

주문 컬렉션을 가져와서 주문을 찾아서는 안 된다. 고객 객체에서 바로 주문 객체를 얻어 와야 한다.

public void applyDiscount(customer, order_id, discount) {
  customer
    .findOrder(order_id)
    .getTotals()
    .applyDiscount(discount);
}

마찬가지 논리를 주문 객체와 합계에도 적용할 수 있다. 주문 객체를 구현할 때 합계를 별도의 객체에 저장했다는 사실은 왜 온 세상 사람들이 알아야 하겠는가?

public void applyDiscount(customer, order_id, discount) {
  customer
    .findOrder(order_id)
    .applyDiscount(discount);
}

데메테르 법칙(디미터 법칙, Law of Demeter)

Tip 46. 메서스 호출을 역지 말라.

무언가에 접근할 때 "."을 딱 하나만 쓰려고 노력해 보라. "무언가에 접근"한다는 건 중간 변수를 사용하는 경우까지 포함해야 한다.

# 좋지 않은 방식이다.
amount = customer.orders.last().totals().amount;

# 마찬가지로 좋지 않다.
orders = customer.orders;
last = orders.last();
totals = last.totals();
amount = totals.amount;

점 하나 규칙에는 큰 예외가 하나 있다. 엮는 것들이 절대로 바뀌지 않을 것 같다면 이 규칙을 지키지 않아도 된다. 언어에 기본으로 포함된 라이브러리는 아마 꽤 안정적일 것이고, 다음과 같이 써도 될 것이다.

people
  .sort_by { |person| person.age }
  .first(10)
  .map {| person | person.name }

연쇄와 파이프라인

파이프라인은 함수에서 함수로 데이터를 넘겨 가며 데이터를 변환한다. 이런 파이프라인은 메서드 호출로 이루어진 열차 사고와는 다르다. 숨겨진 구현 세부 사항에 의존하지 않기 때문이다.

그렇다고 파이프라인이 결합을 하나도 만들지 않는 것은 아니다. 파이프라인의 함수에서 반환하는 데이터는 반드시 다음 함수가 처리할 수 있는 형식이어야 한다.

🥕 글로벌화의 해악

어디서나 접근할 수 있는 데이터는 교묘하게 애플리케이션 컴포넌트 간의 결합을 만들어 낸다. 전역 데이터 하나하나는 애플리케이션의 모든 메서드에 갑자기 매개 변수가 추가된 것과 같은 효과를 낸다. 전역 데이터는 모든 메서드 안에서 사용할 수 있으니 말이다.

전역 데이터는 여러 가지 방법으로 코드의 결합도를 높인다. 전역 데이터의 구현을 변경할 때 시스템 코드 전체에 영향을 줄 수 있음은 분명하다.

전역 데이터는 코드를 떼어 내는 경우에도 문제를 만든다. 코드를 재사용할 수 있도록 해야 한다는 생각이 코딩 습관이 일부가 되어야 한다. 코드를 재사용할 수 있도록 하려면 깨끗한 인터페이스를 만들고 나머지 코드와의 결합을 없애야 한다. 그래야 나머지 것들이 우르르 딸려 들어오는 일 없이 메서드나 모듈을 뽑아낼 수 있다.

전역 데이터를 쓰는 코드에 단위 테스트를 만들다 보면 이런 문제를 발견하게 된다. 그저 테스트를 실행하려는 것뿐인데 전역 환경을 생성하는 코드를 한참이나 써야 한다.

싱글턴(singleton)도 전역 데이터다

앞에서 우리는 일부러 전역 변수가 아니라 전역 데이터라고 계쏙 말했다. 가끔씩 "이것 보세요. 전역 변수는 없어요. 모두 인스턴스 데이터로 싱글턴이나 전역 모듈 안에 넣었어요."라고 말하는 사람이 있기 때문이다.

여러분의 코드에 있는 것이 싱글턴뿐이더라도, 외부로 노출된 인스턴스 변수가 잔뜩 있는 싱글턴은 여전히 전역 데이터다. 그저 이름이 좀 길어졌을 뿐이다.

외부 리소스도 전역 데이터다

수정 가능한 외부 리소스는 모두 전역 데이터다. 여러분의 애플리케이션이 데이터베이스나 저장소, 파일 시스템, 서비스 API 등을 사용한다면 전역 데이터의 함정에 빠질 위험이 있는 것이다. 여기서도 해법은 반드시 이 리소스들을 여러분이 작성하는 코드로 모두 감싸는 것이다.

Tip 48. 전역적이어야 할 만큼 중요하다면 API로 감싸라.

🥕 상속은 결합을 늘린다

상속으로 다른 클래스의 상태와 행동을 그대로 가져올 수 있다. 상속을 잘못 사용하는 문제는 너무 중요해서 별도로 항목을 만들었다. (항목 31. 상속세 참고)

🥕 결국은 모두 ETC

결합된 코드는 바꾸기 힘들다. 코드의 한 곳을 바꾸면 다른 곳에 여파가 미칠 수 있다. 가끔은 찾기 힘든 곳에 문제가 생기는 바람에 한 달 후에나 서비스에 오류가 발생하면서 문제의 실상이 드러나기도 한다.

직접적으로 아는 것만 다루는 부끄럼쟁이 코드를 계속 유지하라. 그러면 애플리케이션의 결합도를 낮게 유지할 수 있을 것이고, 결과적으로 코드를 바꾸기 쉬워질 것이다.

🍭 Topic 29. 실세계를 갖고 저글링하기

🥕 이벤트

이벤트는 무언가 정보가 있다는 것을 의미한다. 정보는 사용자가 버튼을 클릭하거나, 주가 정보가 갱신될 때처럼 외부에서 올 수 있다.

🥕 유한 상태 기계

실용주의 FSM 해부학

기본적으로 상태 기계는 이벤트를 어떻게 처리할지 정의한 명세일 뿐이다. 정해진 상태들이 있고 그중 하나가 "현재 상태"다. 상태마다 그 상태일 때 의미가 있는 이벤트들을 나열하고, 이벤트별로 시스템의 다음 "현재 상태"를 정의한다.

FSM의 멋진 점은 FSM을 오로지 데이터만으로 표현할 수 있다는 것이다.

행동 추가하기

특정한 상태 이행이 일어날 떄 수행하는 행동을 추가하여 FSM을 더 강력하게 만들 수 있다.

상태 기계는 시작일 뿐

상태 기계는 개발자들에게 저평가되어 있다. 여러분이 상태 기계를 적용할 수 있는 곳을 한번 찾아보면 좋겠다. 하지만 상태 기계가 이벤트와 관련된 모든 문제를 해결하지는 못한다.

🥕 감시자 패턴

감시자 패턴은 이벤트를 발생시키는 쪽인 감시 대상과 이런 이벤트에 관심이 있는 클라이언트인 감시자로 이루어진다.
감시자는 자신이 관심 있는 이벤트를 감시 대상에 등록한다. 보통은 호출될 함수의 참조도 등록할 때 함께 넘긴다. 나중에 해당 이벤트가 발생하면 감시 대상은 등록된 감시자 목록을 보면서 함수들을 일일이 호출한다. 이때, 발생한 이벤트를 감시자 함수의 인자로 넘긴다.

감시 대상을 만드는 코드는 별게 없다. 함수 참조를 리스트에 추가하고, 이벤트가 일어나면 이 함수들을 호출한다.

"감시자-감시 대상" 패턴은 수십 년간 쓰여 왔고, 잘 작동했다. 특히 사용자 인터페이스 시스템에서 널리 쓰이는데, 어떤 상호 작용이 일어났다는 것을 애플리케이션에 콜백으로 알려주는 방식을 사용한다.

하지만 감시자 패턴에는 문제가 하나 있다. 모든 감시자가 감시 대상에 등록을 해야 하기 때문에 결합이 생긴다. 더군다나 일반적으로 감시 대상이 콜백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다.
동기적 처리의 특성상 콜백 실행이 끝날 때까지 감시 대상이 계속 기다려야 하기 때문이다. 이 문제는 다음 전략인 "게시-구독"으로 해결한다.

🥕 게시-구독

게시-구독 혹은 발행-구독 모델은 줄여서 펍섭이라고도 부르며 감시자 패턴을 일반화한 것이다. 동시에 감시자 모델의 결합도를 높이는 문제와 성능 문제도 해결한다.

게시-구독 모델에는 게시자와 구독자가 있고, 이들은 채널로 연결된다. 채널은 별도 코드로 구현되는데, 이런 상세한 구현 내용은 여러분의 코드로부터 숨겨져 있다.

각 채널에는 이름이 있다. 구독자는 관심사를 하나 이상의 채널에 등록하고, 게시자는 채널에 이벤트를 보낸다. 감시자 패턴과는 다르게 게시자와 구독자 사이의 통신은 여러분의 코드 밖에서 일어난다. 아마 비동기적으로 이루어질 것이다.

게시-구독 모델은 추가적인 결합 없이 비동기 이벤트 처리를 구현하기에 아주 좋은 기술이다. 대신 단점은 게시-구독 모델을 아주 많이 사용하는 시스템에서는 현재 어떤 일이 벌어지고 있는지 파악하기가 힘들다는 것이다. 게시자가 메시지를 보내는 것을 확인했더라도 어떤 구독자가 그 메시지를 처리하는지 바로 이어서 볼 수 없다.

🥕 반응형 프로그래밍과 스트림 그리고 이벤트

어떤 셀에 들어 있는 수식에서 다른 셀을 참조하고 있을 때, 참조된 셀의 값을 바꾸면 첫 번째 셀의 값도 바뀐다. 값이 바뀌면 그 값을 사용하는 다른 값이 "반응하는" 것이다.
이런 데이터 수준의 반응성을 구현할 수 있는 프레임워크가 많이 있다. 브라우저 세계에서는 현재 리액트와 뷰의 인기가 가장 높다.

이벤트를 사용하여 코드가 반응하도록 할 수 있다는 것은 명백하다. 하지만 이벤트를 이리저리 연결하는 것도 쉽지많은 않다. 그래서 스트림이 필요하다.

스트림은 이벤트를 일반적인 자료 구조처럼 다룰 수 있게 해 준다. 이벤트의 리스트를 다룬다고 생각하면 된다. 새로운 이벤트가 도착하면 이 리스트가 길어지는 셈이다. 이런 방식이 좋은 이유는 익숙한 방식으로 스트림을 다룰 수 있기 때문이다. 이벤트를 처리하고, 조합하고, 골라내는 등 우리가 아는 온갖 작업을 일반적인 자료 구조와 마찬가지 방법으로 할 수 있다. 심지어 이벤트 스트림과 일반 자료 구조를 조합할 수도 있다. 또한 스트림은 비동기적으로 작동할 수도 있는데, 이벤트가 도착했을 때 여러분의 코드가 이벤트에 응답할 기회를 얻는다.

첫 번째 예제는 두 개의 스트림을 받아서 하나로 엮는다. 그러면 결과로 새로운 스트림이 생기는데, 첫 번재 스트림에서 원소 하나, 두 번째 스트림에서 원소 하나를 가져와서 하나로 묶은 것이 새로운 스트림의 원소가 된다. 다음 예에서 첫 번째 스트림은 그냥 동물 이름 다섯 개다. 두 번째 스트림은 좀 더 흥미로운데, 500ms마다 이벤트를 발생시키는 반복 타이머다. 두 스트림이 집으로 엮였기 때문에 둘 모두에 데이터가 있을 때만 엮인 스트림에 결과가 생긴다. 즉, 출력 스트림은 0.5초에 한 번씩 결과를 내보낸다.

import * as Observable from 'rxjs';
import { logValues } from '../rxcommon/logger.js';

let animals = Observable.of("ant", "bee", "cat", "dog", "elk");
let ticker = Observable.interval(500)

let combined = Observable.zip(animals, ticker);

combined.subscribe(next => logValues(JSON.stringify(next)));

위 코드는 브라우저 창의 목록에 새로운 항목을 추가하는 간단한 로깅 함수를 사용한다. 각 항목에는 프로그램이 시작된 후부터 흐른 시간을 밀리초 단위로 붙인다. 500ms마다 하나씩 스트림에서 이벤트를 받고 있다. 브라우저에서 실행해 보면 로그 항목이 정확하게 0.5초마다 나타난다.

🥕 어디에나 이벤트가 있다

이벤트는 모든 곳에 있다. 몇 가지는 뻔하다. 마우스 버튼을 클릭하거나 타이머가 울린다. 하지만 그렇게 뻔하지 않은 경우도 있다. 누군가가 로그인하거나 파일의 특정 줄이 패턴과 일치한다. 하지만 이벤특 어디서 발생하든 이벤트를 중심으로 공들여 만든 코드는 일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 더 낮다.

🍭 Topic 30. 변환 프로그래밍

모든 프로그램은 데이터를 변환한다. 받은 입력은 출력으로 바꾼다. 하지만 우리는 설계를 고민할 때 변환을 만드는 것에 대해서는 거의 생각하지 않는다. 오직 클래스와 모듈, 자료 구조, 알고리즘, 언어, 프레임워크에 대해서만 걱정할 뿐이다.

우리는 이렇게 코드에만 집중하면 핵심을 놓칠 수 있다고 본다. 프로그램이란 입력을 출력으로 바꾸는 것이라는 사고방식으로 돌아갈 필요가 있다. 이렇게 생각하면 그동안 고민하던 많은 세부 사항이 모두 사라진다. 구조는 명확해지고 더 일관적으로 오류를 처리하게 되어 결합도 대폭 줄어들 것이다.

Tip 49. 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.

🥕 변환 찾기

때에 따라선 요구 사항에서 시작하는 게 변환을 찾는 가장 쉬운 방법이다. 요구 사항에서 입력과 출력이 무엇인지 찾으면 전체 프로그램을 나타내는 함수가 정해진다. 이제 입력을 출력으로 바꿔 가는 단계들을 찾으면 된다. 일종의 하향식 접근 방식이다.

🥕 이것이 왜 그리 대단한가?

word
|> all_subset_longer_than_three_characters()
|> sa_unique_signatures()
|> find_in_dictionary()
|> group_by_length()

요구 사항을 달성하기 위해 필요한 것은 하나로 연결된 변환들뿐이다. 각각은 앞의 변환에서 입력을 받아 처리한 결과를 다음 변환으로 넘겨준다. 이보다 글처럼 읽기 쉬운 코드는 만들기 어려울 것이다.

하지만 더 깊은 의미도 있다. 객체 지향 프로그래밍 경혐이 많다면 반사적으로 데이터를 숨기고, 객체 안에 캡슐화해야 한다고 느낄 것이다. 이런 객체들은 서로 이리저리 이야기하며 서로의 상태를 변경한다. 이런 방식은 결합을 많이 만들어 내고, 이는 결국 객체 지향 시스템이 바꾸기 어려워지는 큰 요인이 된다.

Tip 50. 상태를 쌓아 놓지 말고 전달하라.

변환 모델에서는 이런 사고를 근본적으로 뒤엎는다. 데이터를 전체 시스템 여기저기의 작은 웅덩이에 흩어 놓는 대신, 데이터를 거대한 강으로, 흐름으로 생각하라. 데이터는 기능과 동등해진다. 파이프라인은 코드 -> 데이터 -> 코드 -> 데이터 ...의 연속이다. 데이터는 더 이상 클래스를 정의할 때처럼 특정한 함수들과 묶이지 않는다. 대신 우리 애플리케이션이 입력을 출력으로 바꾸어 나가는 진행 상황을 데이터로 자유롭게 표현할 수 있다. 이 말인즉슨 결합을 대폭 줄일 수 있다는 것이다. 어떤 함수든 매개 변수가 다른 함수의 출력 결과와 맞기만 하면 어디서나 사용하고 또 재사용할 수 있다.

🥕 오류 처리는 어떻게 하나.

여러 가지 방법이 있지만 공통으로 사용하는 기본적인 관례가 하나 있다. 바로 변환 사이에 값을 절대 날것으로 넘기지 않는 것이다. 대신 래퍼 역할을 하는 자료 구조나 타입으로 값을 싸서 넘긴다. 이런 자료 구조나 타입은 안에 들어 있는 값이 유효한지를 추가로 알려 준다. 예를 들어 하스켈에서 이런 래퍼를 Maybe라고 부르고, F#과 스칼라에서는 Option이다.

이런 개념을 어떻게 활용하는지는 언어에 따라 다르다. 하지만 코드 작성 방식은 기본적으로 크게 두 가지로 나뉜다. 오류 검사를 변환 안에서 하는 방식과 변환 바깥에서 하는 방식이다.

🥕 변환은 프로그래밍을 변환한다

코드를 일련의 (중첩된) 변환으로 생각하는 접근 방식은 프로그래밍을 해방시킨다. 익숙해지는 데는 시간이 좀 걸리지만, 일단 습관을 들이면 여러분의 코드가 더 명확해지고, 함수는 짧아지며, 설계는 단순해질 것이다.

🍭 Topic 31. 상속세

객체 지향 언어로 프로그래밍하는가? 상속을 사용하는가?
그렇다면 멈춰라! 아마 여러분에게 필요한 것은 상속이 아닐 것이다.

🥕 약간의 배경지식

우리가 맞닥트린 객체 지향 개발자 세대는 다음 둘 중 하나의 이유로 상속을 사용한다. 타입이 싫어서 아니면 타입이 좋아서.

타입을 싫어하는 이들은 입력하는 글자 수를 줄이기 위해 상속을 쓴다. 상속으로 공통 기능을 기반 클래스에서 자식 클래스로 넘기는 것이다. User 클래스와 Product 클래스는 모두 ActiveRecord::Base의 하위 클래스다.
타입을 좋아하는 이들은 상속으로 클래스 간의 관계를 표현한다. Car는 Vehicle의 일종이다.
안타깝지만 두 가지 상속 모두 문제가 있다.

🥕 코드를 공유하기 위해 상속을 쓸 때의 문제

상속도 일종의 결합이다. 자식 클래스가 부모 클래스, 부모의 부모, 또 그 부모에게 연결되는 것은 물론이요, 자식 클래스를 사용하는 코드도 이 클래스의 모든 조상과 얽히게 된다. 다음 예를 보자.

class Vehicle
  def initialize
    @speed = 0
  end
  def stop
    @speed = 0
  end
  def move_at(speed)
    @speed = speed
  end
end

class Car < Vehicle
  def info
    "#{@speed}의 속도로 주행 중인 차입니다."
  end
end

# 최상위 코드
my_car = Car.new
my_car.move_at(30)

최상위 코드에서 my_car.move_at을 호출하면 Car의 부모인 Vehicle의 메서드가 수행된다.
Vehicle 담당 프로그래머사 API를 바꾼다고 해 보자. move_at은 set_velocity로, 인스턴스 변수 @speed는 @velocity로 바꾸었다.
API가 바뀌면 Vehicle 클래스를 사용하는 클라이언트가 작동하지 않는 것은 당연하다. 하지만 앞에서 본 최상위 코드의 담당자는 코드가 작동하지 않아 깜짝 놀랄 것이다. 자신은 Car를 쓰고 있다고만 생각하기 때문이다. Car 클래스가 내부적으로 어떻게 구현되어 있는지는 사용자가 신경 쓸 부분이 아니지만, Car를 사용하는 코드까지 함꼐 망가지고 만다.

비슷하게 인스턴스 변수의 이름은 온전히 내부 구현의 세부 사항이다. 하지만 Vehicle이 변수 이름을 바꾸자 어느새 Car가 망가졌다.
결합이 너무 많다.

🥕 타입을 정의하기 위해 상속을 쓸 때의 문제

클래스 사이의 아주 작은 미묘한 차이까지 잡아내서 표현하기 위해 계층 위에 계층을 덧붙이다 보면, 클래스 계층도는 순식간에 벽면 전체를 덮는 괴물로 자라난다. 이런 복잡도는 애플리케이션을 더 취약하게 만든다. 변경 사항이 위나 아래로 여러 단계에 걸쳐 영향을 미칠 수 있기 때문이다.

Tip 51. 상속세를 내지 말라.

🥕 더 나은 대안

더는 상속을 쓸 필요가 없게 해 주는 세 가지 기법을 소개하겠다.

• 인터페이스와 프로토콜
• 위임 믹스인과 트레이트

인터페이스와 프로토콜

대부분의 객체 지향 언어는 클래스가 특정한 동작을 구현한다고 지정할 수 있다. 여러 동작을 지정할 수도 있는데, 예를 들어 Car 클래스가 Drivable 동작과 Locatable 동작을 구현한다고 할 수 있다. 문법은 언어마다 상이한다. 자바에서는 다음과 같다.

public class Car implements Drivable, Locatable {
  // Car 클래스의 코드, 이 코드는 Drivable과 Locatable이
  // 요구하는 기능을 모두 구현해야 한다.
}

Drivable과 Locatable 같은 자바에서는 인터페이스라고 부른다. 프로토콜이라고 부르는 언어도 있고 트레이트라고 부르는 언어도 있다.
인터페이스는 다음과 같이 정의한다.

public interface Drivable {
  double getSpeed();
  void stop();
}

public interface Locatable {
  Coordinate getLocation();
  boolean locationIsValid();
}

이 선언들은 아무런 코드도 만들지 않는다. 그냥 Drivable을 구현하는 클래스는 모두 getSpeed와 stop 두 개의 메서드를 구현해야 한다고 지시할 뿐이다. Locatable한 클래스는 getLocation과 locationIsValid를 구현해야 한다.

인터페이스나 프로토콜이 강력한 까닭은 이들을 타입으로 사용할 수 있고, 해당 인터페이스를 구현하는 클래스라면 무엇이든 그 타입과 호환되기 떄문이다. 만약 Car와 Phone이 모두 Locatable 인터페이스를 구현했다면 둘 다 Locatable한 것을 담는 리스트에 넣을 수 있다.

List<Locatable> items = new ArrayList<>();

items.add(new Car(...));
items.add(new Phone(...));
items.add(new Car(...));

이 리스트를 처리할 때는 모든 원소가 getLocation과 locationIsValid를 구현했다는 것을 알고 있으므로 이를 활용할 수 있다.

void printLocation(Locatable item) {
  if (item.locationIsValid()) {
    print(item.getLocation().asString());
  }
}

// ...

items.forEach(printLocation);

Tip 52. 다형성은 인터페이스로 표현하는 것이 좋다.

인터페이스와 프로토콜은 상속 없이도 다형성을 가져다준다.

위임

상속은 개발자들이 점점 더 메서드가 많은 클래스를 만들도록 유도한다. 부모 클래스에 메서드가 20개 있으면 하위 클래스는 그중 딱 두 개만 사용하고 싶더라도 필요 없는 18개의 메서드까지 함께 따라와서 자리를 차지하고 호출되기만을 기다린다. 클래스가 자신의 인터페이스를 제어할 수 없게 되는 것이다.

class Account < PersistenceBaseClass
end

이제 Account 클래스는 영속성 클래스 API를 모두 달고 다녀야 한다. 이러는 대신 다음과 같이 위이믈 사용하면 어떨지 생각해 보라.

class Account
  def initialize(. . .)
    @repo = Persister.for(self)
  end

  def save
    @repo.save()
  end
end

이제 Account 클래스는 클라이언트에게 프레임워크의 API를 전혀 노출하지 않는다. 결합이 사라진 것이다. 그뿐 아니라 우리는 더 이상 우리가 사용하는 프레임워크를 API에 제약을 받지 않고, 필요한 API를 마음대로 만들 수 있다. 클라이언트가 우리가 추가한 인터페이스는 건너뛰고 상속받는 영속성 API를 사용할 위험이 있었다. 이제는 우리가 모든 것을 제어한다.

Tip 53. 서비스에 위임하라. Has-A가 Is-A보다 낫다.

Account가 왜 영속성에 관해 알아야하겠는가? Account 클래스는 계정에 관한 비즈니스 규칙을 적용하는 것이 원래 할 일 아닌가?

class Account
  # 계정에 관련된 일만 함
end

class AccountRecord
  # Account를 감싸서 객체를 저장하거나 불러오는 기능을 더함
end

이제는 진짜 결합이 사라졌다. 하지만 여기에는 계산서가 붙는다. 코드를 더 많이 써야 한다. 그중 일부는 틀에 박힌 코드일 것이다. 예를 들어 아마 모든 레코드 클래스에 "찾기" 메서드가 필요할 테니 일일이 메서드를 추가해 주어야 한다.

다행히도 믹스인과 트레이트가 하는 일이 바로 이것이다.

믹스인, 트레이트, 카테고리, 프로토콜 확장 등

믹스인의 기본 발상은 단순하다. 클래스나 객체에 상속을 사용하지 않고 새로운 기능을 추가하여 확장하고 싶다. 그래서 일련의 함수들을 만들고, 여기에 이름을 붙인 다음, 이것으로 어떻게든 클래스나 객체를 확장한다. 이 시점에서 여러분은 기존 클래스와 그에 덧붙이는 믹스인의 동작을 모두 합한 새로운 클래스나 객체를 만든 것이다. 대부분의 경우 확장하려는 클래스의 소스 코드에 접근할 수 없더라도 이런 확장을 만들 수 있다.

이 기능을 구현했을 때 할 수 있는 일, 바로 기존의 것과 새로운 것의 기능 집합을 합치는 것이다.

앞의 AccountRecord 예제에서 AccountRecord가 계정과 영속성 프레임워크를 모두 알아야 한다고 하고선 멈추었다. 영속성 계층에서 제공하는 메서드 중 바깥세상에 노출해야 하는 것들을 일일이 위임하는 일도 해야 한다.

믹스인이 대안을 제시한다. 예를 들어 영속성 계층의 찾기 메서드 세 가지 중 두 가지만을 구현하는 믹스인을 만든다고 하자. 그런 다음 AccountRecord에 이 믹스인을 추가할 수 있다. 그리고 Account 말고 다른 객체를 저장하기 위해 새로운 클래스를 만들 때도 이 믹스인을 사용할 수 있다.

mixin CommonFinders {
  def find(id) { ... }
  def findAll() { ... }
}

class AccountRecord extends BasicRecord with CommonFinders
class OrderRecord extends BasicRecord with CommonFinders

여기서 더 발전시킬 수 있다. 예를 들어 우리 시스템에 나쁜 데이터가 끼어 들어오는 것을 막아야 하므로 당연히 비즈니스 객체에 검증 코드가 필요하다.

class AccountForCustomer extends Account with AccountValidations, AccountCustomerValidations
class AccountForAdmin extends Account with AccountValidations, AccountCustomerValidations

여기서는 두 파생 클래스 모두 계정 객체에 공통으로 적용해야 할 검증을 포함하고 있다. 고객용 클래스인 AccountForCustomer는 고객이 사용하는 API에 적합한 검증을 추가로 포함하고 있고, 관리자용 클래스인 AccountForAdmin은 아마 제한이 더 느슨할 관리자용 검증을 추가로 포함하고 있다.
이제 AccountForCustomer와 AccountForAdmin의 인스턴스를 이리저리 넘길때 자동으로 정확한 검증을 수행하리라 보장할 수 있다.

Tip 54. 믹스인으로 기능을 공유하라.

🥕 상속이 답인 경우는 드물다

타입 정보를 공유하고 싶은 건지, 기능을 더하고 싶은 건지, 메서드를 공유하고 싶은 건지에 따라 다르다. 프로그래밍의 다른 모든 것과 마찬가지로 여러분의 목표는 의도를 가장 잘 드러내는 기법을 사용하는 것이어야 한다.
그리고 정글 전체를 끌어들이지 않도록 조심하라.

🍭 Topic 32. 설정

애플리케이션이 출시된 이후 바뀔 수도 있는 값에 코드가 의존하고 있다면 그 값을 애플리케이션 외부에서 관리하라. 여러분의 애플리케이션이 여러 환경에서 혹은 여러 고객을 위해 실행된다면 특정 환경이나 특정 고객에게 한정된 값을 애플리케이션 외부에서 관리하라. 이렇게 하면 여러분은 애플리케이션을 조정할 수 있게 된다. 코드가 자신이 실행되는 환경에 적응하는 것이다.

Tip 55. 외부 설정으로 애플리케이션을 조정할 수 있게 하라.

일반적으로 설정 데이터 안에 넣는 것은 다음과 같다.

• 데이터베이스나 외부 API 같은 외부 서비스의 인증 정보
• 로그 레벨과 로그 저장 위치
• 애플리케이션이 사용하는 포트 번호, IP 주소, 기계나 클러스터 이름
• 특정 실행 환경에만 적용되는 검증 매개 변수
• 외부에서 지정하는 매개 변수. 예를 들어 배송비
• 지역에 따른 세부 서식
• 라이선스 키

기본적으로 나중에 바뀌리라 알고 있는 것, 소스 코드 본체 바깥에 표현할 수 있는 것을 찾아라. 그리고 설정 더미에 던져 넣어라.

🥕 정적 설정

어떤 형태를 사용하든 여러분의 애플리케이션에서는 설정을 자료 구조 형태로 불러온다. 보통 처음 애플리케이션을 시작할 때 읽어올 것이다. 흔히 자료 구조를 전역에서 접근할 수 있도록 하는데, 코드의 어느 부분에서든 설정 정보에 쉽게 접근할 수 있도록 하기 위해서일 것이다.

우리는 그렇게 하지 않기를 추천한다. 대신 설정 정보를 (얇은) API 뒤로 숨겨라. 그러면 설정을 표현하는 세부 사항으로부터 여러분의 코드를 떼어 놓을 수 있다.

🥕 서비스형 설정

설정 정보를 애플리케이션 외부에서 관리하는 것은 동일하지만, 일반 파일이나 데이터베이스가 아니라 서비스 API 뒤에서 관리하는 것을 선호한다. 서비스형 설정에는 몇 가지 장점이 있다.

• 여러 애플리케이션이 설정 정보를 공유할 수 있다.
• 여러 인스턴스에 걸쳐서 전체 설정을 한번에 바꿀 수 있다.
• 설정 데이터를 전용 UI로 관리할 수 있다.
• 설정 데이터를 동적으로 계속 바꿀 수 있다.

🥕 도도 코드를 작성하지 말라

외부 설정을 사용하지 않는다면 코드는 적응성이나 유연성을 어느 정도 포기해야만 한다. 이것이 얼마나 나쁜 일일까? 글쎄, 프로그램의 세계에서 잠시 벗어나 실제 세상의 이야기를 하자면 환경에 적응하지 못하는 생물은 멸종한다.
여러분의 프로젝트가, 여러분의 경력이 도도의 전철을 밟지 않도록 하라.