델파이의 tinterfacedobject 를 어떻게 발표합니까?

얼마 전, 소프트웨어를 만드는 친구가 나에게 수수께끼를 주었다. 수수께끼는' 소개팅' 인데, 내가 소프트웨어 용어를 맞춰 보자. 나는 대략 1 분 정도 생각했는데, 답이' 객체 지향' 이라고 추측했다. 나는 매우 재미있어서 수수께끼를 하나 생각해 그에게 대답했다. 수수께끼는' 키스' 인데, 그로 하여금 소프트웨어 용어를 추측하게 한다. 1 분 후, 그는 유머러스하게 말했다. "당신이 당신의 아름다운 상대를 대할 때, 당신은 자기도 모르게 그녀와 이야기할 것입니다!" 。 우리는 동시에 크게 웃기 시작했다. 우리 프로그램과의 관계가 깊어진 것 같다. 우리에게 소프트웨어는 생명이다.

제 1 절 인터페이스의 개념

"인터페이스" 라는 단어의 의미가 너무 넓어서 오해받기 쉽다. 여기서 말하는 인터페이스는 프로그램 모듈식 설계의 프로그램 인터페이스를 논의하는 것이 아니라 컴퓨터 하드웨어 장치 간의 인터페이스도 아니다. 제가 지금 말씀드리고자 하는 인터페이스는 클래스와 유사한 프로그래밍 언어 개념이자 분산 개체 소프트웨어를 구현하는 기본 기술입니다.

델파이에서 인터페이스는 클래스처럼 정의되지만 예약된 word 클래스를 사용하지 않고 인터페이스를 사용합니다. 인터페이스와 클래스는 유사한 정의를 가지고 있지만 개념은 매우 다릅니다.

우리는 클래스가 동일한 속성과 동작을 가진 객체에 대한 추상적인 설명이라는 것을 알고 있습니다. 클래스에 대한 설명은 실제 객체를 대상으로 합니다. 인터페이스는 객체를 설명하지 않고 동작만 설명합니다. 인터페이스는 객체이든, 이 동작 방법을 구현하는 다른 것이든, 동작 방법에 대한 설명이다. (알버트 아인슈타인, 인터페이스명언) 그래서 인터페이스와 클래스의 출발점은 다르지만, 다만 문제를 보는 시각은 다르다.

프로세스 간 또는 분산 프로그래밍 기술 개발에서 인터페이스는 순수한 기술 개념이라고 할 수 있습니다. 클래스의 개념은 보편적인 사고 방식이며, 객체 지향 사고의 핵심이다. 그러나, 인터페이스의 개념은 확실히 객체 지향 소프트웨어의 사상과 함께 발전했다. 인터페이스 개념을 사용하여 프로세스 간 또는 분산된 소프트웨어 구조를 이해하고 구축하면 이전에 직접 사용한 RPC (원격 프로시저 호출) 와 같은 기본 개념보다 직관적이고 간단합니다. 하나의 대상을 이해하는 것처럼 인터페이스를 이해할 수 있고, 그 대상이 로컬인지 원격인지 신경쓰지 않기 때문이다. (알버트 아인슈타인, 지식명언)

델파이에서 인터페이스는 interface 로 선언되었습니다. 이름 지정 원칙은 인터페이스가 문자 I 로 명명된다는 것입니다. 클래스가 문자 T 로 명명하는 것처럼 인터페이스 선언에는 메서드만 정의할 수 있고 데이터 멤버는 정의할 수 없습니다. 인터페이스는 메서드와 비헤이비어에 대한 설명일 뿐 객체의 속성 상태는 저장하지 않기 때문입니다. 델파이에서 인터페이스의 속성을 정의할 수 있지만 이러한 속성은 메서드에 따라 액세스해야 합니다.

모든 인터페이스는 IUnknown 에서 직접 또는 간접적으로 상속됩니다. IUnknown 은 모든 인터페이스 유형의 원시 조상이며 클래스 개념에서 TObject 와 같은 위치를 가집니다. "한 인터페이스가 다른 인터페이스를 상속합니다." 라는 말은 사실 틀렸습니다. "한 인터페이스가 다른 인터페이스를 확장했습니다." 라고 말해야 합니다. 인터페이스의 확장은 하나의 인터페이스가 두 개의 상위 인터페이스와 동시에 호환될 수 없는 단일 "호환성" 을 반영합니다.

