상속(개체 지향 프로그래밍)

Inheritance (object-oriented programming)

객체 지향 프로그래밍에서 상속은 객체 또는 클래스를 다른 객체(프로토타입 기반 상속) 또는 클래스(클래스 기반 상속)에 기반하여 유사한 구현을 유지하는 메커니즘입니다.또한 슈퍼 클래스나 기본 클래스 등의 기존 클래스(하위 클래스)에서 새로운 클래스(하위 클래스)를 도출하여 클래스 계층으로 형성하는 것으로 정의됩니다.대부분의 클래스 기반 객체 지향 언어에서, 상속을 통해 생성된 객체인 "하위 객체"는 기본 클래스의 생성자, 파괴자, 과부하 연산자 및 친구 함수를 제외하고 "부모 객체"의 모든 속성과 동작을 획득합니다.상속을 통해 프로그래머는 기존 [1]클래스에 구축된 클래스를 만들고 동일한 동작을 유지하면서 새로운 구현을 지정하며(인터페이스 실현), 코드를 재사용하고 퍼블릭클래스 및 인터페이스를 통해 원본 소프트웨어를 독립적으로 확장할 수 있습니다.상속을 통한 객체 또는 클래스의 관계는 방향 비순환 그래프를 생성합니다.

상속은 1969년 Simula를 위해[2] 발명되었으며 현재 Java, C++, PHP 및 Python과 같은 많은 객체 지향 프로그래밍 언어에서 사용되고 있습니다.

상속된 클래스를 부모 클래스 또는 슈퍼 클래스의 하위 클래스라고 합니다.상속이라는 용어는 클래스 기반 프로그래밍과 프로토타입 기반 프로그래밍 모두에서 느슨하게 사용되지만 좁은 사용에서는 클래스 기반 프로그래밍(한 클래스가 다른 클래스에서 상속됨)을 위해 예약되며 프로토타입 기반 프로그래밍의 해당 기술을 위임(한 개체 위임)이라고 합니다.

상속은 서브타이핑과 [3][4]혼동해서는 안 됩니다.일부 언어에서는 상속과 서브타이핑이 [a]일치하는 반면 다른 언어에서는 다르다.일반적으로 서브타이핑은 is-a 관계를 확립하는 반면, 상속은 실행만을 재사용하고 구문 관계를 확립할 뿐 반드시 의미 관계를 확립할 필요는 없다(상속한다고 해서 행동 서브타이핑이 보장되는 것은 아니다).이러한 개념을 구별하기 위해 서브타이핑은 인터페이스 상속(타입 변수의 전문화가 서브타이핑 관계를 유도하는 것을 인식하지 않음)이라고 불리기도 하지만, 여기서 정의되는 상속은 구현 상속 또는 코드 [5]상속이라고 불립니다.그러나 상속은 하위 유형 [6]관계를 확립하기 위해 일반적으로 사용되는 메커니즘입니다.

상속은 한 개체가 다른 개체를 포함하는 개체 구성(또는 한 클래스의 개체가 다른 클래스의 개체를 포함하는 경우)과 대조됩니다. 상속보다 구성을 참조하십시오.구성은 서브타이핑의 is-a 관계와는 대조적으로 has-a 관계를 구현한다.

종류들

단일 상속
다중 상속

유전에는 패러다임과 특정 [7]언어에 기초한 다양한 유형이 있습니다.

단일 상속
여기서 서브클래스는 하나의 슈퍼클래스의 기능을 상속합니다.클래스는 다른 클래스의 속성을 가져옵니다.
다중 상속
여기서 하나의 클래스는 둘 이상의 슈퍼 클래스를 가질 수 있으며 모든 부모 클래스에서 기능을 상속할 수 있습니다.

「다중 상속은, 효율적인 실장이 매우 어렵다고 하는 것이 일반적입니다.예를 들어, 목표 C에 대한 그의 책에서, 브래드 콕스는 실제로 C++에 다중 상속을 추가하는 것은 불가능하다고 주장했다.따라서 다중 상속은 더 어려워 보였다.1982년부터 다중 상속을 검토하여 1984년에 간단하고 효율적인 구현 기술을 발견했기 때문에 도전을 피할 수 없었습니다.패션이 사건의 [8]연속에 영향을 준 유일한 사례라고 생각한다.

