'오브젝트' 책 보고 공부하기 - ⑦ 객체 분해

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

프로시저 추상화: 

 

알고리즘, 기능을 중심으로 시스템을 추상화

 

 

데이터 추상화: 

 

데이터 중심으로 타입을 추상화 - 추상 데이터 타입 

데이터를 중심으로 프로시저를 추상화 - 객체지향

 

객체지향을 바라보는 일반적인 관점은 데이터 추상화와 프로시저 추상화를 함께 포함한 클래스를 이용해

시스템을 분해하는 것

 

---

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

기능과 데이터에서 처음은 기능의 우위였다. 기능 분해를 통해 시스템을 분해를 하였으며, 이 프로시저 단위로 분해된 것은

인터페이스를 통해 사용할 수 있었다.

(프로시저는 반복적으로 실행 혹은 유사하게 실행되는 작업들을 하나의 장소에 모아놓은 추상화 방법이다.)

 

전통적으로 기능 분해 방법은 하향식 접근법(최상위 기능 정의 후 작은 단위의 하위 기능으로 분해해나가는 방법)을 사용했다.

(개인적인 생각으로는 이 방식이 일반적인 사람이 정책을 생각하는 방법과 많이 닮아 있다 생각한다.)

 

책에서는 급여관리 시스템의 예시를 데이터 중심으로 설계한 후 문제점을 알려준다.

 

첫번째는 하나의 메인 함수를 통해 로직이 구성되어있는 것을 이야기한다.

이는 곧 기능추가에 대해 메인 함수를 재설계를 해야한다는 것을 알려주며, 기능 추가시마다 재설계해야하는 것은 매한가지다.

 

두번째는 비즈니스 로직과 사용자 인터페이스 결합을 이야기한다.

~~를 입력받고 계산 후 결과를 화면에 출력한다. 즉, 비즈니스 로직 진행중 중간중간에 사용자의 개입이 필요하다는 것이다.

인터페이스 변경시에 또다시 재설계를 해야하는 문제점이 발생한다.

 

세번째는 성급하게 결정된 실행 순서 이다.

무엇이 아닌 어떻게에 집중이 되다 보니 문맥의 흐름에 강하게 결합되어있다. 즉, 함께 절차를 구성하는 다른 함수들과

시간적으로 강하게 결합되어있다. 이렇게 되다보니 재사용성이 많이 떨어지게 된다.

 

네번째는 데이터 변경으로 인한 파급효과 이다.

어떤 데이터를 어떤 함수가 사용하고 있는지를 추적하기 어렵다. 데이터를 바꾸는 순간 다른 함수에 영향이 갈수도 있어

해당 데이터를 사용하는 곳을 샅샅이 찾아보아야한다.

이를 최소화 하려면 변경되는 부분을 하나의 구현단위로 묶고 외부에서 제공되는 함수만 이용해 데이터에 접근하도록 해야한다.

 

하향식 접근법은 이미 해결된 알고리즘을 문서화하고 서술하는데 훌륭한 기법이지만,

실제로 동작하는 커다란 소프트웨어를 설계하는데적합한 방법은 아니다.

 

---

 

3) 모듈

정보은닉

 

시스템을 모듈단위로 분해하기 위한 기본 원리로 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인

인터페이스 뒤로 감춰야한다는 것

 

 

모듈 분해

 

감춰야 하는 비밀(복잡성, 변경 가능성)을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존 과정

일반적인 비밀은 데이터이며, 모듈 분해 후 기능 분해를 이용해 모듈에 필요한 퍼블릭 인터페이스를 구현 할 수 있다.

 

 

기능 분해

하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정

 

 

모듈의 장점

1. 모듈 내부의 변수가 변경되더라도 모듈 내부만 영향이 간다.

2. 비즈니스 로직과 인터페이스를 분리

3. 전역변수, 전역함수로부터 네임스페이스 오염 방지한다.

 

 

모듈의 단점

인스턴스 개념을 제공하지 않는다. (개별의 개념이 존재하지 않음)

 

 

---

 

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

 

데이터 추상화

 

바바리 리스코프가 정의한 데이터 추상화는 추상 객체의 클래스이며, 추상 객체에 사용할 수 있는 오퍼레이션을 이용해 규정된다.

추상 데이터 타입을 구현할때 필요한 프로그램이 언어적 지원은 다음과 같다.

- 타입 정의를 선언할 수 있어야한다.

- 타입의 인스턴스를 다루기 위해 사용할 수 있는 오퍼레이션의 집합을 정의할 수 있어야한다.

- 제공된 오퍼레이션을 통해서만 조작할 수 있도록 데이터를 외부로부터 보호할 수 있어야한다.

- 타입에 대해 여러개의 인스턴스를 생성할 수 있어야 한다.

 

추상 데이터 타입을 기반으로 객체 생성은 가능하지만, 데이터와 기능을 분리해서 바라본다. 아직 절차적 프로그래밍에서

벗어나지 못했기 때문에 객체지향과 같은 의미로 생각해서는 안된다.

 

---

 

5) 클래스

 

추상 데이터 타입

 

1.상속, 다형성 지원 하지않음

2.타입을 추상화

3.오퍼레이션을 기준으로 타입을 묶는다.

 

VS

 

클래스

 

1.상속, 다형성 지원 

2.절차를 추상화

3. 타입을 기준으로 오퍼레이션을 묶는다. (구현 내용이 제각각 선언된다.)

4. 공통 로직을 어디에 둘때 사용하는 방법으로 부모 클래스에 의해 상속받아 구현되게 할 수 있다. (다형성)

 

클래스가 추상 데이터 타입의 개념을 따르는지 확인할 수 있는 간단한 방법 - 인스턴스 타입을 표현하는 변수가 있는지

타입 필드에 따라 클래스 유형이 달라진다면 객체지향을 위반하는 것이다.

 

객체지향에서는 타입 변수를 이용해 조건문을 다형성으로 대체하는데, 클라이언트가 객체 타입을 확인하고 메서드를 호출하는

것이아닌 객체가 메시지를 처리할 메서드를 직접 선택하는 것이다.

 

조건문은 변경에 취약하기 때문에 기피하는 것이 좋다.

이는 개방폐쇄 원칙(OCP[Open-Closed-Principle])과 연결되어있다.

 

타입추가라는 변경이 압력이 더 강한 경우에는 객체지향

오퍼레이션 추가라는 변경 압력이 더 강한 경우에는 추상 데이터 타입 이 좋을 수 있다.

 

항상 협력을 생각하자, 무작정 절차를 추상화 하기보다 책임주도 설계를 통한 협력을 이끌어 내서 설계를 하자.

협력에 필요한 책임을 수행하기 위해 어떤 객체가 필요한지 생각하고, 그 책임이 다양한 방식으로 수행해야할 때 타입 계층안에서

각 절차를 추상화하자(다형성을 사용하기도하며)