Când se utilizează interfețe pentru programare - blog-art Michael flonova

Recent am luat cu sine întrebarea de ce avem nevoie de interfață, în cazul în care este doar o descriere a funcțiilor și nu există nici o punere în aplicare a codului. Moștenirea este mult mai bine, pentru că puteți crea obiecte cu punerea în aplicare corectă a și doar le moștenesc.







Programarea interfetelor - acesta este cazul, atunci când se poate invarti o teorie a modului în care acestea funcționează, dar cititorul va înțelege esența numai atunci când vede rezultatele cu proprii mei ochi, care este în practică. Și de aceea am decis să arăt câteva exemple de unde și cum pot beneficia de interfața.

Dar, mai întâi, încă destul de un pic de teorie și cuvinte. Clasa - o descriere și punerea în aplicare a obiectului. Obiect - o instanță a acestei clase, și anume, obiectul este creat pe baza descrierii, pe care le scrie în clasa.

Clasa poate efectua o acțiune și el poate avea proprietăți - care este tot ceea ce declarați cu cuvântul cheie static (în C ca limbi). Astfel de metode sunt numite fără nici o inițializare suplimentare și există proprietăți într-un singur exemplar.

Obiectele - sunt exemple de clase. Puteți crea două obiecte din aceeași clasă și vor avea același set de caracteristici (metode) și proprietăți, dar proprietățile fiecare are propriile sale. Modificarea valorilor proprietăților unui obiect, nu atingeți celălalt. Proprietățile și metodele de obiecte - care este tot ceea ce nu declara statice.

Dacă știți și să înțeleagă diferența, e foarte bine.

Interface - o descriere a modului de a efectua o acțiune. El nu poate fi proprietățile și el nu poate face nimic singur, dar el face o sarcină foarte importantă - a spus - deoarece este posibil de a provoca anumite acțiuni pentru a obține rezultate.

Programarea este adesea menționată ca un protocol. Interfața definește protocolul de comunicare, dar nu o pune în aplicare. Și de ce avem nevoie de un protocol de punere în aplicare fără? Este foarte necesar, și să ne uităm la unele cazuri - când și unde poate veni la îndemână.

Interfețe pentru plug-in-uri

Cel mai simplu exemplu - plug-in. Îmi amintesc, înainte de apariția de interfețe în Delphi a subminate și una dintre aceste perversiuni am arătat în prima carte Delphi ochii hacker. În cazul în care Delphi nu suportă interfața, atunci când am scris acel exemplu.

Ce este un plug-in? Este un obiect care efectuează acțiuni separate. Programul principal (cod principal) nu le pasa cum se face o acțiune, și este posibil ca, chiar și un tambur care se întâmplă acolo, sarcina noastră este doar de a oferi o oportunitate de a conecta să se înregistreze cu noi, și trebuie să știm cum să rulați un plug-in pentru a rula.

Deci, avem nevoie pentru a descrie protocolul ca va comunica unul cu celălalt cod și extinderea plugin. Pentru a descrie această interfață:

Aș vrea să-mi cer scuze pentru eventualele amprente și erori în cod. I-am scris aceasta recenzie de pe iPad în OneNote, care nu are un compilator și verifica pentru erori în C # cod.

Aceasta este doar o interfață cu o metodă și o face absolut nimic și nu avea nici o realizare metoda getTest. Aici multe întrebări - și FIG este necesar? Nu este mai bine să declare o clasă abstractă și moștenesc ea? Și nu în grabă, toată distracția înainte.

Acum putem declara o clasă care va descrie casa si casa poate pune în aplicare protocolul nostru:

Acasă clasa. Interfață

GetTest public void ()

// aici este punerea în aplicare a interfețelor

În același mod ca și clase moștenesc din alte clase, ei pot moșteni și interfețe. În acest caz, casa va moșteni interfața. Pentru a corecta o astfel de clasă, acesta trebuie să Bat toate metodele care sunt declarate în raport, și acestea ar trebui să fie deschis, în caz contrar sens zero, de la ei.

Acum putem crea interfața de clasă Acasă:

test de IInterface = nou Acasă ();

Deoarece casa implementează protocolul nostru, atunci tranzacția este absolut legal.

Deși nu beneficii speciale pentru a fi văzut, dar acum am ajuns la momentul în care este deja posibil pentru a vedea beneficiile. Faptul că ancheta în dublu în C # este interzisă. Ce se întâmplă dacă pluginul trebuie să moștenească de la unele clasă? Dacă doriți să pună în aplicare de expansiune sub forma unei clase abstracte de baza, oamenii care vor scrie extensii nu vor fi în măsură să declare o clasă care va moșteni clasa și o clasă de care au nevoie. Va trebui să utilizați denaturare, care nu este în valoare de lumânare.







Deci, nu avem nevoie de o clasă abstractă, avem nevoie de numele interfeței. În acest caz, programator poate scrie oricare din clasa ta de a implementa interfața noastră, și totul va funcționa.

Să ne uităm la un cod complet de un posibil exemplu:

folosind System; // clasice

folosind System.Collections.Generic; // avem nevoie Lista

// poate că am uitat că este ceva să se conecteze și codul nu va compila

// Nu vă faceți griji, pentru cei cărora le place să caute erori, va fi ocupat

// începe fiecare obiect pentru a efectua

foreach (testul IInterface în testele)