인터페이스는 하나의 메서드와 비헤이비어만 설명하므로 이러한 메서드와 비헤이비어의 구현은 클래스에 의존해야 합니다. 인터페이스에서 인스턴스를 생성할 수 없습니다. 인터페이스 인스턴스 같은 건 없어요. 클래스만 객체 인스턴스를 만들 수 있습니다. 그러나 인터페이스 뒤에는 객체 인스턴스가 있어야 합니다. 이 인스턴스는 인터페이스 메서드의 구현자이며 인터페이스는 객체의 메서드 세트에 대한 참조입니다.

개념적으로 객체의 클래스는 하나 이상의 인터페이스를 구현할 수 있습니다. 인터페이스에 대한 클래스의 책임은 인터페이스를 구현하는 것일 뿐 클래스가 하나 이상의 인터페이스를 상속한다고 해서는 안 됩니다. "실현" 과 "상속" 이라는 단어는 의미가 다르므로 개념적으로 구분해야 한다.

일반적으로 인터페이스를 선언할 때 인터페이스 유형을 고유하게 식별하는 GUID 식별자가 필요합니다. 인터페이스 유형은 프로그램 공간에서만 인식되고 사용되는 클래스 유형과는 달리 서로 다른 프로세스 공간이나 컴퓨터에 분산되어 있는 프로그램에서 사용됩니다. 인터페이스 유형을 어디에서나 고유하게 식별할 수 있도록 다른 인터페이스를 식별하는 효과적인 방법이 필요합니다. 인공적으로 명명하는 방법은 불가능하다. 네가 개발한 인터페이스가 다른 사람과 이름이 같지 않을 것이라고 보장할 수 있는 사람은 아무도 없다. 그래서 소위 글로벌 고유 식별자 (Global Unique Identifier) 가 등장했습니다. 복잡한 알고리즘에 의해 무작위로 생성된 식별자로 16 바이트 길이이며 세계 어느 곳에서나 생성된 식별자가 다르다는 것을 보장합니다. 델파이의 편집 환경에서는 Ctrl+Shift+G 를 인터페이스의 고유 식별자로 사용하여 GUID 식별자를 쉽게 생성할 수 있습니다.

인터페이스에 GUID 를 지정해야 합니다. 인터페이스의 GUID 를 지정하지 않아도 항상 컴파일할 수 있지만 인터페이스 식별 및 변환과 관련된 일부 함수를 사용할 때 문제가 발생할 수 있습니다. 특히 COM 기반 프로그램 개발에서는 GUID 가 필수적입니다.

인터페이스의 개념은 실제로 간단하지만 분산 소프트웨어 개발에 중요한 역할을 합니다. 어떤 친구들은 인터페이스가 비교적 복잡하다고 생각하는데, 주로 인터페이스의 개념과 원리를 이해하지 못한다. 사람은 자신이 모르는 것에 대해 항상 신비감을 가지고 있기 때문이다. 이런 신비감은 종종 미지의 세계에 대한 두려움을 불러일으킨다. 인터페이스의 신비를 밝히기 위해서는 인터페이스의 신비를 끊임없이 배우고 이해해야 한다. 사실, 탐험하는 과정에도 많은 즐거움이있을 것입니다, 그렇죠?

섹션 ii 나는 모른다.

IUnknown 은 모든 인터페이스의 공통 조상이기 때문에 먼저 이해해야 합니다. 일의 원인을 알면 일의 과정과 결과를 이해하는 데 효과적으로 도움이 될 수 있다. IUnknown 의 원래 정의는 System.pas 셀에 있습니다. System.pas 단위에 정의되어 있기 때문에 시스템이나 컴파일러와 관련된 원료여야 합니다. IUnknown 의 정의를 보세요. 간단합니다. 총 6 줄밖에 없습니다.

IUnknown = 인터페이스

['{00000000-0000-0000-c000-0000000046}']

함수 QueryInterface (상수 IID:TGUID；; Outobj): hresult; Stdcall

Function _ AddRef:Integer；; Stdcall

Function _Release: 정수; Stdcall

끝;

그러나 이 6 줄 정의 코드는 인터페이스 표준의 기초가 될 수 있습니다. 이 중 세 가지 인터페이스 방법에는 인터페이스 기반 프로그램을 작성할 때 도움이 될 수 있는 간단하고 심오한 철학이 포함되어 있습니다.

