🌈 Chapter 7: 객체 분해

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

• 현대적인 프로그래밍 언어를 특징 짓는 중요한 두 가지 추상화 메커니즘은 프로시저 추상화와 데이터 추상화이다.
• 프로시저 추상화는 소프트웨어가 무엇을 해야하는지를 추상화한다.
• 데이터 추상화는 소프트웨어가 무엇을 알아야 하는지를 추상화한다.
• 소프트웨어는 데이터를 이용해 정보를 표현하고 프로시저를 이용해 데이터를 조작한다.
• 프로그래밍 패러다임이란 적절한 추상화의 윤곽을 따라 시스템을 어떤 식으로 나눌 것인지를 결정하는 원칙과 방법의 집합이다.
• 시스템을 분해하는 방법을 결정하려면 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 먼저 결정해야 한다.
• 프로시저 추상화를 중심으로 결정했다면 기능 분해의 길로 들어서는 것으로 알고리즘 분해라고 부른다.
• 데이터 추상화 중심으로 결정했다면 다시 두 가지로 나누는데 하나는 타입을 추상화 하는 것이고 다른 하나는 데이터를 중심으로 프로시저를 추상화하는 것이다. 여기서 전자를 추상 데이터 타입이라고 부르고 후자를 객체지향이라고 부른다.

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

🎈 메인 함수로서의 시스템

• 기능은 오랜 시간 동안 시스템을 분해하기 위한 기준으로 사용됐으며, 이 같은 시스템 분해 방식을 알고리즘 분해 또는 기능 분해라고 부른다.
• 기능 분해의 관점에서 추상화의 단위는 프로시저이며 시스템은 프로시저를 단위로 분해된다.
• 프로시저는 반복적으로 실행되거나 거의 유사하게 실행되는 작업들을 하나의 장소에 모아놓음으로써 로직을 재사용하고 중복을 방지할 수 있는 추상화 방법이다.
• 프로시저를 추상화라고 부르는 이유는 내부의 상세한 구현 내용을 모르더라도 인터페이스만 알면 프로시저를 사용할 수 있기 때문이다.
• 전통적인 기능 분해 방법은 하향식 접근법을 따른다. 하향식 접근법이란 시스템을 구성하는 가장 최상위 기능을 정의하고, 이 최상위 기능을 좀더 작은 단계의 하위 기능을 분해해 나가는 방법이다. 각 세분화 단계는 자신의 바로 상위 기능보다 덜 추상적이어야 한다.

🎈 급여 관리 시스템

• 예제로 연초에 회사는 매달 지급해야 하는 기본급에 대해 직원과 협의하며 이 금액을 12개월 동안 동일하게 직원들에게 지급한다.
• 회사는 급여 지급 시 소득 세율에 따라 일정 금액의 세금을 공제한다. 공식은 다음과 같다.

급여 = 기본급 - (기본급 * 소득세율)

• 기능 분해 방법은 하향식 접근법을 따르기 때문에 최상위의 추상적인 함수 정의는 시스템의 기능을 표현하는 하나의 문장으로 나타낸다.
• 아래 문장은 최상위 문장을 기술한다. 즉, 다음 문장은 급여 관리 시스템을 시작하는 메인 프로시저로 구현될 것이다.

직원의 급여를 계산한다.

• 이제 더 세분화된 절체로 구체화 한다.

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

• 각 정제 단계는 이전 문장의 추상화 수준을 감소시켜야 하고 모든 문젱이 정제 과정을 거치면서 하나 이상의 좀 더 단순하고 구체적인 문장들의 조합으로 분해돼야 한다.

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

• 기능 분해 방법에서는 기능을 중심으로 필요한 데이터를 결정한다. 기능이 우선이고 데이터는 기능의 뒤를 따른다.
• 기능 분해를 위한 하향식 접근법은 먼저 필요한 기능을 생각하고 이 기능을 분해하고 정제하는 과정에서 필요한 데이터의 종류와 저장 방식을 식별한다.

🎈 하향식 기능 분해의 문제점

• 하향식 접근법과 기능 분해가 가지는 근본적인 문제점은 변경에 취약한 설계를 낳는다.

🐶 하나의 메인 함수라는 비현실적인 아이디어

• 시간이 지나면 사용자를 만족시키기 위해 새로운 요구사항을 도출해나가면서 지속적으로 새로운 기능을 추가하게 된다.
• 이것은 시스템이 오직 하나의 메인 함수만으로 구현된다는 개념과는 완전히 모순된다.
• 대부분의 경우에 추가되는 기능은 최초에 배포된 메인 함수의 일부가 아닐 것이다.