--
다단계 상속
여기서 서브클래스는 다른 서브클래스에서 상속됩니다.그림 "다단계 상속"에서와 같이 클래스가 다른 파생 클래스에서 파생되는 것은 드문 일이 아닙니다.
다단계 상속
클래스 A는 파생 클래스 B의 베이스 클래스로서 기능하며, 파생 클래스 C의 베이스 클래스로서 기능합니다.클래스 B는 A와 C 사이의 상속 링크를 제공하기 때문에 중간 베이스 클래스라고 불립니다.체인 ABC는 상속 경로로 알려져 있습니다.
다단계 상속을 포함하는 파생 클래스는 다음과 같이 선언됩니다.
학급 A { ... };      // 베이스 클래스 학급 B : 일반의 A { ... };   // A에서 파생된 B 학급 C : 일반의 B { ... };   // B에서 파생된 C
이 프로세스는 임의의 수의 레벨로 확장할 수 있습니다.
계층적 상속
여기서, 1개의 클래스가 복수의 서브 클래스의 슈퍼 클래스(베이스 클래스)로서 기능합니다.예를 들어 부모 클래스 A에는 2개의 서브 클래스 B와 C가 있을 수 있습니다.B와 C의 부모 클래스는 모두 A이지만 B와 C는 2개의 독립된 서브 클래스입니다.
하이브리드 상속
하이브리드 상속은 위의 두 가지 이상의 상속 유형이 혼합된 경우입니다.예를 들어 클래스 A에 2개의 서브클래스 C와 D가 있는 서브클래스 B가 있는 경우를 들 수 있습니다.이는 다단계 상속과 계층 상속의 혼합입니다.

서브클래스 및 슈퍼클래스

하위 클래스, 파생 클래스, 상속 클래스 또는 자식 클래스는 하나 이상의 다른 클래스(슈퍼 클래스, 기본 클래스 또는 부모 클래스)에서 하나 이상의 언어 엔티티를 상속하는 모듈러 파생 클래스입니다.클래스 상속의 의미는 언어에 따라 다르지만 일반적으로 하위 클래스는 해당 슈퍼 클래스의 인스턴스 변수와 멤버 함수를 자동으로 상속합니다.

파생 클래스를 정의하는 일반적인 형식은 다음과 같습니다.[9]