IUnknown 의 세 가지 인터페이스 메서드는 각 인터페이스 객체 클래스에서 구현해야 하는 메서드이며 인터페이스 메커니즘의 기본 메서드입니다. 이 세 가지 방법이 인터페이스 메커니즘의 기초인 이유는 무엇입니까? 내 긴 여정을 들어라.

우선 QueryInterface 메소드부터 시작하겠습니다. 우리는 객체 클래스가 여러 인터페이스를 구현할 수 있음을 알고 있습니다. 모든 인터페이스 객체는 IUnknown 인터페이스를 구현해야 합니다. 따라서 인터페이스 포인터를 얻으면 이 인터페이스 포인터를 통해 QueryInterface 메서드를 호출할 수 있습니다. QueryInterface 를 호출하여 이 인터페이스 포인터가 구현하는 인터페이스를 파악합니다. 이것은 인터페이스 프로그래밍 메커니즘에 매우 중요합니다. 인터페이스 포인터가 인터페이스 기능을 구현하는지 여부, 인터페이스 일치 여부, 인터페이스 유형 간 변환은 모두 QueryInterface 메서드와 관련이 있습니다.

쿼리 인터페이스에는 두 개의 매개 변수와 반환 값이 있습니다. 첫 번째 인수는 인터페이스 유형 id, 즉 16 바이트의 GUID id 입니다. DELPHI 컴파일러는 각 인터페이스에 해당하는 GUID 를 알고 있으므로 ImyInterface 와 같은 식별자를 첫 번째 인수로 직접 사용할 수 있습니다. 인터페이스가 첫번째 매개변수로 지정된 인터페이스 유형을 지원할 경우 두번째 매개변수인 Obj 를 통해 얻은 인터페이스 포인터를 호출자에게 되돌려 S_OK 를 반환합니다.

여기서도 인터페이스에 GUID ID 를 지정해야 하는 이유를 알 수 있습니다. QueryInterface 메서드는 이러한 ID 가 필요하며 인터페이스 및 일치 변환 메커니즘의 기초이기 때문입니다.

다음으로 _AddRef 및 _Release 극좌표 방법에 대해 살펴보겠습니다. _AddRef 및 _Release 인터페이스 메서드는 연결하려는 각 객체 클래스에서 구현해야 하는 메서드입니다. _AddRef 는 인터페이스 객체의 참조 수를 늘리는 것이고 _Release 는 인터페이스 객체의 참조를 줄이는 것입니다. 인터페이스 객체의 참조 수가 0 이면 인터페이스 객체가 제거되고 공간이 확보됩니다. 이것은 인터페이스 메커니즘 요구 사항의 기본 원리입니다. 1+ 1=2 와 같은 간단한 이치는 깊은 설명이 필요하지 않습니다. 수학자들은 왜 1 더하기 1 이 2 인지 연구하는 것에 흥미를 가질 것이다. 그러나 수학자들은 1+ 1=2 에 대해 철저한 이해를 가지고 있다. 마찬가지로, 인터페이스 객체 참조 메커니즘에 대한 심층적 인 이해는 많은 진리를 이해하고 개발 작업에 도움이 될 것입니다.

한 주인은 한 번 말했다: 인터페이스는 인용이다!

이 말을 이해하려면 먼저' 인용' 이라는 개념을 이해해야 한다. "참조" 는 "차용" 을 의미하며 참조 관계를 나타냅니다. 피제시측은 피제시측의 인맥을 찾아야만 제시가격을 받는 것이 진정한 중심이다. 이 참조 관계를 통해 객체를 찾을 수 있기 때문에 참조는 실제로 객체의 ID 표현입니다. 프로그래밍에서 참조는 실제로 객체의 주소를 객체의 식별 표시로 사용하는 포인터입니다.

인터페이스 메커니즘을 기반으로 하지 않는 프로그램에서는 객체에 대한 참조 관계를 관리할 필요가 없습니다. 비인터페이스 객체의 인스턴스는 모두 동일한 프로세스 공간에 있기 때문에 프로그램을 통해 객체의 설정, 사용 및 해제 프로세스를 엄격하게 제어할 수 있습니다. 그러나 인터페이스 메커니즘 기반 프로그램에서는 객체의 생성, 사용 및 해제가 동일한 프로세스 공간, 다른 프로세스 공간, 심지어 인터넷에서 수천 마일 떨어진 두 컴퓨터에서도 발생할 수 있습니다. 한 곳에 인터페이스를 구축하면 이 인터페이스를 구현할 수 있는 개체가 다른 곳에 존재할 수 있습니다. 하나의 인터페이스가 한 곳에 구축되면 다른 곳에서 사용될 수 있습니다. 이 경우 기존 프로그램을 사용하여 객체 작성 및 릴리즈를 제어하는 것은 매우 어렵습니다. 객체 작성 및 릴리즈를 처리하기 위해 또 다른 합의된 메커니즘이 있어야 합니다. 그래서 이 중임은 IUnknown 의 _AddRef 와 _Release 에 떨어졌다.

