ინტერფეისი დელფის პროგრამირების 101-ში

ინტერფეისი დელფის პროგრამირების 101-ში

დელფში "ინტერფეისს" ორი განსხვავებული მნიშვნელობა აქვს. OOP ჟარგონში, შეგიძლიათ იფიქროთ ინტერფეისზე, როგორც კლასში, რომლის განხორციელებაც არ ხდება. დელფის ერთეულის განმარტებით ინტერფეისის სექცია გამოიყენება კოდირების ნებისმიერი საჯარო განყოფილების გამოსაცხადებლად, რომელიც გამოჩნდება ერთეულში. ეს სტატია ახსნის ინტერფეისებს OOP პერსპექტივიდან.

თუ თქვენ მზად ხართ შექმნათ მყარი აპლიკაცია ისე, რომ თქვენი კოდი შენარჩუნდეს, გამოსაყენებელი და მოქნილი იყოს დელფის OOP ბუნებაში დაგეხმარებათ თქვენი მარშრუტის პირველი 70%. ინტერფეისების განსაზღვრა და მათი განხორციელება ხელს შეუწყობს დანარჩენი 30% -ს.

აბსტრაქტული კლასები

თქვენ შეგიძლიათ იფიქროთ ინტერფეისზე, როგორც აბსტრაქტულ კლასად, ყველა იმპლემენტაციით ამოღებულია და ყველაფერი, რაც არ არის საჯარო ამოღებული. დელფში აბსტრაქტული კლასი არის კლასი, რომლის შემოწმება შეუძლებელია - თქვენ არ შეგიძლიათ შექმნათ ობიექტი კლასიდან, როგორც აბსტრაქტი.

მოდით შევხედოთ ინტერფეისის მაგალითს:

ტიპი
IConfigChanged = ინტერფეისი'{0D57624C-CDDE-458B-A36C-436AE465B477}'
პროცედურა ApplyConfigChange;
დასასრული;

IConfigChanged ინტერფეისია. ინტერფეისი განსაზღვრულია კლასელის მსგავსად, სიტყვა "ინტერფეისი" გამოიყენება "კლასის" ნაცვლად. სახელმძღვანელოს მნიშვნელობას, რომელიც მიჰყვება ინტერფეისის საკვანძო სიტყვას, შემდგენელმა იყენებს ინტერფეისის ცალსახად იდენტიფიცირებას. ახალი GUID მნიშვნელობის შესაქმნელად, უბრალოდ დააჭირეთ Ctrl + Shift + G Delphi IDE- ში. თქვენს მიერ განსაზღვრულ ინტერფეისს უნიკალური სახელმძღვანელო მნიშვნელობა სჭირდება.

ინტერფეისი OOP განსაზღვრავს აბსტრაქციას - თარგის რეალურ კლასს, რომელიც განახორციელებს ინტერფეისს - რომელიც განახორციელებს ინტერფეისით განსაზღვრულ მეთოდებს. ინტერფეისი ფაქტობრივად არაფერს აკეთებს, მას მხოლოდ ხელმოწერა აქვს სხვა (განმახორციელებელ) კლასებთან ან ინტერფეისებთან ურთიერთობისთვის.

მეთოდების (ფუნქციების, პროცედურების და ქონების Get / Set მეთოდების) განხორციელება ხდება კლასში, რომელიც ახორციელებს ინტერფეისს. ინტერფეისის განმარტებით, არ არსებობს მასშტაბის სექციები (პირადი, საჯარო, გამოქვეყნებული და ა.შ.) ყველაფერი საჯაროა. ინტერფეისის ტიპს შეუძლია განსაზღვროს ფუნქციები, პროცედურები (რაც საბოლოოდ გახდება კლასის მეთოდები, რომელიც ახორციელებს ინტერფეისს) და თვისებები. როდესაც ინტერფეისი განსაზღვრავს ქონებას, მან უნდა განსაზღვროს get / set მეთოდები - ინტერფეისებს არ შეუძლიათ ცვლადის განსაზღვრა.

როგორც კლასებს, ინტერფეისს შეუძლია მემკვიდრეობა მიიღოს სხვა ინტერფეისებისგან.

ტიპი
IConfigChangedMore = ინტერფეისი(IConfigChanged)
პროცედურა ApplyMoreChanges;
დასასრული;

პროგრამირება

დელფის დეველოპერების უმეტესობა, როდესაც ინტერფეისზე ფიქრობენ, ფიქრობენ COM პროგრამირების შესახებ. ამასთან, ინტერფეისები მხოლოდ ენის OOP თვისებაა - ისინი სპეციალურად COM- სთან არ არის დაკავშირებული. ინტერფეისები შეიძლება განისაზღვროს და განხორციელდეს დელფის აპლიკაციაში, COM- ზე შეხების გარეშე.

განხორციელება

ინტერფეისის განსახორციელებლად, თქვენ უნდა დაამატოთ ინტერფეისის სახელი კლასის განცხადებაში, როგორც ეს:

ტიპი
TMainForm = კლასი(TForm, IConfigChanged)
საზოგადოება
პროცედურა ApplyConfigChange;
დასასრული;