În acest exemplu, am creat două clase complet diferite - și o casă de rață. Ele pot fi derivate din orice altă clasă, și poate fi destul de diferite, dar ele sunt încă similare în măsura în care pune în aplicare același protocol (interfață), și asta e tot ce avem nevoie.

În programul său, putem crea o listă de interfețe:

Listtests = o nouă listă ();

Această listă, care este format din obiecte de orice clasă, dar toate dau seama de interfață IInterface.

Apoi am crea o rață, iar casa a fost adăugat din listă și executați o buclă care efectuează metoda getTest.

abstracție

Lucrul la nivel de interfață, luați un pas de punere în aplicare și facilități. Există programatori care iubesc să scrie aproape toate prin interfețe. Aceasta are propria semnificație.

Gluma aici este că, dacă aveți nevoie pentru a scrie o clasa, un server FTP, nu puteți crea un obiect în mod direct, și de a folosi interfata:

bool UploadFile (filename string);

clasa FtpClient. IFtpInterface

UploadFile bool publice (fileName string);

static void Main (string [] args)

// apoi efectuați o acțiune și să le salvați într-un fișier

// acest fișier dorim să încărcați pe server

IFtpInterface client = new FtpClient ();

În acest caz, avem doar o singură metodă la FtpFlient, deci este greu de imaginat un beneficiu, dar imaginați-vă că zeci de metode de clasă. Ce se întâmplă dacă te-ai decis să nu susțină propriul lor cod client FTP, și a decis să se mute la software-ul terț? În acest software terță parte pot fi alte metode și aici vă veți găsi într-un fund complet, dacă utilizați în mod direct obiectele.

Când utilizați interfețe, trebuie doar să pună în aplicare o clasa care implementeaza IFtpInterface si schimba o linie de inițializare. Toate magic funcționează.

Nu folosesc interfețe peste tot, oriunde, dar încerc să le folosească în cazul în care lucrez cu codul terță parte. Dacă munca Delphi cu baze de date a fost realizată prin interfețe, tranziția de la BDE la ADO.NET sau dbExpress ar fi simplu. Dar, din moment ce acest lucru nu este, aș fi în locul tău, m-am adresat la baza prin intermediul interfețelor.

La crearea de interfață descrie metodele din punctul de vedere al clientului. Nu este nevoie să copieze metodele existente deja în ADO.NET, descrie interfața, astfel încât metodele păreau clare clientului.

testarea codului

Interfețe noi și de testare cod de ajutor. Din nou, luați ultimul exemplu în cazul în care avem o metodă principală care efectuează o acțiune, și descarcă fișierul pe server.

- Știm că componenta FtpClient funcționează și pentru a testa la pacientii cu pot fi teste individuale.

- teste de unitate trebuie să fie cât mai simplu posibil, și verificați funcția de ceva, mai degrabă decât doar să fie difuzate.

- Metoda de încercare care descarcă ceva pe server, nu foarte rapid (în funcție de viteza de acces de fișiere FTP și dimensiunea) și disconfort, pentru că după executarea metodei va trebui să fie descărcate de pe FTP și verificați conținutul.

Toate acestea se rezolvă prin utilizarea interfețe.

bool UploadFile (filename string);

clasa FtpClient. IFtpInterface

bool publice UploadFile (fileName string)

Aici vom încărca fișiere pe un server FTP

clasa UnitTestFtpClient. IFtpInterface

bool publice UploadFile (fileName string)

Nu încărcați fișierele oriunde, ci doar ține undeva

Pentru a verifica rezultatul ar putea UnitTest

static void boo (client IFtpInterface)

// apoi efectuați o acțiune și să le salvați într-un fișier

// acest fișier dorim să încărcați pe server

Deci, noi numim o metodă în realitate:

Și acest lucru este în testele unitare.

boo nu are conceptul unei metode care clasa îl va da și el nu-i pasă. Pentru el, cel mai important lucru ca un parametru pentru a fi trecut o clasă care implementează o interfață cunoscută la o metodă destul de clară și necesară. Cod flexibil și ușor să se adapteze la diferite condiții.

Punerea în aplicare a interfețelor

Are fiecare clasă trebuie să scrie o punere în aplicare metoda UploadFile? Același lucru în fiecare clasă va fi o mulțime de aceeași conexiune FTP și transferul de date cod de inițializare.

clasa UnitTestFtpClient. IFtpInterface

bool publice UploadFile (fileName string)

Codul dublarea este minimă și o flexibilitate mai abrupta decat Alina Kabaeva. Iar atunci când ia în considerare faptul că clasele pot moșteni multe interfețe, vom putea combina unele dintre funcțiile din aceeași clasă. Acest lucru are nevoie de multe ori să fie făcut în controlerele, iar modelul este mai bine pentru a realiza un obiectiv clar în fiecare clasă.

P.S. Știu că acest articol este o grămadă de greșeli de tipar, pentru că nota scrisă pe iPad, dar când am scrie, numărul de stocuri mici, mai mult decât de obicei. Știu că acest lucru nu va corecta, eu nu am timp chiar și pentru a re-citit articolul, astfel încât nu este nevoie să scrie o scrisoare cu solicitarea de a corecta unele erori tipografice. Toate celelalte erori pot fi trimise.

Avertizare. Dacă copiați acest articol pe site-ul dvs., apoi lăsați un link direct către această pagină. Vă mulțumim pentru înțelegere