객체 분해

책임 중심 설계를 위한 메시지 & 인터페이스 정의하기

• 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 추상화라 한다.

• 가장 일반적인 추상화 방법은 한번에 다뤄야하는 문제의 크기를 줄여 해결가능한 작은 문제로 나누는 경향이 있다.

• 큰 문제를 해결 가능한 작은 문제로 나누는 작업을 분해(decomposition)이라 한다.

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

• 프로그램 패러다임은 프로그래밍을 구성하기 위해 사용하는 추상화의 종류와 이 추상화를 이용해 소프트웨어를 분해하는 방법의 두 가지 요소로 결정된다.

• 모든 프로그래밍 패러다임은 추상화와 분해의 관점에서 설명이 가능하다.

• 현대적인 프로그래밍 언어를 특징짓는 중요한 두 가지 추상화 메커니즘

  • 프로시저 추상화(procedure abstraction)

    • 소프트웨어가 무엇을 해야 하는지를 추상화하는 것

  • 데이터 추상화(data abstraction)

    • 소프트웨어가 무엇을 알아야 하는지를 추상화하는 것

• 프로그래밍 패러다임이란

  • 적절한 추상화의 윤곽을 따라 시스템을 어떤 식으로 나눌 것인지를 결정하는 원칙과 방법의 집합

• 시스템을 분해하는 방법의 기준

  • 프로시저 추상화를 중심

    • 기능분해(functional decomposition) or 알고리즘분해(algorithmic decomposition)

  • 데이터 추상화를 중심

    • 데이터를 중심으로 타입을 추상화(type abstraction)

      • 추상 데이터 타입(Abstract Data Type)

    • 데이터를 중심으로 프로시저를 추상화(procedure abstraction)

      • 객체지향(Object-Oriented)

• '역할과 책임을 수행하는 객쳬' 가 바로 객체지향 패러다임이 이용하는 추상화

• '협력하는 공동체' 를 구성하도록 객체들로 나누는 과정이 바로 객체지향 패러다임에서의 분해를 의미한다.

• 프로그래밍 언어의 관점에서 객체지향이란 데이터를 중심으로 데이터 추상화와 프로시저 추상화를 통합한 객체를 이용해 시스템을 분해하는 방법이다.

• 이런 객체를 구현하기 위해 대부분의 객체지향 언어는 클래스라는 도구를 제공한다.

• 프로그래밍 언어적인 관점에서 객쳬지향을 바라보는 일반적인 관점은 데이터 추상화와 프로시저 추상화를 함께 포함한 클래스를 이용해 시스템을 분해하는 것이다.

• 일반적으로 객쳬지향이 전통적인 기능 분해 방법에 비해 효과적이라고 말하는 이유가 무엇일까?

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

메인 함수로서의 시스템

• 기능은 오랜시간 동안 시스템을 분해하기 위한 기준으로 사용됐으며, 이같은 시스템 분해 방식을 알고리즘 분해 또는 기능 분해라고 부른다.

• 기능 분해의 관점에서 추상화의 단위는 프로시저이며 시스템은 프로시저를 단위로 분해된다.

• 프로시저 중심의 기능 분해 관점에서 시스템은 입력 값을 계산해서 출력 값을 반환하는 수학의 함수와 동일하다.

• 시스템은 필요한 더 작은 작업으로 분해될 수 있는 하나의 커다란 메인함수다.

전통적인 기능 분해 방법

• 하향식 접근법(Top-Down Approach)

• 하향식 접근법이란 시스템을 구성하는 가장 최상위(topmost) 기능을 정의하고, 이 최상위 기능을 좀 더 작은 단계의 하위 기능으로 분해해 나가는 방법

• 분해는 세분화된 마지막 하위 기능이 프로그래밍 언어로 구현 가능한 수준이 될때까지 계속된다.

하향식 기능 분해

• 시스템을 최상위의 가장 추상적인 메인함수로 정의하고, 메인 함수를 구현 가능한 수준까지 세부적인 단계로 분해하는 방법

• 하향식 기능 분해 방식으로 설계한 시스템은 메인 함수를 루트로 하는 '트리(tree)'로 표현할 수 있다.

하향식 기능 분해의 문제점

• 시스템은 하나의 메인 함수로 구성되어 있지 않다.

• 기능 추가나 요구사항 변경으로 인해 메인 함수를 빈번하게 수정해야 한다.

• 비즈니스 로직이 사용자 인터페이스와 강하게 결합된다.

