오브젝트 13 ~ 15

13 - 서브 클래싱과 서브 타이핑

상속의 용도 [435p]

1. 타입 계층을 구현 : 부모 클래스는 자식 클래스의 일반화라고 부르고 자식 클래스는 부모 클래스의 특수화라고 부른다.
2. 코드 재사용 : 높은 확률로 강결합이기 때문에 사용하지 않는 것이 좋다.

 

객체 지향 프로그래밍에서 타입을 정의 하는 것은 객체의 퍼블릭 인터페이스를 정의하는 것과 같다. [438p]

객체를 바라볼 때 항상 객체가 외부에 제공하는 행동에 초점이 맞춰져야한다.

객체의 타입을 결정하는 것은 내부의 속성이 아니라 외부에 제공하는 행동이다. [439p]

 

슈퍼 타입 : 서브 타입이 정의 한 퍼블릭 인터페이스를 일반화 시켜 상대적으로 넓은 의미로 정의한것

서브 타입 : 슈퍼 타입이 정의 한 퍼블릭 인터페이스를 특수화 시켜 상대적으로 좁은 의미로 정의한것 [442p]

서브 타입의 인스턴스는 슈퍼타입의 인스턴스로 간주 될 수 있다. [443p]

 

상속을 어휘적인 정의로 접근하면 잘못된 상속이 이루어질 수 있다.

대표적인 예시로 is-a 관계여도 상속이 어울리지 않는 상황이 있다.

상속은 기대되는 행동에 따라 타입 계층을 구성해야한다.

상속은 is-a 관계보다 행동 호환성이 더 중요하다.

Is-a 관계는 상속을 사용할 수 있는 예비 후보 정도로 생각하라. [445p]

어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행동 호환성을 만족시켜야 한다.[453p]

행동 호환성이 지켜지지 않는다면 어휘적으로는 is-a 관계를 만족할 수 있을지 몰라도 그 관계를 is-a 라고 볼 수 없다.

is-a 는 ‘클라이언트 입장에서 is-a ’를 만족해야한다.  [458p]

 

클라이언트에따라 인터페이스를 분리하면 변경에 대한 영향을 더 세밀하게 제어할 수 있게 된다.

인터페이스를 클라이언트의 기대에 따라 분리하여 변경의 영향을 제어하는 설계 원칙을 인터페이스 분리 원칙(ISP)이라 부른다. [450p]

 

서브 클래싱 : 다른 클래스의 코드를 재사용할 목적으로 상속을 사용

서브 타이핑 : 타입 계층을 구성하기 위해 상속을 사용 [452p]

 

어떤 클래스가 다른 클래스를 상속 받으면 그 클래스의 자식 클래스또는 서브 클래스이지만 모든 서브 클래스가 서브 타입인 것은 아니다.

서브 타입을 만족하려면 슈퍼 타입의 행동이 서브 타입에 호환되어야한다. [462p]

사설) 서브 타입은 단순히 상속된 타입을 말하는게 아니라 서브 클래스 이상의 행동 호환성이 보장된 타입이다.

 

계약의 관점에서 상속이 초래하는 가장 큰 문제는 자식 클래스가 부모 클래스의 메소드를 오버라이딩 할 수 있다는 것이다.[465p]

서브 타입은 슈퍼 클래스의 사전 조건을 강화 시킬 수 없다. 

서브 타입은 슈퍼 클래스의 사전 조건을 약화 시킬 수는 있다. 

서브 타입은 슈퍼 클래스의 사후 조건을 강화 시킬 수 있다. 

서브 타입은 슈퍼 클래스의 사후 조건을 약화 시킬 수는 없다. [468p]

 

 

 

14 - 일관성 있는 협력

재사용을 위해서는 객체들의 협력 방식을 일관성 있게 만들어야 한다.[470p]

일관적이지 못한 코드는 새로운 구현을 추가해야할 때, 기존의 구현을 이해 해야할 때 문제가 된다. [485p]

