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

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

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

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

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

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

Ако знаете и разбирате разликата, това е добре.

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

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

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

Най-простият пример - добавка. Спомням си, преди появата на интерфейси в Делфи е извратил и един от тези извращения показах в първата книга Delphi очите на хакера. Ако Delphi не поддържа интерфейса, когато написах, че например.

Какво е плъг-ин? Задачата, която изпълнява действия разделят. Основната програма (основна код) не ми пука как се извършва дадено действие, и че е възможно, че дори и барабан, което се случва там, нашата задача е просто да се даде възможност да се включите, за да се регистрирате при нас, и ние трябва да знаем как да стартирате приставка да се изпълнява.

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

Бих искал да се извиня за всички щампи и грешки в кода. Пиша този преглед на IPAD в OneNote, която не разполага с компилатор и проверка за грешки в C # код.

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

Сега можем да декларираме клас, който ще описва къщата и къщата може да реализира нашата протокол:

клас Начало. интерфейс

обществени невалидни GetTest ()

// тук е изпълнението на интерфейси

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

Сега ние можем да създадем клас интерфейс Дома на:

IInterface тест = нов Начало ();

Тъй като къщата изпълнява нашата протокол, след което сделката е абсолютно законно.

Докато няма особени ползи могат да се видят, но сега стигаме до момента, когато тя вече е възможно да се видят ползите. Фактът, че разследването на двойното в C # е забранено. Какво става, ако приставката ни трябва да наследи от някакъв клас? Ако искате да се приложат разширение под формата на абстрактен базов клас, хората, които ще пишат разширения няма да могат да декларира клас, който ще наследи ви клас и клас, който се нуждаят. Вие ще трябва да използвате изкривяването, което не си струва свещ.

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

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

използване на системата; // класически

използване System.Collections.Generic; // имаме нужда Списък

// може би съм забравил има нещо друго, за да се свържете и кодът няма да се компилира

// Не се притеснявай, за тези, които обичат да се търсят грешки, ще бъде зает

// започне всеки обект за извършване

foreach (IInterface тест в тестове)

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

В програмата си, ние можем да създадете списък с интерфейси:

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

Този списък, който се състои от обекти от всякакъв клас, но всички те осъзнават IInterface интерфейс.

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

абстракция

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

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

BOOL UploadFile (низ име);

клас FtpClient. IFtpInterface

обществен булев UploadFile (низ име);

статично невалидни Майн (струнен [] аргументи)

// след това да извършите някакво действие и да ги запишете във файл

// този файл, което искаме да се зареди на сървъра

IFtpInterface клиент = нов FtpClient ();

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

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

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

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

тестване на кода

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

- Ние знаем, че FtpClient компонент работи и да го тествам при пациенти с могат да бъдат индивидуални тестове.

- тестове единица трябва да бъде възможно най-прости, и да провери функцията на нещо, а не просто да работи.

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

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

BOOL UploadFile (низ име);

клас FtpClient. IFtpInterface

обществен булев UploadFile (низ име)

Тук можем да качвате файлове към FTP сървър

клас UnitTestFtpClient. IFtpInterface

обществен булев UploadFile (низ име)

Не зареждайте файлове навсякъде, но просто държа някъде

За да проверите резултата можеше UnitTest

статично невалидни Бу (IFtpInterface клиент)

// след това да извършите някакво действие и да ги запишете във файл

// този файл, което искаме да се зареди на сървъра

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

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

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

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

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

клас UnitTestFtpClient. IFtpInterface

обществен булев UploadFile (низ име)

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

Послепис Знам, че тази статия е един куп правописни грешки, защото бележката пише на Ipad, но когато го напиша, броят на малките запаси повече от обикновено. Знам, че това няма да се поправи, аз нямам време дори да прочетете отново статията, така че не е необходимо да се напише писмо с искане за коригиране на някои печатни грешки. могат да се изпращат всички други грешки.

Предупреждение. Ако копирате тази статия на вашия сайт, а след това да оставите връзка директно към тази страница. Благодарим Ви за разбирането