• 하향식 분해는 너무 이른 시기에 함수들의 실행 순서를 고정시키기 때문에 유연성과 재사용성이 저하된다.

• 데이터 형식이 변경될 경우 파급효과를 예측할 수 없다.

설계란?

• 코드 배치 방법이며 설계가 필요한 이유는 변경에 대비하기 위한 것이다.

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

• 하향식 접근법은 사용자 인터페이스 로직과 비즈니스 로직을 한데 섞기 때문에 사용자 인터페이스를 변경하는 경우 비즈니스 로직까지 변경에 영향을 받게 된다.

• 하향식으로 기능을 분해하는 과정

  • 하나의 함수를 더 작은 함수로 분해하고, 분해된 함수들의 실행순서를 결정하는 작업으로 요약할 수 있다.

  • 설계를 시작하는 시점부터 시스템이 무엇(what)을 해야 하는지가 아니라, 어떻게(how) 동작해야 하는지에 집중하도록 만든다.

• 하향식 설계의 문제점

  • 중앙 집중 제어 스타일(centralized control style)의 형태를 띈다.

  • 하향식 접근법을 통해 분해한 함수들은 재사용하기도 어렵다.

  • 하향식 설계와 관련된 모든 문제의 원인은 결합도이다.

  • 전체 시스템의 핵심적인 구조를 결정하는 함수들이 데이터와 강하게 결합된다.

• 하향식 설계를 해결하는 방법 (의존성 관리에 대한 핵심)

  • 자주 변경되는 시간적인 제약에 대한 미련을 버리고 좀 더 안정적인 논리적 제약(logical constraint)을 설계의 기준으로 삼는 것이다.

  • 데이터 변경으로 인한 영향을 최소화하려면 데이터와 함께 변경되는 부분과 그렇지 않은 부분을 명확하게 분리해야 한다.

  • 잘 정의된 퍼블릭 인터페이스를 통해 데이터에 대한 접근을 통제해야 한다.

• 하향식 분해가 유용한 경우

  • 하향식 아이디어가 매력적인 이유는 설계가 어느정도 안정화된 후에는 설계의 다양한 측면을 논리적으로 설명하고 문서화하기에 용이하기 때문이다.

  • 특히 프로그래밍 과정에서 이미 해결된 알고리즘을 문서화하고 서술하는 데는 훌륭한 기법이다.

하향식 설계의 문제점 정리

• 하향식 분해방식으로 설계된 소프트웨어는 하나의 함수에 제어가 집중되기 때문에 확장이 어렵다.

• 하향식 분해는 프로젝트 초기에 설계의 본질적인 측면을 무시하고 사용자 인터페이스 같은 비본질적인 측면에 집중하게 만든다.

• 과도하게 함수에 집중하게 함으로써 소프트웨어의 중요한 다른 측면인 데이터에 대한 영향도를 파악하기 어렵게 만든다.

• 하향식 분해를 적용한 설계는 근본적으로 재사용하기 어렵다.

03. 모듈

정보 은닉과 모듈

• 시스템의 변경을 관리하는 기본적인 전략은 함께 변경되는 부분을 하나의 구현 단위로 묶고 인터페이스를 통해서 접근하도록 만드는 것이다.

• 즉, 기능을 기반으로 시스템을 분해하는 것이 아니라 변경의 방향에 맞추어 시스템을 분해하는 것이다.

• 정보 은닉은 외부에 감춰야 하는 비밀에 따라 시스템을 분할하는 모듈 분할 원리이다.

  • 모듈은 변경될 가능성이 있는 비밀을 내부로 감추고, 잘 정의되어 있고 쉽게 변경되지 않을 퍼블릭 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 해야한다.

• 시스템을 관리하기 위한 모듈과 기능분해

  • 모듈과 기능분해의 관계

    • 시스템을 모듈로 분해, 모듈 내부를 구현하기 위한 기능분해를 적용

    • 기능 분해는 하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정

    • 모듈 분해는 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정

  • 모듈이 감추어야 하는 두 가지 비밀

    • 복잡성

      • 모듈이 너무 복잡한 경우 이해하고 사용하기 어렵다.

      • 외부에 모듈을 추상화할 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다.

    • 변경 가능성

      • 변경 가능한 설계 결정이 외부에 노출될 경우 실제로 변경이 발생했을 때 파급효과가 커진다.

      • 변경 발생 시 하나의 모듈만 수정하면 되도록 변경 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공한다.