유사한 기능이라면 서로 다른 방식으로 구현되어서는 안된다.

일관성없는 설계를 마주한 개발자는 여러 해결 방법중 가장 적절한 방법을 찾아야한다는 부담을 안게된다. [486p]

 

일관성있는 설계를 위한 지침

1. 변하는 개념과 변하지 않는 개념을 분리하라.
2. 변하는 개념을 캡슐화하라. [489p, 493p]

 

캡슐화란 소프트웨어에서 변할 수 있는 모든 개념을 감추는 것이다. [495p]

좋은 설계라면 새로운 기능을 추가할 때 규칙을 지키는 것 보다 어기는 것이 더 어려워진다. [508p]

유사한 기능에 유사한 협력 패턴을 적용하는 것은 객체 지향 시스템에서 개념적 무결성(=일관성)을 유지하는 가장 효과적인 방법이다. [509p]

 

 

 

15 - 디자인 패턴과 프레임 워크

패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.

Strategy 패턴 : 다양한 알고리즘을 동적으로 교체할 수 있는 역할, 책임의 집합을 제공한다.

Bridge 패턴 : 추상화의 조합으로 인한 클래스의 폭발적 증가를 막는다. 역할과 책음을 추상화와 구현 두개의 집합으로 분해한다.

Observer 패턴 : 유연한 통지 메커니즘을 구축하고 객체간의 결합도를 낮출 수 있는 역할, 책임의 집합을 제공한다. [517p]

Template 패턴 : 알고리즘을 캡슐화 하기 위해 합성이 아닌 상속 관계를 이용하는 것 

Decorator 패턴 : 객체의 행동을 동적으로 추가할 수 있게 해준다. 객체의 행동을 결합하기 위해 객체 합성을 사용한다. [520p]

Composite 패턴 : 개별 객체와 복합 객체라는 객체의 수와 관련된 변경을 캡슐화한다. [521p]

 

디자인 패턴에서 중요한 것은 디자인 패턴의 구현 방법이나 구조가 아니다. ‘어떤 디자인 패턴이 어떤 변경을 캡슐화 하는가?’이다. 

그리고 각 디자인 패턴이 캡슐화를 위해 어떤 방법을 사용 하는 가이다. [521p]

명확한 트레이드 오프 없이 패턴을 남용하면 설계가 불필요하게 복잡해진다. [522p]

패턴은 패턴을 지향하거나 패턴을 목표로 리팩토링 될 때 의미가 있다. [523p]

 

상위 정책이 세부 사항에 비해 재사용 될 가능성이 높다. 

상위 정책이 세부사항보다 더 다양한 상황에 재사용 될 수 있어야한다. 

이를 위해선 변하는 부분과 변하지 않는 부분을 별도의패키지로 분리하면 좋다.[526p]

추상화를 경계로 패키지를 분리하면 세부사항을 구현한 패키지는 항상 상위 정책을 구현한 패키지에 의존해야 하므로 좋다.[527p]

 

의존성 역전 원리 ( = IoC 원리 = Hollywood 원리)

의존성 역전 원리에 따라 구축되지 않는 시스템은 협력 흐름을 재사용 할 수도 없고 변경에 유연하게 대처할 수도 없다. [528p]

프레임워크를 사용하면 개별 어플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다. [529p]

프레임워크는 일반적인 해겲책만 제공하고 어플리케이션에 따라 달라질 수 있는 특정한 동작은 비워둔다.

그리고 이렇게 완성되지 않은 채로 남겨진 동작을 훅(Hook)이라고 부른다.

프레임워크를 사용하면 우리의 코드는 수동적인 존재다.

프레임워크가 우리의 코드를 호출해줄 때까지 기다리는 수밖에 없다.

마치 할리우드의 캐스팅 담당자가 오디션을 보러 온 배우에게 “먼저 연락하지 마세요. 저희가 연락 드리겠습니다.” 라고 말하는 것과 같다. [530p]

 

사설) 스프링 쓰면서 완전 공감되는 말…