전통적인 기능 분해 방법 : 하향식 접근법
OOP가 전통적인 기능 분해 방법에 비해 효과적이라고 말하는 이유가 무엇인가?
하향식 접근법
= 최상위 기능을 더 작은 단계의 하위 기능으로 분해해나가는 방법.
= 메인 함수부터 시작해 시스템에서 필요한 프로시저들을 만들어가는 단순한 방법
하향식 접근법의 문제점 :
- 시스템은 항상 하나의 메인 함수로 구성되지 않는다.
- 요구사항 변경과 기능 추가로 인해 메인 함수가 빈번히 수정되어야 한다. (OCP 위반)
- 비즈니스 로직이 인터페이스와 강하게 결합
- 실행 순서가 너무 이른 시기에 고정되기 때문에 함수간의 높은 결합도 -> 재사용성과 유연성 저해
- 데이터 변경에 따른 파급 효과 예측 어려움
결국 설계가 필요한 이유는 변경에 대비하기 위한 것이다.
변경은 성공적인 소프트웨어가 맞이해야 하는 피할 수 없는 운명이다.
하향식 접근법과 관련된 모든 문제의 원인은 높은 결합도이다.
함수는 상위 함수가 강요하는 문맥에 강하게 결합되며 문맥을 구성하는 다른 함수들과 시간적으로 강하게 결합된다.
하향식 접근법의 대안 : 모듈
모듈과 정보 은닉
시스템을 모듈 단위로 어떻게 분해할 것인가?
모듈은 다음 두 가지 비밀을 감춰야 한다. 즉 정보 은닉을 해야 한다.
- 복잡성 : 모듈이 너무 복잡할 경우 이해하고 사용하기가 어렵다. 간단한 인터페이스를 제공해 모듈의 복잡도를 낮춰야 한다.
- 변경 가능성 : 모듈의 세부 사항을 내부로 감추고, 외부에는 쉽게 변경되지 않을 인터페이스를 제공해야 한다.
모듈의 장점
- 데이터 변경으로 인한 파급효과를 제어할 수 있기 때문에 코드를 수정하고 디버깅하기 용이하다.
- 네임 스페이스를 제공.
- 높은 응집도와 낮은 결합도
모듈은 변경의 정도에 따라 시스템을 분해하게 하며 외부로부터 데이터를 감춘다.
따라서 모듈 내부는 높은 응집도를 유지하며, 모듈과 모듈 사이에는 퍼블릭 인터페이스를 통해서만 통신해야 하기 때문에 낮은 결합도를 유지할 수 있게 된다.
돌고 돌아 OOP : 클래스와 추상 데이터 타입의 차이점
클래스는 상속과 다형성을 지원하지만 추상 데이터 타입은 지원하지 못한다.
추상 데이터 타입은 타입을 추상화(캡슐화)한 것이고 클래스는 절차를 추상화(캡슐화)한 것이다.
추상 데이터 타입이 오퍼레이션을 기준으로 타입을 묶는 것이라면, 클래스는 타입을 기준으로 오퍼레이션을 묶은 것이다.
클래스는 타입들의 공통 로직을 부모 클래스에 정의하고 자식 클래스(타입)들이 상속받게 한다.
클라이언트 코드는 부모 클래스의 오퍼레이션에 따라 메시지를 전송하고, 실제 클래스가 무엇인지 런타임에 결정되어 클래스별로 절차가 실행된다.
이것이 다형성이다.
다형성은 절차에 대한 클래스간의 차이점을 감춘다.
즉, OOP는 절차 추상화 이다.
이처럼 기존 클라이언트 코드에 영향을 미치지 않고 객체 타입과 행위를 추가할 수 있는 객체지향의 특성을 OCP라고 한다.
그러나 OOP가 언제나 올바른 해결 방법은 아니다.
만약 변경의 주된 압력이 오퍼레이션을 추가하는 것이라면 OOP의 다형성은 오히려 독이 된다.
Employee에 오퍼레이션이 추가될 때마다 모든 서브 클래스에 해당 오퍼레이션을 오버라이딩해야 한다.
'CS > OOP' 카테고리의 다른 글
[오브젝트] 9장 : 유연한 설계를 하려면 OCP, DIP를 지켜라 (0) | 2024.02.01 |
---|---|
[오브젝트] 8장 - 좋은 의존성과 나쁜 의존성 (0) | 2024.01.29 |
[오브젝트] 6장 - 메시지와 인터페이스 (0) | 2024.01.22 |
[오브젝트] 5장 : 책임 할당과 책임 중심 설계 (0) | 2024.01.18 |
[오브젝트] 4장 - 데이터 중심 설계의 문제점과 캡슐화 (0) | 2024.01.15 |