[오브젝트] 7장_객체 분해
하향식 기능 분해 -> 모듈 -> 추상 데이터 타입 -> 클래스
01 프로시저 추상화와 데이터 추상화
- 데이터 추상화
- 추상 데이터 타입 : 데이터 중심으로 타입을 추상화
- 객체지향 : 데이터 중심으로 프로시저를 추상화
02 프로시저 추상화와 기능 분해
메인 함수로서의 시스템
전통적인 기능 분해방법은 하향식 접근법이다. 즉, 최상위 기능을 좀 더 작은 단계의 하위 기능으로 분해해 나가는 방법이다.
급여 관리 시스템
모든 문장이 정제 과정을 거치면서 하나 이상의 좀 더 단순하고 구체적인 문장들의 조합으로 분해된다.
- 직원의 급여를 계산한다
- 사용자에게 소득세율을 입력 받는다
- “세율을 입력하세요 : “ 라는 문장을 화면에 출력한다
- …
- 직원의 급여를 계산한다
- 전역 변수에 저장된 직원의 기본접 정보를 얻는다
- …
- 양식에 맞게 출력한다
- …
- 사용자에게 소득세율을 입력 받는다
급여 관리 시스템 구현
하향식 기능 분해로, 시스템을 최상위의 가장 추상적인 메인함수로 정의하고 메인함수를 구현 가능한 수준까지 세부적인 단계로 분해한다. 메인함수를 루트로 하는 ‘트리’ 로 표현할 수 있다.
하향식 기능 분해의 문제점
- 하나의 메인 함수라는 비현실적 아이디어
- 새로운 요구사항이 나오면 지속적으로 새로운 기능을 추가한다. 이것은 시스템이 오직 하나의 메인 함수로 구현된다는 개념과 모순된다.
- 메인 함수의 빈번한 재설계
- 새로운 기능을 추가할 때마다 매번 메인 함수를 수정해야한다.
- 비즈니스 로직과 사용자 인터페이스 결합
- 사용자 인터페이스는 시스템에서 자주 변경되는 부분이다. 비즈니스 로직은 변경이 적게 발생한다. 하향식 접근 방법은 인터페이스와 비즈니스 로직을 섞기 때문에 사용자 인터페이스를 변경하는 경우 비즈니스 로직까지 변경에 영향을 받는다.
- 성급하게 결정된 실행 순서
- 함수들의 실행순서를 정의하는 시간 제약을 강조한다. 메인 함수가 작은 함수들로 분해되기 위해서는 우선 함수들의 순서를 결정해야한다. 문제는, 함수의 제어 구조가 빈번한 변경의 대상이라는 점이다.
- 분해된 함수들은 재사용이 어렵다
- 모든 함수는 상위 함수를 분해하는 과정에서 필요에 따라 식별되며, 그에 따라 상위 함수가 강요하는 문맥 안에서만 의미를 가지기 때문이다
- 데이터 변경으로 인한 파급 효과
- 어떤 데이터를 어떤 함수가 사용하고 있는지 추적이 어렵다. 그래서, 데이터 변경으로 인해 어떤 함수가 영향 받을지 예상이 어렵다
언제 하향식 분해가 유용한가 ?
이미 해결된 알고리즘을 문서화하고 서술하는데 훌륭한 기법이다.
03 모듈
정보 은닉과 모듈
변경을 관리하는 기본 적략은, 함꼐 변경되는 부분을 하나의 구현 단위로 묶고 퍼블릭 인터페이스를 통해서만 접근하도록 만드는 것이다.
정보 은닉은, 시스템에서 자주 변경되는 부분을 덜 변경되는 안정적인 인터페이스 뒤로 감춰야한다는 것이 핵심이다.
모듈은 다음 두가지를 감춰야한다.
복잡성
외부에 모듈을 추상화 할 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다.변경 가능성
변경 발생히, 하나의 모듈만 수정하면 되도록 변경 가능한 설계 과정을 모듈 내부로 감추고 외부에는 쉽게 견경되지 않을 인터페이스를 제공한다.
모듈의 장점과 한계
모듈은 외부에 감춰야 하는 비밀과 관련성 높은 데이터와 함수의 집합이다. 따라서, 모듈 내부는 높은 응집도를 유지한다.
모듈과 모듈 사이에는 퍼블릭 인터페이스를 통해서만 통신한다. 따라서, 낮은 결합도를 유지한다.
모듈의 장점은,
- 모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 받는다
- 비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다
- 전역변수와 전역 함수를 제거해서, 네임스페이스 오염을 방지하고 이름 충돌의 위험을 완화한다.
모듈의 단점은,
- 인스턴스 개념을 제공하지 않는다. 높은 수준의 추상화를 위해서는 직원 전체가 아니라 개별 직원을 독립적인 단위로 다룰 수 있어야 한다. 이것이 추상 데이터 타입이다.
04 데이터 추상화와 추상 데이터 타입
추상 데이터 타입
개별 직원의 인스턴스를 생성할 수 있는 Employee 추상 데이터 타입은, 전체 직원을 캡슐화하는 Employees 모듈 보다 더 개념적으로 사람들의 사고방식의 가깝다.
추상 데이터 타입을 구현하기 위해, 프로그래밍 언어는 다음 지원이 필요하다.
- 타입 정의 선언 가능해야함
- 타입의 인스턴스를 다루기 위해, 오퍼레이션의 집합을 정의할 수 있어야함
- 제공된 오퍼레이션을 통해서만 조작할 수 있도록 데이터를 외부로부터 보호 할 수 있어야함
- 타입에 대해 여러개의 인스턴스를 생성할 수 있어야함
05 클래스
클래스는 추상 데이터 타입인가 ?
동일하지 않다. 클래스는 상속과 다형성을 지원하는데, 추상데이터타입은 그렇지 않다.
추상 데이터 타입으로 구현된 Employee 타입을 보면, 하나의 타입처럼 보이는 Employee 내부에는 정규 직원과 아르바이트 직원이라는 두개의 타입이 공존한다. 하나의 대표적인 타입이 다수의 세부적인 타입을 감추기 때문에 이를, 타입 추상화 라고한다.
추상 데이터타입이 오퍼레이션을 기준으로 타입을 묶는 방법이라면, 객체지향은 타입을 기준으로 오퍼레이션을 묶는다. 객체지향은 정규 직원과 아르바이트 직원 각각에 대한 클래스를 정의하고 각 클래스들이 calculatePay 와 monthlyBasePay 오퍼레이션을 적절하게 구현한다.
정규 직원과 아르바이트 직원 두 가지 클래스로 분리하면, 공통 로직은 어디에 둘것인가 ? 공통 로직을 포함할 부모 클래스를 정의하고 두 직원 유형의 클래스가 부모 클래스를 상속 받으면 된다
추상 데이터 타입에서 클래스로 변경하기
객체지향에서는, 각 직원의 타입을 독립적인 클래스로 구현한다.
변경을 기준으로 선택하라
인스턴스 변수에 저장된 값을 기준으로 메서드 내에서 타입을 명시적으로 구분하는 방식은 객체지향을 위반한 것이다. 클래스가 추상 데이터 타입의 개념을 따른 것이다.
언제 추상 데이터 타입이, 객체 지향이 낫나 ?
타입 추가라는 변경의 압력이 강하면, 객체 지향이 낫다.
추상 데이터 타입의 경우, 새로운 타입을 추가하면 타입 체크하는 클라이언트 코드를 모두 찾아 수정해야한다.오퍼레이션 추가라는 변경의 압력이 강하면, 추상 데이터 타입이 낫다.
추상 데이터 타입은 전체 타입에 대한 구현 코드가 하나의 구현체 내에 포함돼서 새로운 오퍼레이션 추가가 간단한다.
협력이 중요하다
객체지향의 핵심 : 역함, 책임, 협력
“객체가 참여할 협력을 결정하고, 협력에 필요한 책임을 수행하기 위해, 어떤 객체가 필요한지 고민하라”
오브젝트 <조영호>