이 인터페이스 객체 참조 메커니즘은 인터페이스 객체의 설정 및 해제가 객체 인스턴스가 있는 프로그램, 즉 인터페이스를 구현하는 객체 클래스에 의해 수행되어야 합니다. 어느 곳에서나 객체의 인터페이스를 참조할 때마다 인터페이스의 _AddRef 메서드를 호출해야 합니다. 객체가 더 이상 참조되지 않을 때 인터페이스의 _ 해석법도 호출해야 합니다. 일단 객체 인스턴스가 어느 곳에서도 더 이상 참조되지 않는다는 것을 알게 되면, 그것은 자신을 풀어줍니다.

_AddRef 및 _Release 메서드는 인터페이스 객체 인스턴스 공간 관리 문제를 해결하기 위해 모든 인터페이스 객체 클래스에서 구현해야 하는 메서드입니다.

섹션 iii 인터페이스 객체의 생사

언뜻 보면, 이 절의 제목은 좀 무서운 것 같다. 인터페이스 개체는 어떻게 생사와 연결될 수 있습니까? 인터페이스 대상의 생사가 정말 그렇게 중요한가요? 좋은 통치자는 국민의 생사에 관심을 가져야 한다. 마찬가지로, 좋은 프로그래머도 대상의 생사에 관심을 가져야 한다. 인터페이스 대상은 분산 네트워크의 유랑자이며, 우리는 그들의 생사에 더욱 관심을 가져야 한다!

인터페이스 객체는 인터페이스 참조가 생성될 때 설정되고 인터페이스 참조가 끝나면 소멸되기 때문입니다. DELPHI 에서 interface 를 사용하면 인터페이스를 구현하는 대상이 어떻게 생겨났는지, 어떻게 죽었는지 아무도 신경쓰지 않는 것 같다. 이것이 DELPHI 의 인터페이스 사용의 간결성이자 인터페이스 메커니즘 사용 문제를 해결할 때 추구하는 목표이다. 인터페이스가 필요할 때 항상 그녀를 위해 태어난 개체가 있다. 일단 어떤 인터페이스도 더 이상 참조하지 않으면, 이 개체는 원망 없이 죽고, 1 바이트의 시스템 자원을 끌지 않을 것이다. 봄의 누에는 죽을 때까지 짜고, 매일 밤 촛불은 심지를 울린다.

인터페이스 객체의 생사는 해당 객체를 참조하는 인터페이스의 수와 직접적인 관련이 있기 때문에 어떤 상황에서 인터페이스 참조를 늘리고 줄이는 것이 인터페이스 객체의 생사를 이해하는 열쇠입니다.

이제 가장 간단한 인터페이스 객체 클래스인 TIntfObj 를 구현하겠습니다. IUnknown 인터페이스에 정의된 세 가지 기본 메서드만 구현합니다. 친구가 보자마자 이 클래스가 델파이 중 TInterfacedObject 클래스의 일부 코드를 베꼈다는 것을 알게 되었다. 다만 _AddRef 및 _Release 메서드에 정보 출력문을 각각 추가하여 인터페이스 객체의 생사 문제를 검토할 수 있습니다. 다음 절차를 확인하십시오.

프로그램 ProgramA

사용

시스템, 대화 상자

유형

TIntfObj = class(to object, IUnknown)

보호

FRefCount: 정수;

함수 QueryInterface (상수 IID:TGUID；; Outobj): hresult; Stdcall

Function _ AddRef:Integer；; Stdcall

Function _Release: 정수; Stdcall

끝;

함수 TIntfObj. 쿼리 인터페이스 (constiid: tguid; Outobj): hresult; Stdcall

상수

E _ nointerface = hresult ($80004002);

시작

If GetInterface(IID, obj) then result: = 0 else result: = e _ no interface;

끝;

함수 TIntfObj. _ AddRef:Integer；; Stdcall

시작

Inc (fref count);

ShowMessage(Format ('참조 수를% D.', [frefcount]));

결과: = FRefCount

끝;

함수 TIntfObj. _Release: 정수; Stdcall

