TIL

07 객체 분해

사람의 기억은 단기 기억과 장기 기억으로 분류 가능
- 장기 기억엔 직접 접근이 불가능하고 먼저 단기 영역으로 옮긴 후 처리해야 한다.
- 단기 기억은 장기 기억에 비해 정보를 보관할 수 있는 속도와 공간 측면에서 모두 제약을 받는다.
사람은 문제를 해결할 때 단기 기억을 사용한다.
- 문제 해결에 필요한 요수 수가 단기 기억 용량을 초과하면 인지 부조화가 일어나 문제 해결 능력이 떨어진다.
인지 부조화를 방지하는 방법은 단기 기억에 보관할 정보 양을 조절하는 것이다.
- 문제 해결에 필요한 핵심만 남기는 ‘추상화’
- 큰 문제를 해결 가능한 작은 문제로 나누는 ‘분해’

01 프로시저 추상화와 데이터 추상화

현대 프로그래밍 언어를 특징 짓는 중요한 추상화 메커니즘
- 프로시저 추상화 - 소프트웨어가 무엇을 해야 하는지를 추상화
- 데이터 추상화 - 소프트웨어가 무엇을 알아야 하는지 추상화
프로시저 중심으로 시스템을 분해하기로 결정했다면 기능 분해를 하는 것이다.
- 알고리즘 분해라고 부르기도 한다.
데이터를 중심으로 시스템을 분해하기로 결정했다면 두 가지 중 하나를 선택해야 한다.
- 추상 데이터 타입 - 타입을 추상화
- 객체지향 - 프로시저를 추상화
프로그래밍 언어 관점에서 객체지향
- 데이터를 중심으로 데이터 추상화와 프로시저 추상화를 통합한 객체를 이용해 시스템을 분해하는 방법
- 이를 구현하기 위해 클래스라는 도구를 이용

02 프로시저 추상화와 기능 분해

메인 함수로서의 시스템

기능 분해 관점에서 추상화 단위는 프로시저이며 시스템은 프로시저를 단위로 분해된다.
기능 분해 관점에서 추강화 단위는 프로시저
- 프로시저는 반복되거나 유사하게 실행되는 작업들을 한 장소에 모아놓음으로써 로직을 재사용하고 중복을 방지할 수 있는 추상화 방법
- 프로시저만 알면 구현을 모르더라도 사용할 수 있기에 추상화라고 부른다. (정보은닉)
전통적 기능 분해 방법은 하향식 접근법을 따른다.
- 시스템을 구성하는 최상위 기능을 정의하고, 이 기능을 좀 더 작은 단계의 하위 기능으로 분해해 나가는 방법
- 분해는 세분화된 마지막 하위 기능이 프로그래밍 언어로 구현 가능한 수준이 될 때까지 계속된다.
- 각 단계는 바로 위 단계보다 더 구체적이어야 한다.

급여 관리 시스템

급여 관리 시스템 요구 사항
- 연초에 회사는 매달 지급해야하는 기본급을 직원과 협의하여 12개월 동안 동일하게 지급한다.
- 급여 지급 시 소득세율에 따라 일정 금액의 세금을 공제한다.
  - 급여 = 기본급 - (기본급 * 소득세율)
급여 관리 시스템 구현을 위해 기능 분해 방법을 이용하기 위해 최상위 문장을 기술한다.
- 직원의 급여를 계산한다.
- 위 최상위 문장은 급여 관리 시스템을 시작하는 메인 프로시저로 구현될 것이다.

기능 분해 방법에 따라 이 프로시저를 더 세분화된 절차로 구체화해야 한다.

  직원의 급여를 계산한다.
      사용자로부터 소득세율을 입력받는다.
          "세율을 입력하세오: "라는 문장을 화면에 출력한다.
          키보드를 통해 세율을 입력받는다.
      직원의 급여를 계산한다.
          전역 변수에 저장된 직원의 기본급 정보를 얻는다.
          급여를 계산한다.
      양식에 맞게 결과를 출력한다.
          "이름: {직원명}, 급여: {계산된 금액}" 형식에 따라 출력 문자열을 생성한다.

