Procedure FreeObject(Obj: TBaseMathObject) įunction CreateObject: TBaseMathObject external 'MathDll.dll' Procedure TMathObject.SetOperand(const Value: Double) Procedure SetOperand(const Value: Double) override Now we inherit a class that implements virtual methods from TBaseMathObject. dll module, so we introduce getter ( GetOperand) and setter ( SetOperand) virtual methods. Note that we can’t access FOperand field directly now because it is a part of TMathObject implementation that should be hidden in. Property Operand: Double read GetOperand write SetOperand Procedure SetOperand(const Value: Double) virtual abstract įunction Square: Double virtual abstract įunction Cube: Double virtual abstract A possible solution is to introduce a base class containing virtual abstract methods only:įunction GetOperand: Double virtual abstract We need a different form of contract that does not include an object’s implementation. In the above example the implementation of TMathObject is a contract that both sides (exe and dll) should adhere, so the implementation of TMathObject can’t be changed in dll module only. One of the main reasons to split a program into program modules is a possibility to modify the modules separately for example to modify and deploy a different. If you compile the above example you can see it works, but TMathObject implementation (MathUnit.pas) is duplicated in both program modules (MathTest.exe and MathDll.dll), and that is not just a waste of program memory. Writeln('Square = ', MathObj.Square:3:2, ' Cube = ', MathObj.Cube:3:2) Procedure FreeObject(Obj: TMathObject) external 'MathDll.dll' We want to create and destroy TMathObject instances in dll module:Īnd use an instance of TMathObject in exe module:įunction CreateObject: TMathObject external 'MathDll.dll' Property Operand: Double read FOperand write FOperand The TMathObject class implements Square and Cube functions on the FOperand field we start with the following naive code:
Let us consider a simple example – an object is created in.
There are several reasons to use interface references instead of object references, but most important of them (at least historically) is accessing an object created in a different program module. A simple question – why do we need interface references at all, why can’t we use object references everywhere? Interface reference is a different method to access an object’s functionality. Objects are normally accessed by an object reference.
0 kommentar(er)
