7장 - 객체 분해

개요

이번장에서는 객체를 분해하는 방법들에 대해 살펴봅니다.

 

 

왜 객체를 분해할까?

• 문제 해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 문제 해결 능력은 급격하게 떨어지고 마는데 이 현상을 인지 과부하라고 부릅니다.
• 이러한 인지 과부하 문제를 해결하기 위해 객체들을 분해하여 처리해야 합니다.
• 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 추상화라고 부르며, 큰 문제를 해결 가능한 작은 문제로 나누는 작업을 분해라고 부릅니다.

 

 

어떻게 객체를 분해할까?

• 소프트웨어를 분해하는 방법은 두 가지 요소로 결정됩니다.
  • 프로시저 추상화: 소프트웨어가 무엇을 해야 하는지를 추상화
  • 데이터 추상화: 소프트웨어가 무엇을 알아야 하는지를 추상화
• 먼저 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 결정해야 합니다.
• 프로시저 추상화를 중심으로 시스템을 분해하기로 결정했다면 기능 분해의 길로 들어서는 것이며, 기능 분해는 알고리즘 분해라고 부릅니다.
• 데이터 추상화를 중심으로 시스템을 분해하기로 결정했다면 다시 두 가지 중 하나를 선택해야 합니다.
• 하나는 데이터를 중심으로 타입을 추상화하는 것(추상 데이터 타입)이고 다른 하나는 데이터를 중심으로 프로시저를 추상화하는 것(객체지향)입니다.

 

프로시저 추상화는 어떻게 분해할까?

• 기능을 기준으로 시스템을 분해하는 방식을 알고리즘 분해 또는 기능 분해라고 부릅니다.
• 기능 분해의 관점에서 추상화의 단위는 프로시저이며 시스템은 프로시저를 단위로 분해됩니다.

 

프로시저란?

• 반복적으로 실행되거나 거의 유사하게 실행되는 작업들을 하나의 장소에 모아놓음으로써 로직을 재사용하고 중복을 방지할 수 있는 추상화 방법입니다.

 

프로시저를 추상화라고 부르는 이유는 무엇일까?

• 내부의 상세한 구현 내용을 모르더라도 인터페이스만 알면 프로시저를 사용할 수 있기 때문입니다.
• 프로시저 중심의 기능 분해 관점에서 시스템은 필요한 더 작은 작업으로 분해될 수 있는 하나의 커다란 메인 함수입니다.
• 전통적인 기능 분해 방법은 하향식 접근법을 따릅니다.

 

하향식 접근법이란?

• 시스템을 구성하는 가장 최상위 기능을 정의하고, 이 최상위 기능을 좀 더 작은 단계의 하위 기능으로 분해해 나가는 방법입니다.

 

하향식 기능 분해의 문제점은 무엇일까?

• 설계를 시작하는 시점부터 시스템이 무엇(what)을 해야 하는지가 아니라 어떻게(how) 동작해야 하는지에 집중하도록 만들며 이러한 이유 때문에 다음 문제점들이 나옵니다.
  • 처음부터 구현을 염두에 두기 때문에 함수 실행 순서를 정의하는 시간 제약을 강조: 필요한 함수들의 실행 순서를 미리 결정하지 않는 한 기능 분해를 진행할 수 없습니다.
  • 함수 제어 구조가 빈번한 변경의 대상이라는 점: 결과적으로 전체적인 시스템은 어떤 한 구성요소로 제어가 집중되지 않고 여러 객체들 사이로 제어 주체가 분산됩니다.
  • 분해된 함수들은 재사용하기도 어려움: 모든 함수는 상위 함수를 분해하는 과정에서 필요에 따라 식별되며, 그에 따라 상위 함수가 강요하는 문맥 안에서만 의미를 가지기 때문입니다.
  • 데이터 변경으로 인한 파급효과: 데이터 변경 시 어떤 함수가 영향받을지 예상이 어렵습니다.

 

언제 하향식 분해를 사용하면 좋을까?

• 프로그래밍 과정에서 이미 해결된 알고리즘을 문서화하고 서술하는 데에 사용하면 좋습니다.

 

타입 추상화(추상 데이터 타입)는 어떻게 분해할까?

