챕터7. 객체 분해

햐향식 기능 분해의 문제점

• 변경의 어려움
• 관계(네트워크)에 의해서 작동하는게 아니라 시간적인 절차에 의해서 작동한다
  • 즉 논리적 제약(logical constrain)에 의해 작동하는게 아니라 시간 제약(temporal constrain)로 움직인다는 것
• 비지니스 로직과 사용자 인터페이스의 결합
  • 급여를 계산하는 중요한 비지니스 로직
  • 세율을 입력받아 결과를 화면에 출력해야 하는 사용자 인터페이스
  • 둘 사이에 변경 빈도가 다르다.
  • 둘을 분리할 수 있는 방법 —> 추상화
• 데이터 변경으로 인한 파급효과
  • 어떤 데이터를 어떤 함수가 사용하고 있는지 추적하는게 매우 어려움 —> 버그와 장애 + 전역변수의 빈번함

모듈

• 정보를 은닉할 수 있다. —> 복잡성과 변경 가능성
• 모듈의 개념은 재사용과 논리적 구조를 만들 수 있다는 것
• 모듈의 장단점
  • 모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 미친다.
  • 비지니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다.
  • 전역 변수와 전역 함수를 제거함으로써 네임스페이스 오염을 방지한다.

추상 데이터 타입

• 추상데이터 타입은 모듈의 단점을 보완할 수 있다.
• 타입을 사용할 수 있다는 것은 개발자가 새로운 타입을 만들고 , 타입 인스턴스를 다룰 수 있다는 것이다. 개발 언어에 따라서 타입을 사용하는 방식이 다를 수 있다.
• 추상 데이터 타입은 오퍼레이션을 이용해 규정한다. 뒤에서 나오지만 객체지향과의 차이점은 오퍼레이션이 중심이냐, 데이터가 중심이냐 하는 축의 차이다. 추상 데이터 타입은 오퍼레이션을 단위로 움직인다. (operation cluster)
• 모듈 방식보다 추상 데이터 타입에 정의된 오퍼레이션의 시그니쳐가 더 간단하다는 것을 알 수 있다. (p.242)

클래스 (드디어!)

• 클래스는 추상데이터 타입인가? 가장 중요한 것은 클래스가 상속과 다형성을 지원한다는 것이다. 상속과 다형성이 지원되어야만 비로소 객체지향 프로그래밍이라고 할 수 있다.
• 추상 데이터 타입은 type abstraction이고 클래스는 procedural abstraction이다.
• 추상 데이터 타입에서 Employee내부에는 정규직원과 아르바이트 직원이라는 두 개의 타입이 공존하는 것
• 객체지향은 절차를 추상화 한 것이라는 의미는 다형성과 관련이 있다. 실제로 프로그램이 동작할 때 runtime에서 동일한 메시지임에도 불구하고 다른 타입(직원, 아르바이트)에 따라서 다른 절차를 수행한다. 하지만 어떤 절차인지에 대한 개념 자체는 같다(calculatePay(), monthlyBasePay())

💡 추상 데이터 타입 개념을 따를 것인지 객체지향을 따를 것인지에 대한 판정은 클래스 내부를 확인한다. 인스턴스 변수에 저장된 값을 기반으로 메서드 내에서 타입을 명시적으로 구분하는 방식은 객체지향을 위반하는 것으로 간주된다.