실제로 문제를 해결하기 위해 사용하는 저장소는 장기 기억이 아니라 단기 기억이라는 점
문제 해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 문제 해결 능력은 급격하게 떨어지고 만다.
--> 인지 과부하
과부하를 방지하는 가장 좋은 방법은 단기 기억 안에 보관할 정보의 양을 조절하는 것
불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업
--> 추상화
일반적인 추상화 방법은 한번에 다뤄야 하는 문제의 크기를 줄이는 것
큰 문제를 해결 가능한 작은 문제로 나누는 작업
--> 분해
추상화를 더 큰 규모의 추상화로 압축시켜 단기 기억의 한계를 초월할 수 있다.
프로시저 추상화와 데이터 추상화
사용하는 추상화의 종류, 추상화를 이용해 소프트웨어를 분해하는 방법
모든 프로그래밍 패러다임은 추상화와 분해 관점에서 설명 가능
- 프로시저 추상화: 소프트웨어가 무엇을 해야하는지
- 데이터 추상화: 소프트웨어가 무엇을 알아야하는지
프로시저 추상화 중심으로 시스템 분해
- 기능 분해 (알고리즘 분해)
데이터 추상화를 중심으로 시스템 분해
- 타입 추상화 (Abstract Data Type) // 추상 데이터 타입
- 프로시저 추상화 (Object-Oriented) // 객체지향
복잡성을 극복하기 위해서 효과적인 추상화 메커니즘과 분해 방법을 찾아야한다.
프로시저 추상화와 기능 분해
전통적인 기능 분해 방법은 하향식 접근법
- 세분화된 마지막 하위 기능이 구현 가능한 수준이 될 때까지 계속 분해
- 기능 분해의 결과
- 최상위 기능을 수행하는 데 필요한 절차를 실행되는 시간 순서에 따라 나열
- 유지보수 관점에서 문제가 있음
- 논리적이고 체계적인 시스템 개발 절차를 제시
- 설계가 필요한 이유는 변경에 대비하기 위한 것
- 설계를 논리적으로 설명하고 문서화하기에 용이
- 이미 완전히 이해된 사실을 서술하는데 적합
- 이미 해결된 문제를 구현할 때 사용
작은 프로그램과 개별 알고리즘을 위해서는 유용한 패러다임
모듈
변경을 관리하는 기본적인 방법
함께 변경되는 부분을 하나의 구현 단위로 묶고 퍼블릭 인터페이스를 통해서만 접근하도록 하기
기능 기반 분해가 아니라 변경의 방향에 맞춰 시스템 분해
정보 은닉
- 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 것 뒤로 감춰야 함
모듈 분해
- 감춰야 하는 비밀 선택하고 비밀 주변에 보호막 설치하는 작업
모듈의 장점과 한계
- 모듈 내부 변수가 변경돼도 모듈 내부만 영향
- 비즈니스 로직과 사용자 인터페이스에 대한 관심사 분리
- 전역 변수와 전역 함수를 제거함으로써 네임스페이스 오염을 방지
데이터 추상화와 추상 데이터 타입
타입
- 저장된 값에 대해 수행될 수 있는 연산의 집합을 결정
프로시저 추상화를 보안하기 위해 데이터 추상화
추상 데이터 타입을 구현하려면 다음과 같은 특성을 위한 프로그래밍 언어의 지원이 필요하다.
- 타입 정의를 선언할 수 있어야 한다.
- 타입의 인스턴스를 다루기 위해 사용할 수 있는 오퍼레이션의 집합을 정의할 수 있어야 한다.
- 제공된 오퍼레이션을 통해서만 조작할 수 있도록 데이터를 외부로부터 보호할 수 있어야 한다.
- 타입에 대해 여러 개의 인스턴스 생성할 수 있어야 한다.
추상 데이터 타입의 기본 의도는
프로그래밍 언어가 제공하는 타입처럼 동작하는 사용자 정의 타입을 추가할 수 있게 하는 것이다.
프로그래밍 언어의 관점에서 추상 데이터 타입은 프로그래밍 언어의 내장 데이터 타입과 동일하다.
단지 타입을 개발자가 정의할 수 있다는 점이 다를 뿐이다.
클래스
추상 데이터 타입과 클래스 공통점
- 두 메커니즘 모두 외부에서는 객체의 내부 속성에 직접 접근할 수 없으며 오직 퍼블릭 인터페이스를 통해서만 외부와 의사소통할 수 있다.
추상 데이터 타입과 클래스 차이점
- 추상 데이터 타입은 상속과 다형성을 지원하지 못한다.
상속과 다형성을 지원하는 객체지향 프로그래밍(Object-Oriented Programming)과 구분하기 위해 상속과 다형성을 지원하지 않는 추상 데이터 타입 기반의 프로그래밍 패러다임을 객체기반 프로그래밍(Object-Based Programming)이라고 부르기도 한다.
추상 데이터 타입에서 클래스로 변경하기
- 코드에 아무런 영향도 미치지 않고 새로운 객체 유형과 행위를 추가할 수 있는 객체지향의 특성을 개방-폐쇄 원칙
- 새로운 타입을 빈번하게 추가해야 한다면 객체지향의 클래스 구조가 더 유용
- 새로운 오퍼레이션을 빈번하게 추가해야 한다면 추상 데이터 타입을 선택하는 것이 현명한 판단
변경을 기준으로 선택하라
타입 추가가 빈번한가? => 객체지향
추상데이터 타입의 경우 일일이 새로운 타입에 대해 체크하는 클라이언트 코드를 수정해야 한다.
객체지향의 경우 코드 수정없이 새로운 클래스를 상속 계층에 추가하면 된다.
오퍼레이션 추가가 빈번한가? => 추상 데이터 타입
객체지향의 경우 새로운 오퍼레이션을 추가하기 위해서는 상속 계층에 속하는 모든 클래스를 한번에 수정해야 한다.
추상 데이터 타입의 경우에는 전체 타입에 대한 구현 코드가 하나의 구현체에 포함되어 있다.
따라서 새로운 오퍼레이션을 추가하는 작업이 상대적으로 간단하다