• 먼저 데이터를 감추기 위해 "어떤 데이터에 추상화가 필요한지?" 질문하여 추상화할 데이터를 선택합니다.
• 내부에 캡슐화할 데이터를 결정했다면 추상 데이터 타입에 적용할 수 있는 오퍼레이션을 결정하는 방식으로 객체를 분해합니다.

 

클래스는 추상 데이터 타입일까?

• 추상 데이터 타입에 대한 관점을 봤을 때 "클래스는 추상 데이터 타입인지?"에 대한 궁금증이 생기게 됩니다.
• 클래스와 추상 데이터 타입 모두 데이터 추상화를 기반으로 시스템을 분해하기 때문에 이런 설명이 꼭 틀린 것만은 아니지만 명확한 의미에서 추상 데이터 타입과 클래스는 동일하지 않습니다.
• 가장 핵심적인 차이는 클래스는 상속과 다형성을 지원하는 데 비해 추상 데이터 타입은 지원하지 못한다는 점입니다.
• 상속과 다형성을 지원하지 않는 추상 데이터 타입 기반 프로그래밍 패러다임을 객체기반 프로그래밍이라 부릅니다.
• 추상 데이터 타입은 타입을 추상화한 것이고 클래스는 절차를 추상화한 것입니다.
• 추상 데이터 타입은 오퍼레이션을 기준으로 타입들을 추상화한 것이며, 클래스는 타입을 기준으로 추상화합니다.
• 이것이 추상화와 분해의 관점에서 추상 데이터 타입과 클래스의 다른 점입니다.

 

 

어떤 기준으로 객체를 분해해야 할까?

변경을 기준으로 선택하라

• 단순히 클래스를 구현 단위로 사용한다는 것이 객체지향 프로그래밍을 한다는 것을 의미하지는 않습니다.
• 타입을 기준으로 절차를 추상화하지 않았다면 그것은 객체지향 분해가 아닙니다.
• 클래스가 추상 데이터 타입의 개념을 따르는지를 확인할 수 있는 가장 간단한 방법은 클래스 내부에 인스턴스의 타입을 표현하는 변수가 있는지를 살펴보는 것입니다.
• 인스턴스 변수에 저장된 값을 기반으로 메서드 내에서 타입을 명시적으로 구분하는 방식을 객체지향을 위반하는 것으로 간주됩니다.

 

항상 객체지향 설계방식이 옳은가?

• 설계는 변경과 관련된 것이며, 설계의 유용성은 변경의 방향성과 발생 빈도에 따라 결정됩니다.
• 그리고 추상 데이터 타입과 객체지향 설계의 유용성은 설계에 요구되는 변경의 압력이 타입 추가에 관한 건지, 오퍼레이션 추가에 관한 것인지에 따라 다릅니다.

• 타입 추가라는 변경의 압력이 더 강한 경우 객체지향방식이 더 좋은 방법입니다.
  • 추상 데이터 타입의 경우 새 타입을 추가하려면 타입 체크하는 코드를 일일이 찾아 수정한 후 올바르게 작동하는지 테스트합니다.
  • 객체지향의 경우 코드 수정할 필요가 없으며, 간단하게 새 클래스를 상속 계층에 추가하기만 하면 됩니다.
• 변경이 주된 압력이 오퍼레이션을 추가하는 것이라면 추상 데이터 타입의 승리입니다.
  • 객체지향의 경우 새 오퍼레이션을 추가하기 위해서는 상속 계층에 속하는 모든 클래스를 한 번에 수정해야 합니다.
  • 추상 데이터 타입의 경우 전체 타입에 대한 구현 코드가 하나의 구현체 내에 포함돼 있기 때문에 새 오퍼레이션을 추가하는 작업이 상대적으로 간단합니다.

 

 

마무리

오늘은 오브젝트 책 7장을 스터디하면서 중요하다고 생각한 부분을 정리해 보았습니다.

이번 장에서는 객체를 분해하는 여러 방법들에 대해 알게 되었으며 어떤 기준으로 객체를 분해하면 좋을지 알게 되어서 좋았다고 생각이 듭니다.

하지만 객체를 분해하는 방법들에 대한 설명이 조금 빈약하지 않았나? 생각이 들어서 좀 아쉽게 느껴졌었네요.

이번 포스팅은 마무리하면서 다음 포스팅에서 뵙겠습니다.

 

 

참고

http://www.yes24.com/Product/Goods/74219491

오브젝트 - YES24