각 정제 단계는 이전 문장의 추상화 수준을 감소시켜야 한다.
더 정제 가능한 문장이 존재하면 동일한 과정을 거쳐 구현 가능할 정도로 충분히 저수준 문장이 될 때까지 분해한다.

급여 관리 시스템을 입력을 받아 출력을 생성하는 하나의 메인 함수로 간주하고 기능 분해를 시작했다.
- 입력 정보는 직원 정보와 소득세율이며 출력은 계산된 급여 정보
전통적 하향식 기능 분해 방식은 유지보수에서 다양한 문제를 야기한다.

급여 관리 시스템 구현

구현 예제는 루비를 사용한다.
직원의 급여를 계산한다.라는 최상위 문장은 아래 함수 정의로 바꿀 수 있다.
```
  def main(name)
  end
```

이제 첫 번째 하위 단계의 세분화 내용을 이용해 함수 내부를 채울 차례다.

  직원의 급여를 계산한다.
      사용자로부터 소득세율을 입력받는다.
    
      직원의 급여를 계산한다.
    
      양식에 맞게 결과를 출력한다.

  def main(name)
    taxRate = getTaxRate()
    pay = calculatePayFor(name, taxRate)
    puts(describeResult(name, pay))
  end

그 다음 하위 단계 세분화 내용에 맞게 각 함수를 구현해 나가면서 기능을 구현할 수 있다.
하향식 분해 방식으로 설계한 시스템은 메인 함수를 루트로 하는 트리로 표현할 수 있다.

하향식 기능 분해의 문제점

시스템은 하나의 메인 함수로 구성돼 있지 않다.
- 시스템은 시간이 지남에 따라 새로운 기능을 추가하게 된다.
- 어느 시점에 이르면 유일 메인 함수라는 개념은 없어지고 여러 동등 수준의 함수 집합으로 성장하게 된다.
- 하나의 알고리즘을 구현하거나 배치 처리 구현에는 적합하지만 현대적인 상호작용 시스템에는 적합하지 않다.
기능 추가나 요구사항 변경으로 인해 메인 함수를 빈번하게 수정해야 한다.
- 시스템에 여러 정상이 존재하기에 새로운 기능을 추가할 때마다 매번 메인 함수를 수정해야 한다.
- 새 함수의 적절 위치를 확보해야 하기 때문에 메인 함수 구조가 급격히 변경될 수밖에 없다.
- 기존 코드의 빈번한 수정으로 버그 발생 확률이 높아진다.
비즈니스 로직이 사용자 인터페이스와 강하게 결합된다.
- 로직 설계 초기 단계부터 입력 방법과 출력 양식을 함께 고민하도록 강요한다.
- 문제는 비즈니스 로직과 사용자 인터페이스 변경 빈도가 다르다는 것
하향식 분해는 너무 이른 시기에 함수들의 실행 순서를 고정시키기 때문에 유연성과 재사용성이 저하된다.
- 하향식 분해 과정은 설계 시작 시점부터 시스템이 무엇을 해야 하는지가 아니라 어떻게 동작해야 하는지에 집중하도록 만든다. (설계 처음부터 구현을 염두에 둠)
- 함수들의 실행 순서를 미리 결정하지 않는 한 기능 분해를 진행할 수 없다.
- 문제는 중요한 설계 걸정사항인 함수의 제어 구조가 빈번한 변경 대상이라는 점
- 하향식 설계와 관련된 모든 문제 원인은 결합도이다.
데이터 형식이 변경될 경우 파급 효과를 예측할 수 없다.
- 어떤 데이터를 어떤 함수가 사용하고 있는지를 추적하기 어렵다.
- 즉 데이터 변경으로 인해 어떤 함수가 영향을 받을지 예상하기 어렵다.

03 모듈

