상속은 하위 유형과 어떻게 다릅니 까?

프로그래밍 언어 관점에서 서브 타이핑이란 무엇입니까? "상속은 하위 유형이 아닙니다"라고 들었습니다. 그렇다면 상속과 하위 유형의 차이점은 무엇입니까?

— RoboAlex
소스

이 질문 (및 다른 질문)이 공개 베타에 들어갈 때 새로운 cs.SE 사이트로 리디렉션 될 수 있는지 궁금합니다.

— Suresh Venkat

이론적 컴퓨터 과학 (TCS)의 연구 수준 질문에 대한 Q & A 사이트 인 cstheory에 오신 것을 환영합니다. 귀하의 질문은 TCS에서 연구 수준의 질문으로 보이지 않습니다. 이것이 의미하는 바에 대한 자세한 내용과 질문을 환영 할 수있는 사이트에 대한 제안은 FAQ 를 참조하십시오 . 마지막으로, 귀하의 질문이 범위를 벗어난 것으로 종료 된 상태에서 질문을 편집하여 연구 수준의 질문으로 만들 수 있다고 생각되면 언제든지 질문하십시오. 결산은 영구적이지 않으며 질문을 다시 열 수 있습니다 . 자세한 내용 은 FAQ 를 확인 하십시오.

— Kaveh

@UdayReddy : 처음 대답했을 때 사소한 질문은 없었지만 현대적인 관점에서 결정을 내려야합니다. 당신과 같은 주장은 Dijkstra의 알고리즘에 대한 질문은 첫 번째 논문이 그것에 대해 이야기하고 다른 것은 없기 때문에 주제에 관한 것임을 암시합니다.

— 이토 쓰요시

익스트라 제 종이 때문에 유사 @TsuyoshiIto 적절하지 해결 여기 Cardelli 최초 종이 반면, 문제 작성 문제. 그럼에도 불구하고, 나는 우리가 첫 번째 논문을 기반으로 최첨단 기술을 측정하지 않는다고 지적합니다. 상속과 서브 타이핑의 차이점이 해결 된 문제를 나타내는 것은 아니며 적어도 20 년 동안이 문제가 논의 될 것으로 예상합니다. 질문자는 추가 과제를 수행하고 연구 수준 문제를 명확히하기 위해 질문을 편집하도록 조언받을 수 있습니다.

— Uday Reddy

어쨌든 OP와 같은 이름의 Cook et al.의 논문을 지적하기가 쉽다 : citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.8635

— Andreas Rossberg

[객체 지향 유형 시스템의 문제에 대해 깊이 생각하지는 않았지만 토론을 진행하기 위해 알고있는 것을 말할 것입니다.]

우리는 말할 의 하위 유형 인 모든 경우 값이 모든 상황에서 사용할 수있는 -typed 값이 예상되는 -typed. 아니면 다른 방법으로 $A$ $B$ $A$ $B$ 달리 말하면 유형 값은 유형 값으로 "가장 무도회"할 수 있습니다. $A$ $B$

이러한 마스커레이딩이 유형 검사에 문제가없는 경우, 즉 유형의 값을 연결 경우 $A$ 유형의 값이 필요한계속 입력하면 유형 점검이 계속 진행되는 경우이를"구조적서브 타이핑"이라고합니다. 동작에 문제가 발생하지 않는 경우 (예 : 이러한 막힘으로 인해 예상되는 동작이 변경되지 않는 경우)"행동 적 하위 유형 지정"이라고합니다. ( "예상되는 행동"은 별도로 공식화되어야하며 많은 행동 개념이 가능합니다.) $B$