학급 서브클래스: 가시성 슈퍼 클래스 {     // 서브클래스 멤버 };
  • 콜론은 서브클래스가 슈퍼클래스에서 상속됨을 나타냅니다.가시성은 옵션이며, 존재하는 경우 비공개 또는 공용일 수 있습니다.기본 표시는 비공개입니다.가시성은 기본 클래스의 기능이 비공개로 파생되었는지 또는 공개적으로 파생되었는지 여부를 지정합니다.

일부 언어는 다른 구성 요소의 상속도 지원합니다.예를 들어 에펠에서는 등급의 사양을 정의하는 계약도 상속인에 의해 상속된다.슈퍼클래스는 공통 인터페이스와 기본 기능을 확립합니다.특화된 서브클래스는 상속, 변경 및 보완할 수 있습니다.하위 클래스에서 상속된 소프트웨어는 하위 클래스에서 재사용된 것으로 간주됩니다.클래스의 인스턴스에 대한 참조는 실제로 해당 서브클래스 중 하나를 참조하는 것일 수 있습니다.참조되는 객체의 실제 클래스는 컴파일 시에 예측할 수 없습니다.균일한 인터페이스는 여러 클래스의 객체의 멤버 함수를 호출하기 위해 사용됩니다.서브클래스는 슈퍼클래스 함수를 같은 메서드시그니처를 공유해야 하는 완전히 새로운 함수로 대체할 수 있습니다.

서브클래스 불가

일부 언어에서는 클래스 선언에 특정 클래스 수식자를 추가하여 클래스가 비하위 클래스로 선언될 수 있습니다.예를 들어final키워드 또는 C++11 이후 또는sealed키워드를 지정합니다.이러한 수식어가 클래스 선언에 추가된 후class키워드 및 클래스 ID 선언을 지정합니다.이러한 분류 불가능한 클래스는 재사용 가능성을 제한하며, 특히 개발자가 소스 코드가 아닌 미리 컴파일된 이진 파일에만 액세스할 수 있는 경우에는 더욱 그렇습니다.

서브클래스 이외의 클래스에는 서브클래스가 없기 때문에 해당 클래스의 오브젝트에 대한 참조 또는 포인터는 서브클래스 인스턴스(존재하지 않음)나 슈퍼클래스 인스턴스(레퍼런스유형 업캐스트는 타입시스템에 위반됨)가 아닌 실제로 해당 클래스의 인스턴스를 참조하고 있음을 컴파일 시에 쉽게 추론할 수 있습니다.참조되는 객체의 정확한 유형은 실행 전에 이미 알고 있기 때문에 레이트바인딩(다이나믹디스패치라고도 함) 대신 얼리바인딩(스태틱디스패치라고도 함)을 사용할 수 있습니다.이것에 의해, 복수의 상속이 서포트되고 있는지, 또는 1개의 상속만이 프로그램내에서 서포트되고 있는지에 따라, 1개 이상의 가상 메서드테이블 룩업이 필요하게 됩니다.g 사용 중인 언어.

덮어쓸 수 없는 메서드

클래스가 서브클래스가 아닌 것처럼 메서드 선언에는 메서드가 오버라이드되지 않도록 하는 메서드 수식자가 포함될 수 있습니다(즉, 서브클래스의 동일한 이름과 타입 시그니처의 새로운 함수로 대체됨).프라이빗 메서드는 단순히 멤버함수인 클래스 이외의 클래스에서 액세스 할 수 없기 때문에 덮어쓸 수 없습니다(단, C++의 경우는 해당되지 않습니다).afinal자바에서의 메서드sealedC# 또는 a의 메서드frozen에펠의 기능은 재정의할 수 없습니다.

가상 방식

superclass 메서드가 가상 메서드일 경우 superclass 메서드의 호출이 동적으로 디스패치됩니다.일부 언어에서는 메서드를 virtual(예: C++)으로 명시적으로 선언해야 하며, 다른 언어에서는 모든 메서드가 virtual(예: Java)입니다.비가상 메서드의 호출은 항상 정적으로 디스패치됩니다(즉, 함수 호출의 주소는 컴파일 시에 결정됩니다).스태틱 디스패치는 다이내믹 디스패치보다 고속으로 인라인 확장 등의 최적화가 가능합니다.

상속된 구성원의 가시성

다음 표는 클래스를 [10]파생할 때 주어진 가시성에 따라 상속되는 변수 및 함수를 보여 줍니다.

베이스 클래스 가시성 파생 클래스 가시성
공적 파생상품 개인 파생상품 파생상품 보호
  • 개인 →
  • 보호됨 →
  • 공용 →
  • 상속되지 않음
  • 보호되고 있다
  • 일반의
  • 상속되지 않음
  • 사적인
  • 사적인
  • 상속되지 않음
  • 보호되고 있다
  • 보호되고 있다

적용들

상속은 두 개 이상의 클래스를 서로 상호 관련짓기 위해 사용됩니다.

덮어쓰기

주요 기사:메서드 덮어쓰기
메서드 덮어쓰기 그림

많은 객체 지향 프로그래밍 언어는 클래스 또는 객체가 상속된 측면(일반적으로 동작)의 구현을 대체할 수 있도록 합니다.이 프로세스를 덮어쓰기라고 합니다.덮어쓰기에는 복잡성이 생깁니다.상속된 클래스의 인스턴스가 사용하는 동작의 버전은 자신의 클래스의 일부입니까, 부모(베이스) 클래스의 인스턴스입니까?답은 프로그래밍 언어에 따라 다르며, 일부 언어에서는 특정 동작이 재정의되지 않고 기본 클래스에서 정의된 대로 동작해야 함을 나타내는 기능을 제공합니다.예를 들어 C#에서는 기본 메서드 또는 속성이 가상, 추상 또는 오버라이드 수식자로 표시된 경우에만 서브클래스에서 오버라이드할 수 있습니다.또한 Java 등의 프로그래밍 언어에서는 다른 메서드를 호출하여 다른 [11]메서드를 오버라이드할 수 있습니다.덮어쓰기 대신 상속된 코드를 숨기는 방법이 있습니다.

코드 재사용

구현 상속은 하위 클래스가 기본 클래스의 코드를 재사용하는 메커니즘입니다.기본적으로 하위 클래스는 기본 클래스의 모든 작업을 유지하지만 하위 클래스가 일부 또는 모든 작업을 재정의하여 기본 클래스 구현을 자체 작업으로 대체할 수 있습니다.

다음 Python 예제에서는 서브클래스가SquareSumComputer 및 CubeSumComputer는 기본 클래스 SumComputer의 transform() 메서드를 덮어씁니다.기본 클래스는 두 정수 사이의 제곱 합계를 계산하는 연산으로 구성됩니다.하위 클래스는 숫자를 제곱으로 변환하는 연산을 제외하고 기본 클래스의 모든 기능을 재사용하여 숫자를 제곱과 큐브로 각각 변환하는 연산으로 대체합니다.따라서 하위 클래스는 두 정수 사이의 제곱/입방체의 합을 계산합니다.

다음은 Python의 예입니다. 

학급 Sum Computer(섬 컴퓨터):     방어하다 __init__(자신, a, b):         자신.a = a         자신.b = b      방어하다 변혁(자신, x):         올리다 구현되지 않은 오류      방어하다 입력(자신):         돌아가다 범위(자신.a, 자신.b)      방어하다 계산하다(자신):         돌아가다 합(자신.변혁(가치) 위해서 가치 에 자신.입력())  학급 Square Sum 컴퓨터(Sum Computer(섬 컴퓨터)):     방어하다 변혁(자신, x):         돌아가다 x * x  학급 큐브섬 컴퓨터(Sum Computer(섬 컴퓨터)):     방어하다 변혁(자신, x):         돌아가다 x * x * x

대부분의 분기에서는 코드 재사용만을 목적으로 한 클래스 상속이 [citation needed]선호되지 않습니다.주된 우려 사항은 구현 상속이 다형 치환성을 보장하지 않는다는 것입니다.재사용 클래스의 인스턴스를 상속 클래스의 인스턴스로 대체할 필요는 없습니다.대체 기술인 명시적 위임은 더 많은 프로그래밍 노력을 요구하지만 대체 가능성 문제는 [citation needed]피합니다.C++에서는 개인 상속을 대체 가능성 없이 구현 상속의 형태로 사용할 수 있습니다.공공 상속은 "있는" 관계를 나타내고 위임은 "있는" 관계를 나타내는 반면, 개인(및 보호된) 상속은 "있는" 관계로 [12]간주될 수 있습니다.

상속의 또 다른 빈번한 사용법은 클래스가 특정 공통 인터페이스를 유지하도록 보장하는 것입니다.즉, 클래스는 동일한 메서드를 구현합니다.부모 클래스는 구현된 작업과 자식 클래스에서 구현되는 작업의 조합일 수 있습니다.대부분의 경우 슈퍼타입과 서브타입 사이에는 인터페이스가 변경되지 않습니다.자녀가 부모 [13]클래스 대신 설명한 동작을 구현합니다.

상속과 서브타이핑

상세 정보:서브타이핑

상속은 서브타이핑과 비슷하지만 [3]서브타이핑과는 다릅니다.서브타이핑은 특정 유형을 다른 유형 또는 추상화로 대체할 수 있도록 하며, 언어 지원에 따라 암묵적 또는 명시적으로 하위 유형과 일부 기존 추상화 간의 관계를 확립하는 것으로 알려져 있습니다.관계는 서브타이핑 메커니즘으로 상속을 지원하는 언어로 상속을 통해 명시적으로 표현될 수 있습니다.예를 들어, 다음의 C++ 코드는 클래스 B와 A 사이에 명시적인 상속 관계를 확립합니다.여기서 B는 A의 서브 클래스이자 서브 타입이며, B가 지정되어 있는 곳(참조, 포인터 또는 오브젝트 자체를 통해)에 관계없이 A로 사용할 수 있습니다. 

학급 A {  일반의:   무효 어떻게 좀 해봐.똑같아() 컨스턴트 {} };  학급 B : 일반의 A {  일반의:   무효 DoSomethingBLIKE() 컨스턴트 {} };  무효 UseAnA(컨스턴트 A& a) {   a.어떻게 좀 해봐.똑같아(); }  무효 Some Func() {   B b;   UseAnA(b);  // b는 A를 대체할 수 있습니다. }

서브타이핑 메커니즘으로서의 상속을 지원하지 않는 프로그래밍 언어에서 기본 클래스와 파생 클래스 간의 관계는 유형 간의 관계에 비해 구현 간의 관계(코드 재사용을 위한 메커니즘)일 뿐입니다.서브타이핑 메커니즘으로 상속을 지원하는 프로그래밍 언어에서도 상속이 반드시 동작 서브타이핑을 수반하는 것은 아닙니다.부모 클래스가 예상되는 컨텍스트에서 사용할 때 오브젝트가 올바르게 동작하지 않는 클래스를 도출할 수 있습니다.Liskov 치환 원칙을 참조해 주세요.(비교 함축/표현)일부 OOP 언어에서는 코드 재사용과 서브타이핑의 개념이 일치합니다.왜냐하면 서브타입을 선언하는 유일한 방법은 다른 유형의 구현을 상속하는 새로운 클래스를 정의하는 것이기 때문입니다.

설계상의 제약

프로그램을 설계할 때 상속을 광범위하게 사용하는 것은 특정한 제약을 가합니다.

예를 들어, 개인의 이름, 생년월일, 주소 및 전화 번호가 포함된 클래스를 고려하십시오.성적 평균과 수강한 수업이 포함된 학생이라는 이름의 하위 클래스와 해당 개인의 직책, 고용주 및 급여가 포함된 직원이라는 이름의 하위 클래스를 정의할 수 있습니다.

이 상속 계층을 정의할 때 이미 몇 가지 제한을 정의했지만 모든 제한이 바람직한 것은 아닙니다.

싱글리티
단일 상속을 사용하면 하위 클래스는 하나의 슈퍼 클래스에서만 상속할 수 있습니다.위의 예에 따라 사용자는 학생 또는 직원 중 하나일 수 있지만 둘 다일 수는 없습니다.여러 상속을 사용하면 학생 및 직원 모두에서 상속되는 StudentEmployee 클래스를 정의할 수 있으므로 이 문제는 부분적으로 해결됩니다.그러나 대부분의 구현에서는 여전히 각 슈퍼클래스로부터 한 번만 상속받을 수 있기 때문에 학생이 두 개의 직업을 가지고 있거나 두 개의 기관에 다니는 경우를 지원하지 않습니다.에펠에서 사용 가능한 상속 모델은 반복 상속을 지원함으로써 이것을 가능하게 합니다.
스태틱
개체의 상속 계층은 개체 유형이 선택되면 인스턴스화 시 고정되고 시간에 따라 변경되지 않습니다.예를 들어, 상속 그래프는 학생 오브젝트가 개인 슈퍼클래스의 상태를 유지하면서 직원 오브젝트가 되는 것을 허용하지 않습니다.(단, 이러한 동작은 데코레이터 패턴으로 실현할 수 있습니다.)일부에서는 상속이 개발자를 원래 설계 [15]기준에 얽매이게 한다고 비판하고 있다.
가시성
클라이언트 코드가 개체에 액세스할 때마다 일반적으로 개체의 모든 수퍼 클래스 데이터에 액세스할 수 있습니다.슈퍼클래스가 공개로 선언되지 않은 경우에도 클라이언트는 오브젝트를 슈퍼클래스 타입으로 캐스팅할 수 있습니다.예를 들어, 학생의 개인 슈퍼클래스에 저장된 모든 개인 데이터에 대한 액세스 권한을 부여하지 않고 학생의 성적 평균 및 성적표에 대한 포인터를 함수에 제공할 수 있는 방법은 없습니다.C++ 및 Java를 포함한 많은 현대 언어에서는 하위 클래스가 데이터에 액세스할 수 있도록 "보호된" 액세스 수식자를 제공합니다. 이 수식자는 상속 체인 외부에 있는 코드가 데이터에 액세스할 수 없도록 합니다.

복합 재사용 원칙은 상속의 대안이다.이 기술은 동작을 프라이머리 클래스 계층에서 분리하고 비즈니스 도메인 클래스에 필요한 특정 동작 클래스를 포함시킴으로써 다형성과 코드 재사용을 지원합니다.이 접근법은 실행 시 동작 수정을 허용함으로써 클래스 계층의 정적 특성을 피하고 한 클래스가 상위 클래스의 동작에 제한되는 대신 뷔페식으로 동작을 구현할 수 있도록 합니다.

과제와 대안

구현 상속은 적어도 1990년대 이후 객체 지향 프로그래밍의 프로그래머와 이론가들 사이에서 논란이 되고 있다.그들 중에는 인터페이스 상속을 옹호하고 상속보다 구성을 선호하는 Design Patterns의 저자들이 있습니다.예를 들어, 클래스 간 상속의 정적 특성을 극복하기 위해 데코레이터 패턴(상기)이 제안되었습니다.같은 문제에 대한 보다 근본적인 해결책으로서 역할 지향 프로그래밍은 상속과 구성의 속성을 새로운 [citation needed]개념으로 결합하는 뚜렷한 관계를 도입합니다.

Allen Holub에 따르면 구현 상속의 주요 문제는 "취약성 기본 클래스 문제"[5]의 형태로 불필요한 결합을 도입하는 것입니다.기본 클래스 구현의 변경은 서브 클래스에서 의도하지 않은 동작 변경을 일으킬 수 있습니다.인터페이스를 사용하면 구현이 공유되지 않고 [15]API만 공유되므로 이 문제를 피할 수 있습니다.이를 나타내는 또 다른 방법은 "상속은 캡슐화를 파괴한다"[16]는 것입니다.이 문제는 시스템 제공 클래스에서 클라이언트 코드가 상속되고 [5]알고리즘에서 시스템 클래스를 대체해야 하는 프레임워크와 같은 개방형 객체 지향 시스템에서 명확하게 나타납니다.

보도에 따르면 자바 발명가 James Gosling은 구현 상속을 반대하며 [15]자바를 재설계할 경우 이를 포함하지 않겠다고 밝혔다.서브타이핑(인터페이스 상속)에서 상속을 분리하는 언어 설계는 1990년에 [17]등장했습니다.이것의 현대적인 예는 Go 프로그래밍 언어입니다.

복잡한 유전 또는 충분히 성숙하지 않은 설계 내에서 사용되는 유전은 요요 문제를 일으킬 수 있습니다.1990년대 후반에 상속이 시스템에서 코드를 구조화하기 위한 주요 접근법으로 사용되었을 때 개발자들은 자연스럽게 시스템 기능이 성장함에 따라 코드를 여러 계층의 상속으로 나누기 시작했습니다.개발 팀이 여러 계층의 상속을 단일 책임 원칙과 결합하면 많은 초박형 코드 계층이 생성되며, 그 중 대부분은 각 계층에 1~2줄의 코드만 포함됩니다.레이어가 너무 많으면 디버깅이 필요한 레이어를 판별하기가 어려워지기 때문에 디버깅은 큰 과제가 됩니다.

상속의 또 다른 문제는 하위 클래스를 코드로 정의해야 한다는 것입니다. 즉, 프로그램 사용자는 실행 시 새 하위 클래스를 추가할 수 없습니다.기타 설계 패턴(Entity-component-system 등)을 통해 프로그램 사용자는 실행 시 엔티티의 변형을 정의할 수 있습니다.

「 」를 참조해 주세요.

메모들

  1. ^ 이것은 일반적으로 C++, C#, Java 및 Scala와 같은 정적 유형의 클래스 기반 OO 언어에서만 해당됩니다.

레퍼런스

  1. ^ Johnson, Ralph (August 26, 1991). "Designing Reusable Classes" (PDF). www.cse.msu.edu.
  2. ^ Mintz, Mike; Ekendahl, Robert (2006). Hardware Verification with C++: A Practitioner's Handbook. Springer. p. 22. ISBN 978-0-387-25543-9.
  3. ^ a b Cook, William R.; Hill, Walter; Canning, Peter S. (1990). Inheritance is not subtyping. Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL). pp. 125–135. CiteSeerX 10.1.1.102.8635. doi:10.1145/96709.96721. ISBN 0-89791-343-4.
  4. ^ Cardelli, Luca (1993). Typeful Programming (Technical report). Digital Equipment Corporation. p. 32–33. SRC Research Report 45.
  5. ^ a b c Mikhajlov, Leonid; Sekerinski, Emil (1998). A study of the fragile base class problem (PDF). Proceedings of the 12th European Conference on Object-Oriented Programming (ECOOP). Lecture Notes in Computer Science. Vol. 1445. Springer. pp. 355–382. doi:10.1007/BFb0054099. ISBN 978-3-540-64737-9.
  6. ^ Tempero, Ewan; Yang, Hong Yul; Noble, James (2013). What programmers do with inheritance in Java (PDF). ECOOP 2013–Object-Oriented Programming. Lecture Notes in Computer Science. Vol. 7920. Springer. pp. 577–601. doi:10.1007/978-3-642-39038-8_24. ISBN 978-3-642-39038-8.
  7. ^ "C++ Inheritance". www.cs.nmsu.edu.
  8. ^ Stroustrup, Bjarne (1994). The Design and Evolution of C++. Pearson. p. 417. ISBN 9780135229477.
  9. ^ Schildt, Herbert (2003). The complete reference C++. Tata McGrawhill. p. 417. ISBN 978-0-07-053246-5.
  10. ^ Balagurusamy, E. (2010). Object Oriented Programming With C++. Tata McGrawhill. p. 213. ISBN 978-0-07-066907-9.
  11. ^ 오버라이드(C# 참조)
  12. ^ "GotW #60: Exception-Safe Class Design, Part 2: Inheritance". Gotw.ca. Retrieved 2012-08-15.
  13. ^ Venugopal, K.R.; Buyya, Rajkumar (2013). Mastering C++. Tata McGrawhill Education Private Limited. p. 609. ISBN 9781259029943.
  14. ^ Mitchell, John (2002). "10 "Concepts in object-oriented languages"". Concepts in programming language. Cambridge University Press. p. 287. ISBN 978-0-521-78098-8.
  15. ^ a b c Holub, Allen (1 August 2003). "Why extends is evil". Retrieved 10 March 2015.
  16. ^ Seiter, Linda M.; Palsberg, Jens; Lieberherr, Karl J. (1996). "Evolution of object behavior using context relations". ACM SIGSOFT Software Engineering Notes. 21 (6): 46. CiteSeerX 10.1.1.36.5053. doi:10.1145/250707.239108.
  17. ^ America, Pierre (1991). Designing an object-oriented programming language with behavioural subtyping. REX School/Workshop on the Foundations of Object-Oriented Languages. Lecture Notes in Computer Science. Vol. 489. pp. 60–90. doi:10.1007/BFb0019440. ISBN 978-3-540-53931-5.

추가 정보