정보 은닉과 모듈

시스템 변경을 관리하는 기본 전략
- 함께 변경되는 부분을 하나의 구현 단위로 묶고 퍼블릭 인터페이스를 통해서만 접근하도록 하기
- 즉 기능 기반의 시스템 분해가 아닌 변경 영향에 맞춰 시스템을 분해해야 한다.
정보 은닉
- 시스템을 모듈 단위로 분해하기 위한 기본 원리
- 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야 한다는 것이 핵심
모듈과 기능 분해는 상호 베타적 관계가 아니다.
- 시스템을 모듈로 분해한 후에는 각 모듈 내부에는 기능 분해를 적용할 수 있다.
모듈은 다음 두 가지 비밀을 감춰야 한다.
- 복잡성: 모듈이 너무 복잡하면 이해하고 사용하기 어렵다. 외부에 모듈을 추상화할 수 있는 간단한 인터페이스를 제공해서 모듈 복잡도를 낮춘다.
- 변경 가능성: 변경 발생 시 하나의 모듈만 수정하면 되도록 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공한다.
시스템의 가장 일반적인 비밀은 데이터이지만 정보 은닉에서 비밀이 반드시 데이터일 필요는 없다.
- 복잡한 로직이나 변경 가능성이 큰 자료 구조일 수도 있다.
자바에서 모듈의 개념은 패키지를 이용해 구현 가능하다.

모듈 장점과 한계

모듈은 변경의 정도에 따라 시스템을 분해한다.
- 모듈 내부는 높은 응집도를 유지
- 모듈 사이에는 퍼블릭 인터페이스를 통해서만 통신
모듈의 장점
- 모듈 내부 변수가 변경되더라도 모듈 내부에만 영향을 미친다.
  - 모듈 내부에 정의된 변수를 직접 참조하는 코드 위치를 모듈 내부로 제한할 수 있다.
- 비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다.
- 전역 변수와 전역 함수를 제거함으로써 네임스페이스 오염을 방지한다.
  - 변수와 함수를 모듈 내부에 포함시키기 때문에 다른 모듈에서도 동일한 이름을 사용할 수 있게 된다.
  - 이름 충돌 위험 완화
모듈의 가장 큰 단점은 인스턴스의 개념을 제공하지 않는다는 점
- 좀 더 높은 수준의 추상화를 위해서는 추상 데이터 타입이 필요하다.

04 데이터 추상화와 추상 데이터 타입

추상 데이터 타입

프로그래밍 언어에서의 타입
- 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미
- 타입은 값에 대해 수행될 수 있는 연산의 집합을 결정하기에 값이 어떻게 행동할 것이라는 것을 예측할 수 있게 한다.
프로그래밍 언어에는 다양한 형태의 내장 타입(built-in type)을 제공한다.
- 기능 분해 시대에는 적은 수의 내장 타입만 제공하던 언어가 많았고 새 타입 추가는 제한적이었다.
이러한 프로시저 추상화를 보완하기 위해 데이터 추상화 개념이 등장했다.
추상화 데이터 타입 구현을 위해선 프로그래밍 언어의 지원이 필요하다.
- 타입 정의를 선언할 수 있어야 한다.
- 타입 인스턴스를 다루기 위해 사용할 수 있는 오퍼레이션 집합을 정의할 수 있어야 한다.
- 제공된 오퍼레이션을 통해서만 조작할 수 있도록 데이터를 외부로부터 보호할 수 있어야 한다.
- 타입에 대해 여러 개의 인스턴스를 생성할 수 있어야 한다.
추상 데이터 타입 기본 의도는 내장 타입처럼 동작하는 사용자 정의 타입을 추가할 수 있게 하는 것
- 클래스는 추상 데이터 타입인가?

05 클래스

클래스는 추상 데이터 타입인가?