ზემოთ მოცემულ კოდში დელფის ფორმა სახელწოდებით "MainForm" ახორციელებს IConfigChanged ინტერფეისს.

გაფრთხილებაროდესაც კლასი ახორციელებს ინტერფეისს, მან უნდა განახორციელოს ყველა მისი მეთოდი და თვისება. თუ თქვენ ვერ ახერხებთ მეთოდის დანერგვას (მაგალითად: ApplyConfigChange) შედგენის დროის შეცდომა "E2003 გაუქმებული იდენტიფიკატორი: 'ApplyConfigChange'" მოხდება.
გაფრთხილება: თუ ცდილობენ ინტერფეისის მითითებას GUID მნიშვნელობის გარეშე მიიღებთ: "E2086 ტიპი" IConfigChanged "ჯერ არ არის ბოლომდე განსაზღვრული".

მაგალითი

განვიხილოთ MDI პროგრამა, სადაც მომხმარებლებისთვის ერთდროულად შეიძლება ნაჩვენები იყოს რამდენიმე ფორმა. როდესაც მომხმარებელი ცვლის აპლიკაციის კონფიგურაციას, ფორმების უმეტესობამ უნდა განაახლოს თავისი ეკრან – შოუს / დამალვა რამდენიმე ღილაკი, ეტიკეტის განახლება და ა.შ. თქვენ დაგჭირდებათ მარტივი გზა, რომ აცნობოთ ყველა ღია ფორმას, რომ მოხდა პროგრამის კონფიგურაციის ცვლილება. სამუშაოსთვის იდეალური ინსტრუმენტი იყო ინტერფეისი.

ყველა ფორმა, რომლის განახლებაც საჭიროა კონფიგურაციის ცვლილებისას, განახორციელებს IConfigChanged. მას შემდეგ, რაც კონფიგურაციის ეკრანი აჩვენებს მოდულს, როდესაც იგი დახურავს შემდეგ კოდს, უზრუნველყოფს IConfigChanged განხორციელების ყველა ფორმის შესახებ შეტყობინებას და ApplyConfigChange ეწოდება:

პროცედურა DoConfigChange ();
var
cnt: მთელი რიცხვი;
icc: IConfigChanged;
დაიწყოს
ამისთვის cnt: = 0 რომ -1 + ეკრანი.FormCount კეთება
დაიწყოს
თუ მხარდაჭერა (Screen.Formscnt, IConfigChanged, icc) შემდეგ
icc.ApplyConfigChange;
დასასრული;
დასასრული;

მხარდაჭერის ფუნქცია (განსაზღვრულია Sysutils.pas- ში) მიუთითებს თუ არა მოცემული ობიექტი ან ინტერფეისი მხარს უჭერს განსაზღვრულ ინტერფეისს. კოდი იმეორებს Screen.Forms კოლექციის საშუალებით (TScreen ობიექტის) - ყველა განაცხადში ამჟამად ნაჩვენები ფორმები. თუ ფორმა ეკრანი.ფორმირება მხარს უჭერს ინტერფეისს, მხარს უჭერს ინტერფეისს ბოლო პარამეტრის პარამეტრის და ბრუნდება ნამდვილი.

ამრიგად, თუ ფორმა ახორციელებს IConfigChanged– ს, icc– ის ცვლადი შეგიძლიათ გამოიყენოთ ინტერფეისის მეთოდები, როგორც ეს ფორმა განხორციელებულია. რა თქმა უნდა, გაითვალისწინეთ, რომ ყველა ფორმას შეიძლება ჰქონდეს საკუთარი განსხვავებული დანერგვა აქვს ApplyConfigChange პროცედურას.

Წინაპრები

დელფში განსაზღვრულ ნებისმიერ კლასს უნდა ჰქონდეს წინაპარი. TObject არის ყველა ობიექტისა და კომპონენტის საბოლოო წინაპარი. ზემოხსენებული იდეა ეხება ინტერფეისებსაც, II ინტერფეისი არის ბაზის კლასი ყველა ინტერფეისისთვის. II ინტერფეისი განსაზღვრავს 3 მეთოდს: QueryInterface, _AddRef და _Release.

ეს ნიშნავს, რომ ჩვენს IConfigChanged- ს აქვს ასევე ამ 3 მეთოდი, მაგრამ ჩვენ არ განვახორციელეთ ეს. ეს იმიტომ ხდება, რომ TForm მემკვიდრეობს TComponent- დან, რომელიც უკვე ახორციელებს II ინტერფეისს თქვენთვის! როდესაც გსურთ განახორციელოთ ინტერფეისი კლასში, რომელიც მემკვიდრეობს TObject– დან, დარწმუნდით, რომ თქვენს კლასს მისგან მემკვიდრეობით იღებს TInterfacedObject– დან. ვინაიდან TInterfacedObject არის ინტერლინგის განმახორციელებელი TOBject. Მაგალითად:

TMyClass = კლასი(TInterfacedObject, IConfigChanged)
პროცედურა ApplyConfigChange;
დასასრული;

დასასრულ დასკვნით, IUnknown = II ინტერფეისი. IUnknown არის COM.