12. 다형성
다형성(Polymorphism) : Poly(많은)과 morph(형태)의 합성으로 다양한 형태를 가질 수 있는 능력을 의미한다.
매개 변수 다형성 : 인스턴스 변수나 메서드의 매개변수 타입을 임의의 타입으로 선언한 후 사용되는 시점에 구체적인 타입으로 명시하는 방식, 제네릭 프로그래밍과 관련이 깊다.
포함 다형성 : 메시지가 동일해도 수신하는 객체에 따라 다르게 행동할 수 있다.
강제 다형성 : 언어가 지원하는 타입 변환을 통해 동일한 연산자을 다양한 타입에 사용할 수 있게 해준다.
오버로딩 다형성 : 이름은 같지만 동작이 다른 메서드들이 공존할 수 있게 해준다.
상속의 매커니즘
class Lecture{
//...
public boolean LectureQuery(/*...*/) {}
//...
}
class GoodLecture extends Lecture{/*...*/}
class BadLecture extends Lecture{/*...*/}
Lecture lecture01 = new GoodLecture(); //up casting
Lecture lecture02 = new BadLecture(); //up casting
lecture01.LectureQuery() !== lecture02.LectureQuery()
// dynamic binding업캐스팅 : 부모 클래스 타입 변수에 자식 클래스 타입 인스턴스를 제약없이 대입할 수 있다.
동적 바인딩 : 위의 LectureQuery 메시지가 어떤 동작을 할지는 Lecture 타입 변수 내의 값이 누구의 인스턴스인가에 따라 달라진다.
self
self는 인스턴스 자신를 가리키는 포인터다.
인스턴스가 메시지를 수신하면 해당 메시지를 실행시키기 위해
self => class 포인터 => parent 포인터 => parent의 parent 포인터 => ... 로 최상위 부모 클래스까지 탐색을 진행한다.
이때 적합한 메서드가 발견되면 이 과정을 끝내고 해당 메서드를 실행한다.
위의 lecture01과 lecture02는 메서드 탐색 시작 지점이 다르다. 둘다 Lecture 타입 변수에 담겨있어도 lecture01은 GoodLecture부터, lecture02는 BadLecture부터 시작하기에 다른 메서드를 동작시킬 수 있다.
상속과 위임
클래스의 위임은 다른 클래스의 객체를 멤버로 갖는 형태의 클래스 정의를 의미한다.
상속을 코드 재사용, 기능 확장의 관점으로 바라보지 말고 위임의 관점으로 바라보자. 그러면 상속을 사용해도 부모 클래스와 자식 클래스 간의 의존도를 낯출 수 있을 것이다.
super 키워드를 사용하는 것은 자식 class가 부모와 그 위 class에게 특정 행위를 위임하는 것으로 여길 수 있다.
메서드 탐색 메커니즘를 기반으로 부모 클래스에서 this 키워드를 사용하는 것은 부모 class가 자식 class에 특정 행위를 위임하는 것으로 여길 수 있다.
13. 서브 타이핑과 서브 클래싱
상속의 용도
- 타입 계층 구현 : 부모 클래스는 자식 클래스의 일반화, 자식 클래스는 부모 클래스의 특수화, 서브 타이핑이라고도 부른다.
- 코드 재사용 : 부모와 자식이 강하게 결합되기 때문에 변경이 힘들다. 서브 클래싱이라고도 불린다.
상속은 객체 지향 세계의 client 관점에서 is-a 관계를 모델링할 때 사용한다. client 입장에서 부모 클래스 타입에 자식 클래스 인스턴스를 사용해도 될 때 이 관계를 구현하기 위해 상속을 사용한다.
- 추가 내용
LSP(Liskov Substitution Principle)
서브타입은 슈퍼타입을 대체할 수 있어야 한다. 특히 어휘적으로 is-a를 만족하더라도 client 관점에서 행동이 달라 is-a를 만족하지 못한다면 그 관계를 is-a라고 할 수 없다.
ISP (Interface Segreation Principle)
인터페이스를 클라이언트의 기대에 따라 분리해서 변경에 의한 영향을 제어하는 설계 원칙
타입
개념 관점에서의 타입 : 개념은 우리가 인지하는 사물의 종류, 어떤 대상이 타입으로 분류될 때 그 대상을 타입의 인스턴스라고 부른다. 개념은 심볼, 내연, 외연으로 구성되어 있다.
프로그래밍 언어 관점에서 타입 : 타입에 수행되는 오퍼레이션을 미리 정의, 타입이 수행할 수 있는 유효한 오퍼레이션 집합을 정의
객체지향 페러다임 관점에서 타입 : 객체가 수신할 수 있는 메시지 기준으로 타입을 분류함. 동일한 퍼블릭 인터페이스를 제공하는 객체들은 동일한 타입으로 분류된다.
타입 사이 포함 관계
포함하는 타입(슈퍼타입) : 외연 관점에서는 더 크고 내연 관점에서는 더 일반적이다.
포함되는 타입(서브타입) : 외연 관점에서는 더 작고 내연 관점에서는 더 특수하다.
객체 지향 세계에서는 내연의 기준이 행동(메시지)이니 퍼블릭 인터페이스의 크기가 슈퍼 타입과 서브 타입을 가리는 기준이 된다.
계약에 의한 설계와 서브타이핑
계약에 의한 설계 기본 개념.
사전 조건 : client가 server의 메서드를 실행시키기 위해 지켜야할 조건
사후 조건 : server가 client에게 보장해야 하는 조건
클래스 불변식 : 메서드 실행 전과 실행 후에 인스턴스가 만족시켜야 하는 클래스 불변식
서브타입에 더 강력한 사전 조건을 정의할 수 없다.
서브타입에 더 약한 사후 조건을 정의할 수 없다.
14. 일관성 있는 협력
유사한 요구사항을 반복적으로 수정하거나 추가할 때 객체들의 협력 구조를 서로 다르게 만들어두면 나중에 수정하거나 재사용하기 힘들어진다.
변경의 방향을 파악하기 => 변경되는 부분과 변경되지 않는 부분을 구분하기 => 변경되는 부분은 캡슐화로 숨기기 => 추상화 부분에서 협력 패턴 구상 => 구체적인 협력 구현하기
15. 디자인 패턴과 프레임워크
디자인 패턴 : 소프트웨어 설계 과정에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법
프레임 워크 : 설계와 코드를 함께 재사용하는 것.
디자인 패턴
디자인 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다. 특정 컨텍스트에서 협력 관계를 구축하기 할때 Strategy, bridge, observer 등 여러 디자인 패턴 구조를 사용할 수 있다.
패턴은 컨텍스트에 맞게 사용되어 져야 한다. 그러나 아쉽게도 패턴 그 자체로는 어떤 컨텍스트에서 쓰여야 좋은지에 대한 정보가 없다. 패턴을 맹목적으로 사용하는 것은 사용하지 않는 것보다 나쁘다. 결국은 책임 주도 설계 하에 적절한 책임을 분배해 효율적인 협력 관계를 만드는게 중요하다.
프레임워크
프레임워크 : 애플리케이션의 골격, 시스템 혹은 일부를 구현해 놓은 재사용 가능한 설계
디자인 패턴이 소프트웨어에서 코드를 제외하고 협력 구조만 차용했다면 프레임워크는 협력 구조 + 코드다. 프레임워크가 전반적인 시스템 동작과 관련된 협력을 담당하고 개발자는 비즈니스 로직을 수행할 구체적인 오퍼레이션의 구현만 담당하면 된다.
프레임워크는 사용자가 해야할 협력 관계 제어를 자기가 한다. 프레임워크를 사용하는 우리는 해당 프레임워크가 적절한 시점에 실행할 것으로 예상되는 코드를 짜면 된다.