🐶 메인 함수의 빈번한 재설계

• 시스템 안에는 여러 개의 정상이 존재하기 때문에 결과적으로 하나의 메인 함수를 유일한 정상으로 간주하는 하향식 기능 분해의 경우에는 새로운 기능을 추기할 때마다 매번 메인 함수를 수정해야 한다.
• 기존 코드를 수정하는 것은 항상 새로운 버그를 만들어낼 확률을 높인다.
• 결과적으로 기존 코드의 빈번한 수정으로 인한 버그 발생 확률이 높아지기 때문에 시스템은 변경에 취약해질 수밖에 없다.

🐶 비즈니스 로직과 사용자 인터페이스의 결합

• 하향식 접근법은 비즈니스 로직을 설계하는 초기 단계부터 입력 방법과 출력 양식을 함께 고민하도록 강요한다.
• 비즈니스 로직과 사용자 인터페이스 로직이 밀접하게 결합된다.
• 문제는 비즈니스 로직과 사용자 인터페이스가 변경되는 빈도가 다르다는 것으로 사용자 인터페이스는 시스템 내에서 가장 자주 변경되는 부분이다. 반면 비즈니스 로직은 사용자 인터페이스에 비해 변경이 적게 발생한다. 때문에 사용자 인터페이스를 변경하는 경우 비즈니스 로직까지 변경에 영향을 미친다. 따라서 하향식 접근법은 근본적으로 변경에 불안정한 아키텍처를 낳는다.

🐶 성급하게 결정된 실행 순서

• 하향식으로 기능을 분해하는 과정은 하나의 함수를 더 작은 함수로 분해하고, 분해된 함수들의 실행 순서를 결정하는 작업으로 요약할 수 있다. 이것은 설계를 시작하는 시점부터 시스템이 무엇을 해야 하는지가 아니라 어떻게 동작해야 하는지에 집중하도록 만든다.
• 하향식 접근법의 설계는 처음부터 구현에 염두에 두기 때문에 자연스럽게 함수들의 실행 순서를 정의하는 시간 제약을 강조한다.
• 실행 순서나 조건, 반복과 같은 제어 구조를 미리 결정하지 않고는 분해를 진행할 수 없기 때문에 기능 분해 방식은 중앙집중 제어 스타일의 형태를 띨 수밖에 없다.
• 문제는 중요한 설계 결정사항인 함수의 제어 구조가 빈번한 변경의 대상이라는 점이다. 기능이 추가되거나 변경될 때마다 초기에 결정된 함수들의 제어 구조가 올바르지 않다는 것이 판명된다. 결과적으로 기능을 추가하거나 변경하는 작업은 매번 기존에 결졍된 함수의 제어구조를 변경하도록 만든다.
• 하향식 접근법을 통해 분해한 함수들은 재사용하기도 어려운데 모든 함수는 상위 함수를 분해하는 과정에서 필요에 따라 식별되며, 그에 따라 상위 함수가 강요하는 문맥 안에서만 의미를 가지기 때문이다.
• 하향식 설계와 관련된 모든 문제의 원인은 결합도이다. 함수는 상위 함수가 강요하는 문맥에 강하게 결합된다. 다른 함수들과 시간적으로 강하게 결합돼 있다.

🐶 데이터 변경으로 인한 파급효과

• 하향식 기능 분해의 가장 큰 문제점은 어떤 데이터를 어떤 함수가 사용하고 있는지를 추적하기 어렵다는 것이다. 따라서 데이터 변경으로 인해 어떤 함수가 영향을 받을지 예상하기 어렵다.
• 이것은 의존성과 결합도의 문제이고 데스트의 문제이기도 하다.
• 데이터 변경으로 인한 영향을 최소화하려면 데이터와 함께 변경되는 부분과 그렇지 않은 부분을 명확하게 분리해야 한다. 이를 위해 데이터와 함께 변경되는 부분을 하나의 구현 단위로 묶고 외부에서는 제공되는 함수만 이용해 데이터에 접근해야 한다. 즉, 잘 정의된 퍼블릭 인터페이스를 통해 데이터에 대한 접근을 통제해야 하는 것이다.
• 기능 분해가 가진 본질적인 문제를 해결하기 위해 이 같은 개념을 기반으로 한 정보 은닉과 모듈이라는 개념을 제시하였다.

🎈 언제 하향식 분해가 유용한가?

