오브젝트 7장

제 7장

객체 분해

• 사람의 기억은 단기 기억과 장기 기억으로 분류할 수 있음
• 장기 기억의 공간은 무한하며 수개월, 길게는 평생을 거쳐 보관하는 저장소
• 단기 기억의 저장 개수는 5개에서 많아야 9개
• 문제를 해결하기 위해서는 필요한 정보를 장기기억 영역에서 단기기억 영역으로 불러와야 함
• 그러나 문제 해결에 필요한 정보의 수가 단기 기억 용량을 초과하는 순간 문제 해결 능력은 급격히 떨어지며 이를 인지 과부하(congnitive overload)라고 부른다.
• 이를 위해 인간의 뇌는 한 번에 다뤄야 하는 정보의 수를 줄이기 위해 추상화를 사용
• 만약 한 번에 해결하기 어려운 큰 문제라면 분해(decomposition)을 사용

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

• 프로그래밍 또한 효과적인 추상화를 이용해 복잡성을 극복하려고 시도
• 현대 프로그래밍 인어를 특징 짓는 두가지 추상화 매커니즘은 프로시저 추상화(procedure abstraction)와 데이터 추상화(data abstraction)
• 객체지향은 데이터 추상화와 프로시저 추상화를 함께 포함한 클래스를 이용해 시스템을 분해하는 개발 기법

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

• 전통적인 개발 방법론은 기능을 중심으로 분해하는 기법을 사용
• 여기서 말하는 기능의 단위는 프로시저이며 시스템은 프로시저 단위로 분해
• 전통적 개발 방법은 하향식 접근법을 사용함
• main 함수를 루트로 하는 트리 구조를 갖고 있으며 자식 노드는 부모 노드를 구현하는 절차 중의 한 단계를 의미
• main 함수를 시작으로 프로그램이 진행되어감
• 문제점
  • 그러나 이러한 개발 방법은 변경에 유연하게 대처하지 못함
  • 시스템은 하나의 메인 함수로 구성되어 있지 않음
  • 결과적으로 이 설계는 좋은 설계가 아님
  • 비즈니스 로직과 사용자 인터페이스가 결합되는 문제
  • 성급하게 결정된 실행 순서
    • 하위 함수는 상위 함수가 강요하는 문맥에서만 의미를 갖기 때문에 재사용이 어려움
    • 하향식 설계는 결합도를 높임
    • 강하게 결합된 시스템은 사소한 변경에도 전체가 흔들리는 취약한 구조를 가짐
  • 데이터 변경으로 인한 파급효과
    • 하향식 기능 분해는 어떤 데이터를 어떤 함수가 사용하고 있는지 추적하기 어려움

하향식 분해가 유용한 시점

• 이미 해결된 알고리즘이나 작은 프로그램에서 유용함

결론

• 실제 동작하는 커다란 소프트웨어를 설계하는데 하향식 설계는 적합한 방법이 아님
• 하향식 설계는 설계의 본질적 측면을 무시하고 인터페이스와 같은 비본질적 측면에 집중하게 함
• 과도하게 함수에 집중하게 함으로써 소프트웨어의 중요한 다른 측면인 데이터에 대한 영향도를 파악하기 어렵게 만듦
• 하향식 분해는 결과적으로 재사용이 어렵다.

모듈

정보 은닉과 모듈

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

• 모듈은 다음과 같은 두가지 비밀을 감춰야 한다.
  • 복잡성
  • 변경 가능성
• 정보 은닉과 데이터 캡슐화는 다름
  • 둘 다 변경과 관련된 비밀을 감춰야 하는 것은 동일
  • 그러나 데이터 캡슐화는 비밀의 한 종류인 데이터를 감추는 캡슐화의 한 종류일 뿐

모듈의 장점과 한계

장점

• 모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 미친다.
• 비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리
• 전역 변수와 전역 함수를 제거함으로써 네임스페이스 오염을 방지

단점

• 가장 큰 단점은 인스턴스의 개념을 제공하지 않음
• 개별 인스턴스를 독립적인 단위로 다룰 수 있는 추상화 메커니즘이 필요하며 이를 위해 등장한 개념이 추상 데이터 타입

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

추상 데이터 타입

• LSP (리스코프 치환 원칙)으로도 유명한 바바라 리스코프는 프로시저 추상화의 한계를 지적하고 추상 데이터 타입의 중요성을 강조했다.
• 추상 데이터 타입은 사람들이 세상을 바라보는 방식에 좀 더 근접해지도록 추상화 수준을 향상시킨다.
• 프로그래밍 언어의 과점에서 추상 데이터 타입은 프로그래밍 언어의 내장 데이터 타입과 동일하다. 단, 타입을 개발자가 정의할 수 있다는 점이 다를 뿐
• 여기까지 오면 개발자들은 머릿속에 한가지 의문이 떠오른다.
• 클래스는 추상 데이터 타입일까?

클래스

클래스는 추상 데이터 타입인가?

• 클래스는 추상 데이터 타입이 아니다.
• 클래스는 상속과 다형성을 지원하지만 추상 데이터 타입은 그러지 못하다.

변경을 기준으로 선택하라

• 객체지향은 타입 변수를 이용한 조건문을 다형성으로 대체한다.
• 추상 데이터 타입을 기반으로 하면 새로운 타입을 추가하기 위해 반드시 조건문이 들어가게 되며 이는 변경에 취약한 설계가 된다.
• 이에 반해 객체지향은 상속 계층에 추가하고 필요한 메서드를 오버라이딩 하면 변경에 유연한 코드를 만들 수 있다.
• 기존 코드에 아무런 영향도 미치지 않고 새로운 객체 유형과 행위를 추가할 수 있는 객체지향의 특성을 개방-폐쇄 원칙(Open-Closed Principle, OCP)라고 부른다.
• 만약 새로운 오퍼레이션이 빈번하게 추가되는 경우라면 추상 데이터 타입을 선택하라.
• 만약 새로운 타입을 빈번히 추가해야 한다면 객체지향의 클래스 구조가 더욱 유용하다.
• 결국 정답은 없다, 상황에 맞는 방법을 선택할 뿐

Reference

오브젝트 - 조영호