07_객체 분해

BookReview/오브젝트

07_객체 분해

Fkaa 2023. 2. 5. 23:44

오브젝트 - 코드로 이해하는 객체지향 설계의 7장 객체 분해 파트를 다루는 글이다. 7장에서는 프로그래밍 패러다임의 흐름 속에서 지금까지 정리했던 객체지향 개념들이 탄생하게 된 배경을 서술하고 있다. 이를 통해 지금까지 다루었던 다양한 원리와 개념들을 이해하는데 많은 도움이 될 수 있고, 객체지향 이외의 다른 패러다임을 이해하는것에 도움을 받을 수 있다고 설명하고 있다.

00_들어가기

추상화
- 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업
분해
- 큰 문제를 해결 가능한 작은 문제로 나누는 작업
추상화와 분해는 인간이 세계를 인식하고 반응하기 위해 사용하는 가장 기본적인 사고 도구라고 할 수 있음

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

프로그래밍 언어의 발ㄹ전은 좀 더 효과적인 추상화를 이용해 복잡성을 극복하려는 개발자들의 노력에서 출발했다.
어샘블리어
- 숫자로 뒤범벅된 기계어에 인간이 이해할 수 있는 상징을 부여하려는 노력의 결과
고수준 언어
- 기계적인 사고를 강요하는 낮은 수준의 명령어들을 탈피해서 인간의 눈높이에 맞는 기계 독립적이고 의미 있는 추상화를 제공하려는 시도의 결과
프로그래밍 언어를 통해 표현되는 추상화의 발전은 다양한 프로그래밍 패러다임의 탄생으로 이어졌다.
프로그래밍 패러다임
- 프로그래밍을 구성하기 위해 사용하는 추상화의 종류와 이 추상화를 이용해 소프트웨어를 분해하는 방법의 두 가지 요소로 결정된다.
- 프로시저 추상화(Procedure Abstraction)
  - 소프트웨어가 무엇을 해야 하는지를 추상화
- 데이터 추상화(Data Abstraction)
  - 소프트웨어가 무엇을 알아야 하는지를 추상화
- 소프트웨어는 데이터를 이용해 정보를 표현하고 프로시저를 이용해 데이터를 조작한다.
- 프로그래밍 패러다임
  - 적절한 추상화의 윤곽을 따라 시스템을 어떤 식으로 나눌 것인지를 결정하는 원칙과 방법의 집합