• 하향식 아이디어가 매력적인 이유는 설계가 어느 정도 안정화된 후에는 설계의 다양한 측면을 논리적으로 설명하고 문서화하기에 용이하기 때문이다. 그러나 설계를 문서화하는 데 적절한 방법이 좋은 구조를 설계할 수 있는 방법과 동일한 것은 아니다.
• 프로그래밍 과정에서 이미 해결된 알고리즘을 문서화하고 서술하는 데는 훌륭한 기법이다. 그러나 실제로 동작하는 커타란 소프트웨어를 설계하는 데 적합한 방법은 아니다.

📚 모듈

🎈 정보 은닉과 모듈

• 기능을 기반으로 시스템을 분해하는 것이 아니라 변경의 방향에 맞춰 시스템을 분해하는 것이다.
• 정보 은닉은 시스템을 모듈 단위로 분해하기 위한 기본 원리로 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야 한다는 것이 핵심이다.
• 모듈은 번경될 가능성이 있는 비밀을 내부로 감추고, 잘 정의되고 쉽게 변경되지 않을 퍼블릭 인터페이스를 외부에 제공해서 내부의 비밀에 함부로 접근하지 못하게 한다.
• 기능 분해가 하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정이라면 모듈 분해는 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정이다.
• 비밀을 결정하고 모듈을 분해한 후에는 기능 분해를 이용해 모듈에 필요한 퍼블릭 인터페이스를 구현할 수 있다.
• 모듈은 복잡성과 변경 가능성 두 가지 비밀을 감춰야 한다.
• 이 비밀이 반드시 데이터일 필요는 없으며 복잡한 로직이나 변경 가능성이 큰 자료 구조일 수도 있다.

🎈 모듈의 장점과 한계

🐶 모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 미친다.

• 모듈을 사용하면 모듈 내부에 정의된 변수를 직접 참조하는 코드의 위치를 모듈 내부로 제한할 수 있다.
• 어떤 데이터가 변경됐을 때 영향을 받는 함수를 찾기 위해 해당 데이터를 정의한 모듈만 검색하면 된다.

🐶 비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다.

• 만약 사용자 인터페이스에 추가하더라도 비즈니스 로직은 변경되지 않는다.

🐶 전역 변수와 전역 함수를 제거함으로써 네이스페이스 오염을 방지한다.

• 변수와 함수를 모듈 내부에 포함시키기 때문에 다른 모듈에서도 동일한 이름을 사용할 수 있게 된다. 따라서 네임스페이스의 오염을 방지하는 동시에 이름 충돌의 위험을 완화한다.

---

• 각 모듈은 외부에 감춰야 하는 비밀과 관련성 높은 데이터와 함수의 집합이다. 따라서 모듈 내부는 높은 응집도를 유지한다. 모듈과 모듈 사이에는 퍼블릭 인터펲이스를 통해서만 통신해야 한다. 따라서 낮은 결합도를 유지한다.
• 한 모듈이 정보 은닉이라는 개념을 통해 데이터라는 존재를 설계의 중심 요소로 부각시켰다. 모듈에 있어서 핵심은 데이터이다. 모듈은 감춰야 할 데이터를 결정하고 이 데이터를 조작하는 데 필요한 함수를 결정한다. 다시 말해서 기능이 아니라 데이터를 중심으로 시스템을 분해하는 것이다.
• 모듈의 가장 큰 단점은 인스턴스의 개념을 제공하지 않는다는 점이다.

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

🎈 추상 데이터 타입

• 프로그래밍 언어에서 타입이란 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미한다.
• 타입은 저장된 값에 대해 수행될 수 있는 연산의 집합을 결정하기 때문에 변수의 값이 어떻게 행동할 것이라는 것을 예측할 수 있게 된다.
• 리스코프는 프로시저 추상화를 보완하기 위해 데이터 추상화의 개념을 제안했다. 추상 데이터 타입은 프로시저 추상화 대신 데이터 추상화를 기반으로 소프트웨어를 개발하게 한 최초의 발걸음이다.
• 추상 데이터 타입을 구현하려면 다음과 같은 특성을 위한 프로그래밍 언어의 지원이 필요하다.
  • 타입을 정의를 선언할 수 있어야 한다.
  • 타입의 인스턴스를 다루기 위해 사용할 수 있는 오퍼레이션의 집합을 정의할 수 있어야 한다.
  • 제공된 오퍼레이션을 통해서만 조작할 수 있도록 데이터를 외부로부터 보호할 수 있어야 한다.
  • 타입에 대해 여러 개의 인스턴스를 생성할 수 있어야 한다.