대부분의 프로그래밍 서적은 클래스 = 추상 데이터 타입으로 설명한다.
- 둘 다 데이터 추상화를 기반으로 시스템을 분해하기에 틀린 것만은 아니다.
- 두 메커니즘 모두 객체 내부 속성에 접근할 수 없으며 오직 퍼블릭 인터페이스를 통해서만 외부와 의사소통할 수 있다.
그러나 명확한 의미에서 추상 데이터 타입과 클래스는 다르다.
- 핵심적인 차이는 클래스는 상속과 다형성을 지원하지만 추상 데이터 타입은 지원하지 못한다.
- 상속과 다형성을 지원하지 않는 추상 데이터 타입 기반 패러다임을 객체지향이 아닌 ‘객체기반 프로그래밍’이라 부르기도 한다.
윌리엄 쿡은 객체지향과 추상 데이터 타입 간의 차이를 프로그래밍 언어 관점에서 설명한다.
- 추상 데이터 타입은 타입을 추상화한 것
- 클래스는 절차를 추상화한 것
추상 데이터 타입은 오퍼레이션을 기준으로 타입을 통합하는 데이터 추상화 기법이다.
- 상속, 다형성 개념이 없기에 하나의 개념에 대한 여러 종류에 대한 동작을 정의할 수 없다.
- ex) 직원 타입에게 정규 직원과 아르바이트 직원에 따라 급여 계산 로직이 다르다면 추상 데이터 타입에선 이를 구분할 수 없다.
- ex) 추상 데이터 타입을 사용하면 오퍼레이션을 호출할 수는 있지만 정규 직원이나 아르바이트 직원이 있다는 사실은 알 수 없다.
객체지향에선 타입을 기준으로 오퍼레이션을 묶는다.
- 여러 타입을 명시적으로 정의하고 오퍼레이션의 실행 절차를 여러 타입에 분배한다.
- ex) 하나의 오퍼레이션을 정규 직원, 아르바이트 직원 각 클래스를 정의하고 적절하게 구현
- 상속과 다형성을 통해 클라이언트 관점에서 인스턴스는 동일하게 보이지만 실제 내부에서 실행되는 절차는 다르다.
- 즉 객체지향은 절차 추상화이다.

변경을 기준으로 선택하라

클래스를 사용하고 있더라도 타입을 기준으로 절차를 추상화하지 않았다면 그것은 객체지향 분해가 아니다.
클래스가 추상 데이터 타입 개념을 따르는지 확인하는 간단한 방법은 클래스 내부에 인스턴스 타입을 표현하는 변수가 있는지 살펴보는 것이다.
- ex) Employees 클래스에 hourly라는 직원 유형을 정의한다면 객체지향을 위반했다고 볼 수 있다.
객체지향에서는 타입 변수를 이용한 조건문을 다형성으로 대체한다.
- 조건문 사용을 기피하는 이유 역시 변경 때문이다.
개방-폐쇄 원칙 (Open-Closed Principle, OCP)
- 기존 코드에 영향을 미치지 않고 새로운 객체 유형과 행위를 추가할 수 있는 객체지향 특성
설계는 변경과 관련된 것이며 설계 유용성은 변경 방향성과 발생 빈도에 따라 결정된다.
- 변경의 압력이 ‘타입 추가’라면 객체지향이 적합하다. 새로운 클래스를 상속 계층에 추가하기만 하면 되기 때문이다.
- 변경의 압력이 ‘오퍼레이션 추가’라면 추상 데이터 타입이 적절하다. 전체 타입에 대한 구현 코드가 하나의 구현체에 내포되어 있기에 오퍼레이션 추가가 간단하다.

협력이 중요하다.

협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션 구현 방식을 타입별로 분배하는 것은 올바른 접근법이 아니다.
객체가 참여할 협력을 결정하고 협력에 필요한 책임을 수행하기 위해 어떤 객체가 필요한지에 관해 고민하라.
타입 계층과 다형성은 협력이라는 문맥에서 책임 수행 방법에 관한 고민의 결과물이어야 하며 그 자체가 목적이 되어서는 안된다.