객체 분해
책임 중심 설계를 위한 메시지 & 인터페이스 정의하기
불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을
추상화라 한다.가장 일반적인 추상화 방법은 한번에 다뤄야하는 문제의 크기를 줄여 해결가능한 작은 문제로 나누는 경향이 있다.
큰 문제를 해결 가능한 작은 문제로 나누는 작업을
분해(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. 모듈
정보 은닉과 모듈
시스템의 변경을 관리하는 기본적인 전략은 함께 변경되는 부분을 하나의 구현 단위로 묶고 인터페이스를 통해서 접근하도록 만드는 것이다.즉, 기능을 기반으로 시스템을 분해하는 것이 아니라 변경의 방향에 맞추어 시스템을 분해하는 것이다.
정보 은닉은 외부에 감춰야 하는 비밀에 따라 시스템을 분할하는 모듈 분할 원리이다.
모듈은 변경될 가능성이 있는 비밀을 내부로 감추고, 잘 정의되어 있고 쉽게 변경되지 않을 퍼블릭 인터페이스를 외부에 제공하여 내부의 비밀에 함부로 접근하지 못하도록 해야한다.
시스템을 관리하기 위한 모듈과 기능분해
모듈과기능분해의 관계시스템을 모듈로 분해, 모듈 내부를 구현하기 위한 기능분해를 적용
기능 분해는 하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정
모듈 분해는 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정
모듈이 감추어야 하는 두 가지 비밀복잡성
모듈이 너무 복잡한 경우 이해하고 사용하기 어렵다.
외부에 모듈을 추상화할 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다.
변경 가능성
변경 가능한 설계 결정이 외부에 노출될 경우 실제로 변경이 발생했을 때 파급효과가 커진다.
변경 발생 시 하나의 모듈만 수정하면 되도록 변경 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공한다.
Last updated