• 추상 데이터 타입 정의를 기반으로 객체를 생성하는 것은 가능하지만 여전히 데이터와 기능을 분리해서 바라본다. 추상 데이터 타입은 말 그대로 시스템의 상태를 저장할 데이터를 표현한다. 추상 데이터 타입으로 표현된 데이터를 이용해서 기능을 구현하는 핵심 로직은 추상 데이터 타입 외부에 존재한다. 그렇기 때문에 여전히 데이터와 기능을 분리하는 절차적인 설계의 틀에 갇혀 있다.
• 추상 데이터 타입의 기본 의도는 프로그래밍 언어가 제공하는 타입처럼 동작하는 사용자 정의 타입을 추가할 수 있게 하는 것이다. 프로그래밍 언어의 관점에서 추상 데이터 타입은 프로그래밍 언어의 내장 데이터 타입과 동일하다. 단지 타입을 개발자가 정의할 수 있다는 점이 다를 뿐이다.

📚 클래스

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

• 클래스는 명확한 의미에서 추상 데이터 타입과 동일하지 않다. 가장 핵심적인 차이는 클래스는 상속과 다형성을 지원하는 데 비해 추상 데이터 타입은 지원하지 못한다는 점이다.
• 상속과 다형성을 지원하는 객체지향 프로그래밍과 구분하기 위해 상속과 다형성을 지원하지 않는 추상 데이터 타입 기반의 프로그래밍 패러다임을 객체기반 프로그래밍이라고 부르기도 한다.
• 추상 데이터 타입은 타입을 추상화한 것이고 클래스는 절차를 추상화한 것이다.
• 타입 추상화는 개별 오퍼레이션이 모든 개념적인 타입에 대한 구현을 포괄하도록 함으로써 하나의 물리적인 타입 안에 전체 타입을 감춘다. 따라서 타입 추상화는 오퍼레이션을 기준으로 타입을 통합하는 데이터 추상화 기법이다.
• 추상 데이터 타입이 오퍼레이선을 기준으로 타입을 묶는 방법이라면 객체지향은 타입을 기준으로 오퍼레이션을 묶는다.
• 두 가지 타입을 기준으로 클래스로 분리할 경우 공통 로직을 어디에 둘 것인지가 이슈가 되는데 공통 로직을 제공할 수 있는 가장 간단한 방법은 공통 로직을 포함할 경우 부모 클래스의 정의하고 두 직원 유형의 클래스가 상속받게 하는 것이다. 이제 클라이언트는 부모 클래스의 참조자에 대해 메시지를 전송하면 실제 클래스가 무엇인가에 따라 적절한 절차가 실행된다. 즉, 동일한 메시지에 대해 서로 다르게 반응한다. 이것이 바로 다형성이다.
• 클라이언트 콴점에서는 두 클래스의 인스턴스는 동일하게 보이지만 실제로 내부에서 수행되는 절차는 다르다. 다시 말해 객체지향은 절차 추상화이다.

🎈 변경을 기준으로 선택하라

• 타입을 기준으로 절차를 추상화하지 않았다면 그것은 객체지향 분해가 아니다. 클래스를 사용하고 있더라도 말이다.
• 클래스가 추상 데이터 타입의 개념을 따르는지를 확인할 수 있는 가장 간단한 방법은 클래스 내부에 인스턴스의 타입을 표현하는 변수가 있는지를 살펴보는 것이다.
• 객체지향에서는 타입 변수를 이용한 조건문을 다형성으로 대체한다. 클라이언트가 객체의 타입을 확인한 후 적절한 메서드를 호출하는 것이 아니라 객체가 메시지를 처리할 메서드를 선택한다.
• 모든 설계의 문제가 그런 것처럼 조건문을 사용하는 방식을 기피하는 이유는 역시 변경 때문이다.
• 기존 코드에 아무런 영향도 미치지 않고 새로운 객체 유형과 행위를 추가할 수 있는 객체지향의 특성을 개방-폐쇄 원칙(OCP)이라고 부른다.
• 만약 타입 추가라는 변경의 압력이 더 강한 경우에는 객체지향의 손을 들어줘야 한다. 클라이언트 코드를 수정할 필요가 없고, 간단하게 새로운 클래스를 상속 계측에 추가하기만 하면 된다.
• 이에 반해 변경의 주된 압력이 오퍼레이션을 추가하는 것이라면 추상 데이터 타입의 승리를 선언해야 한다. 객체지향의 경우 새로운 오퍼레이션을 추가하기 위해서는 상속 계층에 속하는 모든 클래스의 한 번에 수정해야 한다. 이와 달리 추상 데이터 타입의 경우에는 전체 타입에 대한 구현 코드가 하나의 구현체 내에 포함돼 있기 때문에 새로운 오퍼레이션을 추가하는 작업이 상대적으로 간단하다.