Кога да се използва интерфейс за програмиране, VR-онлайн - безплатно електронно списание за всички

Програмни интерфейси - това е така, когато можете да се върти една теория за това как те работят, но читателят ще разбере същността само когато вижда резултатите със собствените си очи, че е на практика. И затова реших да покажа няколко примера за това къде и как можете да се възползвате от интерфейса.

Но първо, все още доста малко теория и думи. Клас - описание и изпълнение на обекта. Обект - инстанция на този клас, т.е., обектът е създаден на базата на описанието, което ти пиша в клас.

Класът може да изпълнява някакво действие и той може да има свойствата - това е всичко, което можете да декларира с статични ключова дума (в C като езици). Такива методи се наричат ​​без никакво допълнително инициализация и съществуват имоти в един екземпляр.

Обекти - са случаи на класове. Можете да създадете два обекта от същия клас, и те ще имат един и същ набор от функции (методи / свойства), само на стойностите на имотите ще бъдат различни. Промяна на стойностите на свойствата на един обект, не е докоснат от друга. Свойства и методи на обекти - това е всичко, че не декларират статична.
Ако знаете и разбирате разликата, това е добре.

Интерфейс - описание на това как да се извърши някакво действие. Той не може да бъде свойствата и той не може да направи себе си нищо, но той прави много важна задача - казва - тъй като е възможно да причини някои действия, за да получите резултати. Програмирането е често по-нататък протокол. Интерфейсът дефинира протокола за комуникация, но не го изпълни. И защо ни е необходим един протокол, без да бъдат приложени? Това е много необходимо, и нека да разгледаме някои случаи - когато и където тя може да дойде по-удобно.

Интерфейси за плъгини

Най-простият пример - добавка. Спомням си, преди появата на интерфейси в Делфи съм извратен, и един от тези извращения съм показаха в първата книга Delphi очите на хакера. Какво е плъг-ин? Това е обект, който изпълнява определени действия. Основната програма (основна код) не ми пука как се извършва дадено действие, а може би дори и на барабан, което се случва там. Нашата задача е само да се даде възможност да се създаде приставка приложение, и ние трябва да знаем как да стартирате приставка да се изпълнява. Така че, ние трябва да се опише като протоколът ще комуникират един с друг код и разширение плъгин. За да се опише този интерфейс:

Бих искал да се извиня за всички щампи и грешки в кода. Пиша този преглед на IPAD в OneNote, която не разполага с компилатор и проверка за грешки в C # код. Това е само един интерфейс с един метод и го прави абсолютно нищо. Той няма реализация метод getTest. Тук мнозина въпрос - и ФИГ, че е необходимо? Не е ли по-добре да обяви абстрактен клас и да го наследи? И не бързат, всички удоволствия напред. Сега можем да декларираме клас, който ще описва къщата и къщата може да реализира нашата протокол:

По същия начин, както и класове наследяват от други класове, те могат да наследят и интерфейси. В този случай, къщата ще наследи на интерфейса. За да се коригира този клас, трябва да Bat всички методи, които са обявени в доклада, и те трябва да бъдат отворени, в противен случай нулев смисъл от тях. Сега ние можем да създадем клас интерфейс Дома на:

IInterface тест = нов Начало (); Тъй като къщата изпълнява нашата протокол, след което сделката е абсолютно законно. Докато няма особени ползи за да се види, но стигаме до точката, където лъчите му ще започнат да направи своя път през тъмнината. Фактът, че двойното наследство е забранено в C #. Какво става, ако приставката ни трябва да наследи от някакъв клас? Ако искате да се приложат разширение под формата на абстрактен базов клас, разработчиците, които ще пишат разширения, няма да могат да декларира клас, който ще наследи на класа си, и класа, които имат нужда. Вие ще трябва да използвате изкривяването, което не си струва свещ. Така че ние нямаме нужда от абстрактен клас, ние се нуждаем от името на интерфейса. В този случай, програмистът може да пише някой от класа си да приложат нашия интерфейс, и всичко ще се получи.

Нека да разгледаме пълен код на възможен пример:

В този пример, ние сме създали две напълно различни класа - и къща патица. Те могат да бъдат получени от друг клас, и може да бъде доста по-различно, но те все още са сходни с това, че прилагането на същия протокол (интерфейс), и това е всичко, което трябва. В програмата си, ние можем да създадете списък с интерфейси:

Listtests = нов Списък ();

Този списък, който се състои от обекти от всякакъв клас, но всички те се реализира интерфейс интерфейс. Тогава се създаде патица и къщата беше добавен в списъка и тече една линия, която изпълнява метод getTest.

Работата на ниво интерфейс, можете да направите стъпка по изпълнението и обекти. Има програмисти, които обичат да пишат почти всички през интерфейсите. Това има своя смисъл. Joke тук е, че ако трябва да се напише клас, на FTP сървър, няма да може да се създаде обект директно и да използвате интерфейса:

В този случай имаме само един метод на FtpFlient, така че е трудно да си представим полза, но представете си, че десетките методи на клас. Какво става, ако реши да не подкрепи собствената си FTP клиент код, и към страната на развитието? В този софтуер от трета страна може да бъде други методи, а това е мястото, където се окажете в пълен задник, ако използвате обектите директно.

При използване интерфейс, само трябва да се приложи клас, който реализира IFtpInterface и промяна на един ред инициализация. Всички магически работи.

Аз не се използват интерфейси навсякъде, където и да е, но аз се опитвам да ги прилага, когато работя с код на трета страна. Ако работата на Delphi с бази данни се извършва чрез интерфейси, преходът от BDE да ADO.NET или DBExpress ще бъде просто. Но тъй като това не е, щях да съм на твое място, бих адресирано към основата чрез интерфейси. При създаването на интерфейс описва методите от гледна точка на клиента на. Няма нужда да се копира методите, които вече съществуват в ADO.NET, описва интерфейса, така че методите изглеждаха ясни до клиента.

Интерфейси с нас и код тестване помогнат. Отново, да вземе последния пример, където ние имаме основен метод, който изпълнява някакво действие, и изтегля файла на сървъра.

- Ние знаем, че FtpClient компонент работи и да го тествам при пациенти с могат да бъдат индивидуални тестове.
- тестове единица трябва да бъде възможно най-прости, и да провери функцията на нещо, а не просто да работи.
- Метод за изпитване, която сваля нещо на сървъра, не много бързо (в зависимост от скоростта на достъп FTP и големината на файла) и неудобно, защото след изпълнението на метода ще трябва да бъде изтеглен от ВТП и провери съдържанието.

Всичко това се решава чрез използване на интерфейси.

Така че ние наричаме метод в действителност:

И това е в тестовете на устройството.

Бу не разполага с концепцията за метод, който клас ние ще му даде и той не го е грижа. За него най-важното нещо като параметър да бъде приет един клас, който реализира интерфейс известно, че доста ясно и необходим начин. Код гъвкава и лесна за адаптиране към различни условия.

Трябва ли всеки клас да напише изпълнение метод UploadFile? Същото във всеки клас ще бъде много по същия FTP връзка и пренос на данни инициализация код.

Код на дублирането е минимална, и гъвкавостта е по-стръмен от тази на Алина Кабаева. И като се има предвид, че класовете могат да наследят произволен брой интерфейси, ние можем да комбинираме някои от функциите в един и същи клас. Това често трябва да се направи в контролерите, а моделът е по-добре да се извърши една ясна цел във всеки клас.