시작

Dec (fref count);

If FRefCount & lt& gt 그렇게 0

ShowMessage (형식 ('참조 수를 %d.', [FRefCount]))

그렇지 않으면 시작합니다

파괴;

ShowMessage ('는 참조 수를 0 으로 줄이고 객체를 삭제합니다. );

끝;

결과: = FRefCount

끝;

변수를 정의합니다

Aoobject: tintfobj;

AInterface:I unknown；;

IntfObjLife 프로세스;

시작

Ao object:= TIntfObj 입니다. 만들기;

AInterface:= a object；; //참조 추가

AInterface:= nil；; //1 회 발생 감소

끝;

시작

IntfObjLife

끝내다.

우리는 단일 단계 디버깅 함수를 사용하여 인터페이스 참조 수의 증감과 인터페이스 생사의 관계를 연구해야 한다. 따라서 컴파일러가 필요한 명령을 최적화하지 않도록 옵션에서 컴파일러 페이지의 최적화를 지우는 것이 좋습니다.

프로그램이 IntfObjLife 서브루틴의 코드 세 줄을 실행할 때 한 번에 한 단계씩 코드를 디버그하십시오. 인터페이스 유형 변수 할당이 발생하면 인터페이스 참조 수가 증가하거나 감소한다는 것을 알 수 있습니다.

명령문을 실행하다

AInterface:= a object；;

메시지 "참조 수가 1 으로 증가했습니다." 인터페이스 참조가 한 번 추가되었음을 나타내는 가 나타납니다.

이 문을 실행합니다

AInterface:= nil；;

"참조 수가 0 으로 줄고 객체가 제거됩니다." 가 나타나 인터페이스 참조가 0 으로 떨어지고 인터페이스 객체가 삭제됨을 나타냅니다.

따라서 인터페이스 유형의 변수에 참조 값을 할당하면 인터페이스 객체의 참조 수가 증가한다는 결론을 내릴 수 있습니다. 인터페이스 유형 변수의 참조 값이 지워지면 (nil 값이 지정됨) 인터페이스 객체의 참조 수가 줄어듭니다.

다음 코드를 살펴보고 이 결론에 대한 우리의 이해를 깊게하십시오.

변수를 정의합니다

Aoobject: tintfobj;

InterfaceA, InterfaceB:I unknown；;

......

Ao object:= TIntfObj 입니다. 만들기;

Interface a:= a object；; //참조가 1

Interfaca:= interfaca； a; //참조는 2 로 증가했지만 즉시 1 으로 줄었습니다.

InterfaceB:= InterfaceA； a; //참조가 2 로 증가했습니다

인터faca: = nil; //참조가 1

InterfaceB:= InterfaceA； a; //참조를 0 으로 줄이고 객체를 해제합니다.

......

인터페이스 객체를 변수에 할당할지 여부, 인터페이스 변수를 인터페이스 변수에 할당할지 여부, nil 을 인터페이스 변수에 할당할지 여부는 이 결론을 확인합니다. 흥미롭게도, InterfaceA := InterfaceA 라는 말이 실행되면 인터페이스 객체에 대한 참조가 먼저 증가한 다음 즉시 줄어든다. 왜 그럴까요? 자신에게 맡겨라!

그런 다음 다음 코드를 살펴 보겠습니다.

IntfObjLife 프로세스;

변수를 정의합니다

Aoobject: tintfobj;

AInterface:I unknown；;

시작

Ao object:= TIntfObj 입니다. 만들기;

AInterface:= a object；;

끝;

이 프로세스는 변수가 로컬 변수로 정의되고 마지막 인터페이스 변수에 0 값이 부여되지 않는다는 점에서 이전 프로세스와 다릅니다. 프로그램이 서브루틴 end 문으로 실행되기 전에 인터페이스 객체에 대한 참조가 0 으로 줄어들고 해제되는 것을 발견했습니다. 왜 그럴까요?

우리는 변수가 범위가 있다는 것을 안다. 전역 변수의 범위는 프로그램 내 어느 곳에나 있지만 로컬 변수의 범위는 해당 하위 프로그램에만 있습니다. 변수가 범위를 벗어나면 변수 자체는 더 이상 존재하지 않으며 저장된 값은 더욱 의미가 없습니다. 따라서 프로그램이 하위 프로그램을 떠나려고 할 때 로컬 변수인 aInterface 는 더 이상 존재하지 않으며 저장된 인터페이스 객체 참조 값도 의미가 없습니다. Smart DELPHI 는 인터페이스 객체의 참조 수를 자동으로 줄여 프로그램이 계층별 호출 및 반환에서 인터페이스 객체의 메모리 공간을 제대로 관리할 수 있도록 합니다.

따라서 모든 인터페이스 변수가 범위를 벗어나면 관련 인터페이스 객체의 참조 수가 감소한다는 새로운 결론을 내릴 수 있습니다.

하위 프로그램의 매개변수 변수도 변수이며 해당 범위도 하위 프로그램의 범위 내에 있다는 점에 유의해야 합니다. 인터페이스 유형 매개 변수를 사용하여 하위 프로그램을 호출하면 관련 인터페이스 객체의 참조 수가 매개 변수 전달로 증가하고 하위 프로그램이 반환될 때 감소합니다.

마찬가지로 하위 프로그램의 반환 값이 인터페이스 유형인 경우 반환 값의 범위는 기본 호출자의 반환 지점에서 기본 호출자의 end 문까지입니다. 이 경우 인터페이스 객체의 참조 수도 증가하거나 감소합니다.

대상의 생사를 총결해야 한다. 결론적으로 우리는 다음과 같은 원칙을 도출할 수 있다.

1. 인터페이스 객체에 대한 참조 값을 전역 변수, 로컬 변수, 매개 변수 변수 및 반환 값에 할당하면 인터페이스 객체에 대한 참조 수가 확실히 증가합니다.

2. 변수의 원래 인터페이스 참조 값이 변경될 때까지 연관된 객체의 참조 수가 줄어듭니다. 변수에 nil 값을 할당하는 것은 인터페이스 참조를 할당하고 수정하는 특수한 경우로, 원래 인터페이스 객체의 참조 개수만 줄이고 새 인터페이스 참조는 포함하지 않습니다.

3. 인터페이스 참조 값을 저장하는 글로벌 변수, 로컬 변수, 매개 변수 변수, 반환 값 등의 요소로, 범위를 벗어나면 인터페이스 객체의 참조 수가 자동으로 감소합니다.

4. 인터페이스 객체의 참조 수가 0 이면 인터페이스 객체의 메모리 공간이 자동으로 해제됩니다. (MTS 와 같은 객체 캐싱 기술을 사용하는 일부 미들웨어 시스템에서는 이 원칙을 따르지 않을 수 있습니다. ) 을 참조하십시오

설정된 인터페이스 개체가 인터페이스에 전달되면 개체의 생사가 인터페이스에 맡겨진다는 점을 상기시켜 줄 필요가 있다. (윌리엄 셰익스피어, 윈프리, 희망명언) 너의 귀염둥이를 성실한 사람에게 시집가는 것처럼, 너는 그를 완전히 신뢰하고, 그가 그녀를 잘 돌볼 수 있다고 믿어야 한다. 그 이후로 오브젝트와의 접촉은 오브젝트를 직접 다루는 것이 아니라 인터페이스를 통해 이루어져야 합니다. 사위를 돌아서 딸의 일에 직접 개입하면 큰 문제가 생길 수 있다는 것을 알아야 한다. 믿지 마세요. 다음 코드를 살펴 보겠습니다.

가족 계획

유형

IHusband = 인터페이스

함수 getsomething: string;

끝;

TWife = class(TInterfacedObject, IHusband)

개인

F something:string；;

대중의

생성자 create (something: string);

함수 getsomething: string;

끝;

생성자 TWife. 만들기 (무언가: 문자열);

시작

상속 생성

F Something:= 무언가;

끝;

함수 TWife. Get something:string；;

시작

결과: = FSomething

끝;

프로그램 husband do (ahusband: ihusband);

시작

끝;

변수를 정의합니다

The life:tw ife；;

The husband:IHusband；;

시작

The life:= TWife 입니다. 창조 ('대부');

Thehusband: = thelife; //객체 TheWife 는 일반 인터페이스 변수 TheHusband 에 위임됩니다.

남편: = 영; //인터페이스 참조를 지우면 객체가 사라집니다.

생활. GetSomething// 직접 액세스 개체에 오류가 있을 것입니다!

The life:= TWife 입니다. 창조 ('대부');

남편의 행동 (the life); //객체는 매개 변수 인터페이스 변수 aHusband 에 위임되어 객체가 반환될 때 사라집니다.

생활. GetSomething// 직접 액세스 개체에 오류가 있을 것입니다!

끝내다.