- 시스템을 분해하는 방법을 결정하려면 먼저 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 결정
  - 프로시저 추상화 중심
    - 기능 분해(Functional Decomposition) [== 알고리즘 분해(Algorithm Decomposition)]
  - 데이터 추상화 중심
    - 데이터를 중심으로 타입을 추상화(Type Decomposition) [== 추상 데이터 타입(Abstract Data Type]
    - 데이터를 중심으로 프로시저를 추상화(Procesure Abstraction) [== 객체지향(Object-Oriented)]
- 객체지향 패러다임 : 역할과 책임을 수행하는 자율적인 객체들의 협력 공동체를 구축하는 것
  - 역할과 책임을 수행하는 객체 > 객체지향 패러다임이 이용하는 추상화
  - 협력하는 공동체 를 구성하도록 객체들로 나누는 과정이 객체지향 패러다임에서의 분해를 의미
- 프로그래밍 언어 관점에서의 객체지향
  - 데이터를 중심으로 데이터 추상화와 프로시저 추상화를 통합한 객체를 이용해 시스템을 분해하는 방법
- 프로그래밍 언어적인 관점에서 객체지향을 바라보는 일반적인 관점
  - 데이터 추상화와 프로시저 추상화를 함께 포함한 클래스를 이용해 시스템을 분해하는 것

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

메인 함수로서의 시스템
- 기능은 오랜 시간 동안 시스템을 분해하기 위한 기준으로 사용되었다.
- 이 같은 시스템 분해 방식을 알고리즘 분해 또는 기능 분해 라고 한다.
- 기능 분해의 관점에서 추상화의 단위는 프로시저이며, 시스템은 프로시저를 단위로 분해한다.
- 프로시저
  - 반복적으로 실행되거나 거의 유사하게 실행되는 작업들을 하나의 장소에 모아놓음으로써 로직을 재사용하고 중복을 방지할 수 있는 추상화 방법
  - 프로시저를 추상화라고 부르는 이유
    - 내부의 상세한 구현 내용을 모르더라도 인터페이스만 알면 프로시저를 사용할 수 있기 때문
- 하향식 접근법(Top-Down Approach)
  - 전통적인 기능 분해 방법
  - 시스템을 구성하는 최상위(topmost) 기능을 정의하고, 이 최상위 기능을 좀 더 작은 단계의 하위 기능으로 분해해 나가는 방법
  - 분해는 세분화된 마지막 하위 기능이 프로그래밍 언어로 구현 가능한 수준이 될 때까지 계속
  - 각 세분화 단계는 바로 위 단계보다 더 구체적이어야 한다.
  - 상위기능은 하나 이사아의 더 간단하고 더 구체적이며 덜 추상적인 하위 기능의 집합으로 분해된다.
급여관리 시스템
- 7장에서 사용되는 예시는 간단한 급여 관리 시스템
- 급여 관리 시스템의 기능 분해 과정
  1. 시스템에 대한 추상적인 최상위 문장을 기술
    - 직원의 급여를 계산한다.
  2. 최상위 문장을 좀 더 세분화된 절차로 구체화
    - 직원의 급여를 계산한다.
      - 사용자로부터 소득세율을 입력받는다.
      - 직원의 급여를 계산한다.
      - 양식에 맞게 결과를 출력한다.
  3. 정제 가능한 문장이 존재할 경우 동일 과정을 거쳐 구현이 가능할 정도로 충분히 저수누의 문장이 될 때가지 기능을 분해
    - 직원의 급여를 계산한다.
      - 사용자로부터 소득세율을 입력받는다.
        
        "세율을 입력하세요: "라는 문장을 화면에 출력한다.
        
        키보드를 통해 세율을 입력받는다.
      - 직원의 급여를 계산한다.
        
        전역 변수에 저장된 직원의 기본급 정보를 얻는다.
        
        급여를 계산한다.
      - 양식에 맞게 결과를 출력한다.
        
        "이름: {직원명}, 급여: {계산된 금액}" 형식에 따라 출력 문자열을 생성한다.
- 기능 분해의 결과는 최상위 기능을 수행하는 데 필요한 절차들을 실행되는 시간 순서에 따라 나열한 것
  그림 7.1 메인 함수수로서의 급여 관리 시스템
- 기능 분해 방법에서는 기능을 중심으로 필요한 데이터를 결정
- 기능 분해를 위한 하향식 접근법은 먼저 필요한 기능을 생각하고 이 기능을 분해하고, 정제하는 과정엥서 필요한 데이터의 종류와 저장 방식을 식별
  - 유지보수에 다양한 문제점을 야기
- 하향식 기능 분해 방식이 가지는 문제점을 이해하는 것은 유지보수 관점에서 객체지향의 장점을 이해할 수 있는 좋은 출발점
기능 분해 방식에 따른 급여 관리 시스템 구현
- 오브젝트 에서는 동일한 시스템을 다양한 방식으로 구현하고 비교해야 하는 목표를 달성하기 위해 Ruby언어를 사용하였다.
- Ruby를 사용하기 위해 환경설정을 하는것 보다 코드를 해석하고 java로 풀어쓰기로 하고 예시코드 작성을 진행하였다.
- Github_01 Java를 통한 급여 관리 시스템의 구현
- https://github.com/JIHYEON-PF/book_review_object/pull/14

07_객체 분해 첫 번째 PR - 급여 관리 시스템 구현 by JIHYEON-PF · Pull Request #14 · JIHYEON-PF/book_review_obje

오브젝트의 7장 객체 분해 파트의 첫 번재 PR로 급여 관리 시스템을 구현하였다. 도서에서는 Ruby 언어를 통해 구현된 내용을 Java로 풀어서 구현하였다. 또한 이 시스템은 기능 분해 구조를 통해

github.com

- 하향식 기능 분해는 논리적이고 체계적인 시스템 개발 절차를 제시한다.
- 체계적이고 이상적인 방법은 불규칙하고 불완전한 인간과 만나는 지점에서 혼란과 동요를 야기한다.

하향식 기능분해의 문제점
- 하향식 접근법과 기능 분해가 가지능 근목적인 문제점은 변경에 취약한 설계를 낳는다는 것
- 하나의 메인 함수라는 비현실적인 아이디어
  - 대부분의 시스템에서는 하나의 메인 기능이란 개념은 존재하지 않음.
  - 하향식 접근법은 하나의 알고리즘을 구현하거나 배치 처리를 구현하기에는 적합하지만, 현대적인 상호작용 시스템을 개발하는데는 적합하지 않다.
    - 현대적인 시스템은 동등한 수준의 다양한 기능으로 구성됨
- 메인 함수의 빈번한 재설계
  - 하향식 기능 분해의 경우에는 새로운 기능을 추가할 때마다 매번 메인 함수를 수정해야 한다.
  - 기존 코드의 빈번한 수정으로 인한 버그 발생 확률이 높아지기 때문에 시스템은 변경에 취약해질 수 밖에 없다.
- 비즈니스 로직과 사용자 인터페이스의 결합
  - 하향식 접근법은 비즈니스 로직을 설계하는 초기 단계부터 입력 방법과 출력 양식을 함께 고민하도록 강요
    - 코드 안에서 비즈니스 로직과 사용자 인터페이스 로직이 밀접하게 결합
  - 비즈니스 로직과 사용자 인터페이스가 변경되는 빈도는 다르다.
    - 사용자 인터페이스는 시스템 내에서 가장 자주 변경되는 부분이지만, 비즈니스 로직은 사용자 인터페이스에 비해 변경이 적다.
    - 하향식 접근법은 사용자 인터페이스를 변경하는 경우 비즈니스 로직까지 변경에 영향을 받게된다.
    - 따라서 하향식 접근법은 근본적으로 변경에 불안정한 아키텍처를 낳는다.
  - 하향식 접근법은 기능을 분해하는 과정에서 사용자 인터페이스의 관심사와 비즈니스 로직의 관심사를 동시에 고려하도록 강요하기 때문에 "관심사의 분리"라는 아키텍처 설계의 목적을 달성하기 어렵다.
- 성급하게 결정된 실행 순서
  - 하향식 분해는 설계를 시작하는 시점부터 시스템이 무엇(what)을 해야하는지가 아닌, 어떻게(how) 동작해야 하는지에 집중하도록 한다.
    - 하향식 접근법의 설계는 처음부터 구현을 염두에 두기 때문에 자연스럽게 함수들의 실행 순서를 정의하는 시간제약(temporal constraint)을 강조
  - 실행 순서나 조건, 반복과 같은 제어 구조를 미리 결정하지 않고는 분해를 진행할 수 없기 대문에 기능분해 방식은 중앙집중 제어 스타일(Centralized control style)의 형태를 띨 수 밖에 없다.
    - 중요한 설계 결정 사항인 함수의 제어 구조는 빈번한 변경의 대상이다.
    - 기능을 추가하거나 변경하는 작업은 매번 기존에 결정된 함수의 제어구조를 변경하도록 한다.
    - 해결 방법 : 자주 변경되는 시간적인 제약에 대한 미련을 버리고 좀 더 안정적인 논리적 제약(Locgical Constraint)을 설계의 기준으로 한다.
      - 객체지향은 함수 간의 호출 순서가 아닌 객체 사이의 논리적인 관계를 중심으로 설계를 이끌어 간다.
      - 전체적인 시스템은 어떤 한 구성요소로 제어가 집중되지 않고 여러 객체들 사이로 제어 주체가 분산된다.
  - 하향식 접근을 통해 분해된 함수들은 재사용이 어렵다.
    - 분해된 하위 함수들은 상위 함수가 강요하는 문맥 안에서만 의미를 가지기 때문이다.
  - 하향식 설계와 관련된 모든 문제의 원인은 결합도다.
    - 강한 결합도는 시스템을 변경에 취약하게 만들고 이해하기 어렵게 한다.
    - 하향식 설계의 함수는 함께 절차를 구성하는 다른 함수들과 시간적으로 강하게 결합돼 있다.
- 데이터 변경으로 인한 파급효과
  - 어떤 데이터를 어떤 함수가 사용하고 있는지를 추적하기 어려움
    - 어떤 데이터가 어떤 함수에 의존하고 있는지를 파악하는 것은 어려운 일인데, 모든 함수를 열어 데이터를 사용하고 있는지를 모두 확인해봐야 하기 때문
  - 코드 안에서 텍스트를 검색하는 단순한 문제가 아닌 의존성과 결합도의 문제, 그리고 테스트의 문제
  - 데이터 변경으로 인한 영향을 최소화 하려면 데이터와 함께 변경되는 부분과 그렇지 않은 부분을 명확하게 분리해야 한다.
    - 잘 정의된 퍼블릭 인터페이스를 통해 데이터에 대한 접근을 통제한다.
- 하향식 분해가 유용할 때
  - 작은 프로그램과 개별 알고리즘을 위해서는 유용한 패러다임
  - 이미 해결된 알고리즘을 문서화 하고 서술하는데 훌륭한 기법

03_모듈

정보 은닉과 모듈
- 정보 은닉(Information Hiding)
  - 시스템을 모듈 단위로 분해하기 위한 기본 원리
  - 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야 한다는 것이 핵심
  - 외부에 감춰야 하는 비밀에 따라 시스템을 분할하는 모듈 분할 원리
  - 모듈과 기능 분해는 상호 베타적인 관계가 아님
    - 시스템을 모듈로 분해한 후에는 각 모듈 내부를 구현하기 위해 기능 분해를 적용할 수 있음
    - 기능분해: 하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정
    - 모듈분해: 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정
- 모듈이 감춰야 하는 비밀
  - 복잡성 : 모듈이 너무 복잡한 경우 이해하고 사용하기가 어렵다. 외부에 모듈을 추상화 할 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다.
  - 변경 가능성 : 변경 가능한 설계 결정이 외부에 노출될 경우 실제로 변경이 발생했을 때 파급효과가 커진다. 변경이 발생 시 하나의 모듈만 수정하면 되도록 변경 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공한다.
모듈의 장점과 한계
- 장점
  - 모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 미친다.
    - 모듈은 데이터 변경으로 인한 파급효과를 제어할 수 있기 때문에 코드를 수정하고 디버깅하기 더 용이하다.
  - 비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다.
  - 전역 변수와 전역 함수ㅡㄹ 제거함으로써 네임스페이스 오염(namespace pollution)을 방지한다.
    - 모듈은 전역 네임스페이스의 오염을 방지하는 동시에 이름 충돌(name collision)의 위험을 완화한다.
- 모듈은 기능이 아닌 변경의 정도에 따라 시스템을 분해
  - 모듈 내부는 높은 응집도를 유지
    - 모듈은 외부에 감춰야 하는 비밀과 관련성 높은 데이터의 함수의 집합
  - 모듈은 낮은 결합도를 유지
    - 모듈과 모듈 사이에는 퍼블릭 인터페이스를 통해서만 통신
  - 모듈은 데이터와 함수가 통합된 한 차원 높은 추상화를 제공하는 설계 단위
- 한계
  - 변경을 관리하기 위한 구현 기법이기 대문에 추상화 관점에서의 한계점이 명확
    - 인스턴스 개념을 제공하지 않는다.

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

추상 데이터 타입
- 타입(Type) : 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미
- 프로그래밍 언어는 다양한 형태의 내장 타입(built-in type)을 제공
- 데이터 추상화(Data Abstraction) : 프로시저 추상화를 보완하기 위한 개념
  - 추상 객체의 클래스를 정의한 것으로 추상 객체에 사용할 수 있는 오퍼레이션을 이용해 규정
    - 오퍼레이션을 이용해 추상 데이터 타입을 정의할 수 있음을 의미
- 추상 데이터 타입 구현을 위한 프로그래밍 언어의 필요 지원
  - 타입 정의를 선언할 수 있어야 한다.
  - 타입의 인스턴스를 다루기 위해 사용할 수 있는 오퍼레이션의 집합을 정의할 수 있어야 한다.
  - 제공된 오퍼레이션을 통해서만 조작할 수 있도록 데이터를 외부로부터 보호할 수 있어야 한다.
  - 타입에 대해 여러 개의 인스턴스를 생성할 수 있어야 한다.
- CLU : 추상 데이터 타입을 정의할 수 있는 문법을 제공하는 프로그래밍 언어
- 추상 데이터 타입 정의를 기반으로 객체를 생성하는 것은 가능하지만, 여전히 데이터와 기능을 분리해서 바라본다는 점을 주의

05_ 클래스

클래스는 추상 데이터 타입인가?
- 대부분의 프로그래밍 서적에서는 클래스를 추상 데이터 타입으로 설명
  - 명확한 의미에서 추상 데이터 타입과 클래스는 동일하지 않음.
  - 데이터 추상화를 기반으로 시스템을 분해하기 때문에 꼭 틀린것은 아니지만, 클래스는 상속과 다형성을 지원하는 데 비해 추상 데이터 타입은 지원하지 못한다.
  - 객체기반 프로그래밍(Object-Based Programming)
    - 상속과 다형성을 지원하지 않은 추상 데이터 타입을 기반의 프로그래밍 패러다임
  - "윌리엄 쿡(William Cook)"
    - 추상 데이터 타입 : 타입을 추상화 한 것(Type Abstraction)
    - 클래스 : 절차를 추상화한 것(Procedural Abstration)
    - 타입추상화
      - 하나의 대표적인 타입이 다수의 세부적인 타입을 감춤
      - 개별 오퍼레이션이 모든 개념적인 타입에 대한 구현을 포괄하도록 함으로써 하나의 물리적인 타입 안에 전체 타입을 감춤
      - 타입추상화는 오퍼레이션을 기준으로 타입을 통합하는 데이터 추상화 기법
  - 타입 추상화를 기반으로 하는 대표적인 기법 : 추상 데이터 타입
  - 객체지향
    - 타입을 기준으로 오퍼레이션을 묶음
    - 동일한 메시지에 대해 서로 다른 반응을 함 > 다형성
    - 실제로 내부에서 수행되는 절차는 다르지만 클래스를 이용한 다형성은 절차에 대한 차이점을 감춘다.
    - 객체지향 = **절차 추상화(Procedural Abstration)
- 추상화와 분해의 관점에서 추상 데이터 타입과 클래스의 차이
  - 추상 데이터 타입은 오퍼레이션을 기준으로 타입을 추상화
  - 클래스는 타입을 기준으로 절차들을 추상화
변경을 기준으로 선택하라
- 단순히 클래스를 구현 단위로 사용한다는 것이 객체지향 프로그래밍을 한다는 것을 의미하지는 않음.
- 타입을 기준으로 절차를 추상화하지 않았다면 그것은 객체지향 분해가 아님.
- 객체지향에서는타입 변수를 이용한 조건문을 다형성으로 대체한다.
  - 클라이언트가 객체의 타입을 확인한 후 적절한 메서드를 호출하는 것이 아니라 객체가 메시지를 처리할 적절한 메서드를 선택.
- 개방-폐쇄의 원칙(Open-Closed Principle, OCP)
  - 기존 코드에 아무런 영향도 미치지 않고 새로운 객체 유형과 행위를 추가할 수 있는 객체지향의 특성
  - 객체지향 설계가 전통적인 방식에 비해 변경하고 확장하기 쉬운 구조로 설계할 수 있는 이유
- 설계의 유용성은 변경의 방향성과 발생 빈도에 따라 결정
- 추상 데이터 타입과 객체지향 설계의 유용성은 설계에 요구되는 변경의 압력이 '타입 추가'에 관한 것인지, '오퍼레이션 추가'에 관한 것인지에 따라 달라진다.
  - 새로운 타입을 빈번하게 추가해야 한다면 객체지향의 클래스 구조가 유용
  - 새로운 오퍼레이션을 빈번하게 추가해야 한다면 추상 데이터 타입이 유용

06_ Review

이번 장을 읽으면서 가장 큰 실수를 했던 것은 Ruby언어를 Java로 풀어쓰기 시작한 것이다. 저자가 Ruby를 통해 예시를 들고 설명을 시작한 것은 그만한 이유가 있어서였으나, '나는 Java를 사용하니 Java로 풀어쓰며 다른 언어가 어떤 방식으로 사용되고 이걸 어떻게 리팩터링해서 사용할 수 있는지 배울 수 있는 기회가 될 것이다.'라고 생각하고 풀어쓰기 시작하였다.
하지만 저자가 Ruby를 사용하면서 전통적인 기능 분해 방식에 따라 코드를 작성하는 것을 Java로 충분히 풀어적지 못하였고, 눈으로만 보고 이해하는것에 그쳐 굉장히 아쉬웠다. 다음으로 올 챕터 또는 다른 책을 읽으면서 다른 언어를 사용하여 설명을 할 때는 해당 언어로 작성해보고 난 후 이 언어를 어떻게 Java로 가져올 것인지를 고려해봐야 겠다.
책 내용에 대한 점은 개인적으로 이해하기 어려웠던 장이었다. 객체지향이 절차를 추상화하여 클래스별로 정보은닉과 다형성 등의 이점이 있는것은 알게되었으나, 구체적으로 추상 데이터 타입이 어떤 형식으로 정의되는지에 대해서는 완벽하게 이해하기 어려워서 아쉬웠다. 시간이 날 때 다시 한번 읽어봐야 하는 장으로 남겨두어야겠다.

오브젝트

객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것이다. 세번째 걸음을 내디딜 수 있는지 여부는 협력에 참여하는 객체 들에게 얼마나 적절한 역할과 책임을 부여할 수 있느냐에 달려 있다. 객체지향의 마지막 걸음은 앞에서 설명한 개념들을 여러분이 사용하는 프로그래밍 언어라는 틀에 흐트러짐 없이 담아낼 수 있는 기술을 익히는 것이다. 《객체지향의 사실과 오해》가 첫번째 걸음과 두번째 걸음인 객체와 협력에 초점을 맞췄다면 《오브젝트: 코드로 이해하는 객체지향 설계》는 세번째와 네번째 걸음인 책임의 할당과 그 구현에 초점을 맞춘다. 이 책을 읽고 나면 객체에 적절한 역할과 책임을 부여하는 방법과 유연하면서도 요구사항에 적절한 협력을 설계하는 방법을 익히게 될 것이다. 나아가 프로그래밍 언어라는 도구를 이용해 객체지향의 개념과 원칙들을 오롯이 표현할 수 있는 방법 역시 익힐 수 있을 것이다. ★ 이 책에서 다루는 내용 ★ ◎ 역할, 책임, 협력에 기반해 객체지향 프로그램을 설계하고 구현하는 방법 ◎ 응집도와 결합도를 이용해 설계를 트레이드오프하는 방법 ◎ 설계를 유연하게 만드는 다양한 의존성 관리 기법 ◎ 타입 계층을 위한 상속과 코드 재사용을 위한 합성의 개념 ◎ 다양한 설계 원칙과 디자인 패턴

저자: 조영호

출판: 위키북스

출판일: 2019.06.17

(참고문헌: 조영호, 오브젝트 - 코드로 이해하는 객체지향 설계, 위키북스, 2022.11.30(6쇄 발행), p.216 ~ p.252)

저작자표시 비영리 변경금지