[오브젝트] 챕터 7 - 객체 분해

이번 챕터는 추상화와 분해에 대해서 알아보는 시간이었습니다.

저는 추상화라고 하면 어느 순간부터 abstract class니 interface니 하는 구현에 관련된 생각으로 시야가 좁아졌었나 봅니다.

 

추상화는 왜 하는 것일까요? Open Closed 원칙을 지키기 위해서 일까요? 아니죠. 결국에는 사람이 쉽게 이해하는 코드를 만들기 위해서 나온 개념입니다.

사람은 너무 많은 세부사항을 한번에 기억할 수 없습니다. 적어도 저는 그렇습니다. 비즈니스 로직 작업을 하면서 동시에 화면에 어떻게 그리고 애니메이션 될 지 고민하면 작업이 진행이 도무지 안됩니다. 비즈니스 로직 작업 및 검증 따로, 비즈니스 로직이 정상 동작한다 생각하고 화면 작업 따로 진행합니다. 그래야 일이 진행이 됩니다.

 

이게 바로 추상화입니다. 별로 대단한 게 없네요. 저는 디자인 패턴이니 아키텍쳐니 하는 방법론에 매료된 나머지 추상화를 엄청 대단한 테크닉으로 생각하고 as abstract as possible을 외친 적도 있었죠. (부끄럽네요.)

 

이번 챕터는 그러한 추상화를 달성하기 위해 제안된 방법론들에 대해서 다룹니다. 추상화는 결국 복잡하고 모호한 상위 개념을 더 구체적인 하위 개념의 집합으로 나누어 생각하는 겁니다. 그래요. 나누어 생각하다 분해(decomposition)라고 하죠.

 

분해를 어떻게 할 것인가? 가 이번 챕터에서 볼 수 있는 내용입니다. (아래 정리 내용 참조)

 

타입 추상화와 절차 추상화를 다루는 내용은 압권이였습니다.

ADT의 타입 추상화 개념은 여러 타입을 하나의 물리적 타입으로 묶은 개념을 말하는 것이였고, 제가 실무에서도 항상 하는 작업이였습니다. ADT가 OO가 아니라니! (Object-Based라고 주장함)

---

• 인지 과부화를 방지하는 가장 좋은 방법은 한번에 기억해야하는 양을 조절하는 것
• 추상화: 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업
• 분해(decomposition): 큰 문제를 해결 가능한 작은 문제로 나누는 작업
• 추상화를 더 큰 규모의 추상화로 압축시켜 단기 기억의 한계를 초월할 수 있다.
• 프로시저 추상화와 데이터 추상화
  • 사용하는 추상화의 종류, 추상화를 이용해 소프트웨어를 분해하는 방법
  • 모든 프로그래밍 패러다임은 추상화와 분해 관점에서 설명 가능
  • 프로시저 추상화: 소프트웨어가 무엇을 해야하는지
  • 데이터 추상화: 소프트웨어가 무엇을 알아야하는지
  • 프로시저 추상화 중심으로 시스템 분해
    • 기능 분해, 알고리즘 분해
  • 데이터 추상화를 중심으로 시스템 분해
    • 타입 추상화 (Abstract Data Type)
    • 프로시저 추상화 (Object-Oriented)
  1. 기능 구현을 위해 필요한 객체 식별
  2. 협력 가능하도록 시스템 분해
  3. 프로그래밍 언어를 수단으로 실행가능한 프로그램 구현
  • 복잡성을 극복하기 위해서 → 효과적인 추상화 메커니즘, 분해 방법을 찾아야함.
  • 이러한 관점에서 객체지향을 평가해보자.
• 프로시저 추상화와 기능 분해
  • 하향식 접근법 (Top-Down)
  • 세분화된 마지막 하위 기능이 구현 가능한 수준이 될 때까지 계속 분해
  • 추상적인 상위 기능은 좀 더 구체적인 하위 기능의 집합으로 분해된다.
  • 기능 분해의 결과 → 최상위 기능을 수행하는 데 필요한 절차를 실행되는 시간 순서에 따라 나열함.
  • 유지보수 관점에서 문제가 있음.
  • 논리적이고 체계적인 시스템 개발 절차를 제시한다.
  • 설계가 필요한 이유는 변경에 대비하기 위한 것
  • 설계를 논리적으로 설명하고 문서화하기에 용이하다.
  • 이미 완전히 이해된 사실을 서술하는데 적합
  • 이미 해결된 문제를 구현할 때 사용한다.
  • 작은 프로그램과 개별 알고리즘을 위해서는 유용한 패러다임
• 모듈
  • 변경을 관리하는 기본적인 방법
  • 함께 변경되는 부분을 하나의 구현 단위로 묶고 퍼블릭 인터페이스를 통해서만 접근하도록 하기
  • 기능 기반 분해가 아니라 변경의 방향에 맞춰 시스템 분해
  • 정보 은닉 (information hiding)
    • 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 것 뒤로 감춰야 한다.
  • 모듈 분해 → 감춰야 하는 비밀 선택하고 비밀 주변에 보호막 설치하는 작업
  • 복잡성, 변경 가능성을 감춰야함.
  • 모듈이 너무 복잡한 경우, 이해하고 사용하기 어렵다.
  • 변경 가능한 설계 결정이 외부에 노출될 경우 변경시 파급효과가 크다.
  • 모듈의 장점 & 단점
    • 변경 파급효과의 국소화: 모듈 내부 변수가 변경돼도 모듈 내부만 영향
    • 의미 단위로 코드 분리와 관리: 비즈니스 로직과 사용자 인터페이스에 대한 관심사 분리
    • 네임스페이스 오염 방지: 모듈 내에서 의미있는 이름을 사용가능
    • 모듈 내부 → 높은 응집도
    • 모듈과 모듈은 퍼블릭 인터페이스를 통해서만 통신 → 낮은 결합도
    • 데이터의 존재를 설계의 중심 요소로 부각
    • 인스턴스 개념이 없음
• 데이터 추상화와 추상 데이터 타입
  • 타입: 저장된 값에 대해 수행될 수 있는 연산의 집합을 결정
  • 데이터 추상화: ADT는 사용할 수 있는 오퍼레이션을 이용해 규정됨, 외부에 제공하는 행위에만 관심을 가짐, 세부적인 사항은 무시
  1. 어떤 데이터를 감추기 위해 데이터 추상화가 필요한가?
  2. ADT에 적용할 수 있는 오퍼레이션은 무엇인가?
  • 데이터와 기능을 분리해서 바라본다.
  • 기능을 구현하는 핵심 로직은 추상 데이터 타입 외부에 존재
  • 프로그래밍 언어가 제공하는 타입처럼 동작하는 사용자 정의 타입을 추가할 수 있다는 것!
• 클래스
  • 상속과 다형성을 지원함
  • 절차를 추상화 함
  • ADT → 타입 추상화 → 하나의 물리적인 타입 안에 전체 타입을 감춘다.
  • 객체 지향 → 실행 절차를 세부 타입에 분배
  • 개념적 타입을 독립적인 클래스로 구현함으로써 여러 타입이 존재한다는 사실을 명시적으로 표현한다.
  • 변경을 기준으로 선택하라
    • 객체 지향이라면 타입을 기준으로 절차를 추상화
    • 클래스 내부에 타입을 표현하는 변수가 있는지 살피자.
    • 변경의 축이 어디인가? → 타입 추가인가? 오퍼레이션 추가인가?
      • 새로운 타입을 빈번하게 추가해야하는 경우는 어떤 경우임?
      • 새로운 오퍼레이터를 빈번하게 추가하는 건 무슨 얘기임?