Interfețele există pentru a sprijini un anumit comportament

"Bună, Amigo! Astăzi aș dori să vă spun motivele pentru care există interfețele. Auzi adesea că o anumită clasă, obiect sau entitate acceptă o anumită interfață. Ce înseamnă să suporti o interfață ? "

Într-un sens mai larg, orice interfață este un mecanism pentru ca ceva să interacționeze cu altceva. De exemplu, o telecomandă TV este o interfață la distanță. Un câine înțelege și execută comenzi, ceea ce înseamnă că câinele acceptă o interfață vocală (de control). Pentru a rezuma totul, putem spune că o interfață este o modalitate standardizată de interacțiune a două lucruri, în care ambele părți cunosc standardul. Când o persoană îi spune unui câine să „stea”, comanda sa face parte dintr-o „interfață de control vocal al câinelui”, iar dacă câinele respectă comanda, atunci spunem că câinele acceptă interfața.

Asa este in programare. Metodele sunt acțiuni efectuate asupra unui obiect, asupra datelor acestuia. Și dacă o clasă implementează anumite metode, atunci „sprijină execuția” anumitor comenzi. Ce câștigăm combinând metode într-o interfață?

1) Fiecare interfață , la fel ca o clasă , are un nume unic. Ambele părți pot fi 100% sigure că cealaltă parte acceptă interfața exactă pe care o cunosc și nu o interfață similară.

2) Fiecare interfață impune anumite restricții unei clase care o va suporta. Clasa (dezvoltatorul ei) decide ce va face atunci când sunt apelate metodele moștenite de la o interfață, dar rezultatul ar trebui să fie în limitele așteptărilor rezonabile. Dacă ordonăm unui câine să „stea” și apoi se rostogolește pe loc timp de 5 minute și apoi se așează, atunci acceptă interfața. Dar dacă în schimb te prinde de picior, atunci cu greu putem spune că acceptă interfața. Executarea comenzii nu a produs rezultatul așteptat.

Să presupunem că tu și prietenii tăi scrieți un joc pe computer. Și ai fost desemnat să programezi comportamentul unui personaj. Unul dintre colegii tăi a scris deja cod pentru a afișa toate caracterele pe ecran. Un al doilea coleg, responsabil cu salvarea jocului pe disc, a scris cod pentru a salva toate obiectele jocului într-un fișier. Fiecare dintre ei a scris mult cod și a creat o interfață pentru a interacționa cu acel cod. De exemplu, ar putea arăta astfel:

interface Saveable
{
 void saveToMap(Map<String, Object> map);
 void loadFromMap(Map<String, Object> map);
}

interface Drawable
{
 void draw(Screen screen);
}

class PacMan implements Saveable, Drawable
{
…
}

Cu alte cuvinte, pentru a sprijini orice interfață (grup de interfețe), clasa ta trebuie să:

1) Moștenește-le

2) Implementează metodele declarate în acestea

3) Metodele trebuie să facă ceea ce au fost destinate să facă.

Apoi, restul codului programului, care nu știe nimic despre clasa ta și obiectele sale, poate funcționa cu clasa ta.

„De ce codul nu poate ști nimic despre clasa mea?”

„Să presupunem că ai luat codul dintr-un program pe care cineva l-a scris cu un an în urmă. Sau să presupunem că prietenii tăi au cumpărat/au licențiat motorul de joc de la altcineva. Ai cod de lucru pentru joc. Mii de obiecte care interacționează între ele. Și ei pot interacționa cu ușurință corect cu obiectele tale dacă faci ca această interacțiune să se întâmple prin interfețe pe care clasele tale le-au implementat corect."

"Departe! Nu știam că este posibil."

"Toate proiectele mari funcționează așa. Oamenii au încetat să scrie de la zero cu mult timp în urmă."

De asemenea, oamenii nu reinventează matematica și alfabetul de fiecare dată. În schimb, ei studiază tot ce a fost inventat înaintea lor.