구조적 서브 타이핑은 유형의 구조가 우연한 이유로 일치 할 수 있으므로 동작 서브 타이핑을 보장하지 않습니다. 그러나 예상되는 동작을 정의하는 것은 쉽지 않습니다. 따라서 많은 프로그래밍 언어가 중간 지점을 사용하므로 사용자는 어느 유형이 하위 유형인지 선언해야합니다. 이것을 "공칭 서브 타이핑"이라고 합니다. 암시 적 대 명시 적 하위 유형 에 대한 질문을 참조하십시오.이 문제에 대한 토론. 아이디어는 프로그래머가 자신의 독창성을 사용하여 선언 된 모든 하위 유형에 대한 행동 하위 유형을 보장해야한다는 것입니다. 언어는 도움을 줄 수 없습니다. 그러나 선언 된 모든 하위 유형은 최소한 구조적 하위 유형이어야합니다. 그렇지 않으면 프로그램이 검사를 입력하지 못했습니다. 언어가이를 보장 할 수 있습니다. (일부 프로그래밍 언어는 컴파일 타임에이를 보장하기에 충분한 유형 시스템을 가지고 있지 않습니다. 그러한 경우 런타임에 유형 오류가 감지되거나 잘못된 결과가 생성 될 수 있습니다. 이러한 유형 구멍은 분명히 바람직하지 않습니다.)

객체 지향 프로그램에서 서브 클래스를 정의 할 때 일반적으로 공개적으로 보이는 필드 (또는 메소드)를 추가합니다. 대부분의 프로그래밍 언어에서 이러한 서브 클래스는 공칭 으로 간주됩니다 하위 유형 . 문제는 그것들이 또한 구조적 서브 타입 인지의 여부 입니다. 만약 그것이 프로그래밍 언어가 아닌 경우, 즉 구조적 서브 타입이 아닌 명목 서브 타입을 선언 할 수 있다면, 프로그래밍 언어에 타입 홀이있을 것입니다.

간단한 경우에는 필드를 추가해도됩니다. 수퍼 클래스의 유형은 서브 클래스의 유형보다 적은 수의 필드를 예상합니다. 따라서 sueprclass의 인스턴스가 예상되는 서브 클래스의 인스턴스를 연결하면 프로그램은 제공된 추가 필드를 무시하고 아무런 문제가 없습니다.

그러나 수퍼 클래스 또는 서브 클래스에 자체와 동일한 유형의 인수를 사용하거나 자체와 동일한 유형의 결과를 리턴하는 메소드가있는 경우 문제점이 발생합니다. 그러면 서브 클래스의 인터페이스 유형은 수퍼 클래스 의 인터페이스 유형이 아닙니다 . Java와 같이 널리 사용되는 형식 안전 프로그래밍 언어는 이러한 하위 클래스를 허용하지 않습니다. 따라서 언어를 제한 하여 형식 안전성을 얻습니다. 프로그래밍 언어 인 Eiffel은 유연성 을 얻기 위해 타입 안전성을 희생했다고합니다 . 융통성을 유지하는 강력한 유형 시스템을 설계하는 경우 하위 클래스가 하위 유형을 생성한다는 원칙을 포기해야합니다. 따라서 논문의 제목은 "상속은 아 종형이 아니다". 저자는 대신 작동하는 고차 하위 유형의 다른 개념을 제안합니다. Kim Bruce는 또한 동일한 효과를 달성하는 "매칭"이라는 밀접한 관련 제안을 가지고 있습니다. 이 프리젠 테이션을 참조하십시오 . Andrew Black 의 게재 논문 도 도움이 됩니다.

시맨틱 커뮤니티는 아마도 문제를 크게 무시하는 데 잘못되었을 수 있습니다. 우리는 전통적으로 그것을 이론적 인 관심이 거의없는 실용적인 유형 시스템 엔지니어링 문제로 간주했습니다. 그렇지 않은 경우 실제로 해당 지역에서 일부 의미론 작업이있는 경우 다른 사람들이 언급 할 수 있기를 바랍니다.

— 우다이 레디
소스

객체 시스템의 Ocaml과 같이 상속과 하위 유형을 성공적으로 분리 한 실제 언어가 있다는 것도 언급 할 가치가 있습니다.

— Andreas Rossberg

@AndreasRossberg 사실, OCaml은 그 답을 쓸 때 내 틀에 없었습니다. OCaml에 공칭 하위 유형이 전혀 없다고 가정합니다. 따라서 이러한 문제 중 일부는 발생하지 않습니다. 그러나 동작이 일치하지 않더라도 실수로 유형이 일치 할 가능성이 있으며 유형 시스템은 해당 유형의 실수를 잡을 수 없습니다.

— Uday Reddy