Mikor kell használni felületek programozás, vr-line - ingyenes e-zine az összes

Programozási interfészek - ez az eset áll fenn, amikor is elhúz egy elmélet, hogyan működnek, de az olvasó meg fogja érteni a lényegét csak akkor látja az eredményeket a saját szememmel, hogy a gyakorlatban. És ez az, amiért úgy döntött, hogy mutatnak néhány példát, hol és hogyan részesülhetnek a felületen.

De először is egy kicsit az elmélet és a szavak. Osztály - a leírás és végrehajtása az objektumot. Object - egy példányát az osztály, vagyis az objektum létrehozásakor a leírás alapján, ami írsz osztályban.

Az osztály valamilyen műveletet végeznek, és ő lehet a tulajdonságok - ez minden, amit nyilvánítja a kulcsszó statikus (C nyelveket). Ezek a módszerek az úgynevezett nélkül további inicializálási és tulajdonságai vannak egy-egy példányban.

Objects - olyan esetek, az osztályok. Hozhat létre két objektum azonos osztályba tartozó, és ugyanaz lesz a készlet jellemzői (módszerek / tulajdonságok), csak az értékek a tulajdonságok más lesz. Az értékek módosítása a tulajdonságai egy tárgy, ne érintse meg a másikat. Tulajdonságok és módszerek tárgyak - ez minden, amit nyilvánítja nem statikus.
Ha tudja és érti a különbséget, csak finom.

Interface - egy leírást, hogyan kell elvégezni bizonyos intézkedéseket. Ő nem lehet a tulajdonságokat, és nem tud semmit önmagáról, de tesz egy nagyon fontos feladat - mondta -, mert lehet, hogy okoz némi akció az eredményt. A programozás gyakran nevezik protokoll. Az interfész meghatározza a kommunikációs protokoll, de nem hajtják végre. És miért van szükségünk egy protokoll alkalmazása nélkül? Ez nagyon fontos, és nézzük meg néhány esetben - amikor és ahol jól jöhet.

Interfészek a plug-inek

A legegyszerűbb példa - plug-in. Emlékszem, eljövetele előtt interfészek Delphi már perverz, és az egyik ilyen perverzió megmutattam az első könyvben Delphi szemében a hacker. Mi az a plug-in? Ez egy objektum, amely végrehajtja bizonyos intézkedéseket. A fő program (fő kód) nem érdekel, hogy egy művelet végrehajtása, és talán még egy dobra, hogy történik ott. A mi feladatunk csak az, hogy lehetőséget teremt a plug-in alkalmazást, és tudnunk kell, hogy hogyan kell egy plug-in futtatásához. Tehát szükségünk, hogy leírja a protokoll fog kommunikálni egymással kód és a bővítmény. Leírni ezt a felületet:

Szeretnék elnézést kérni minden nyomatok és a kódon. Én írom ezt a véleményét az iPad OneNote, amely nem rendelkezik a fordító és a hibák ellenőrzéséhez C # kódot. Ez csak egy interfész az egyik módszer, és ez nem semmi. Ő nem megvalósítás getTest módszer. Itt sok a kérdés - és a FIG van rá szükség? Hát nem jobb, hogy állapítsa meg egy absztrakt osztály, és örökölni? És nem siet, a szórakozás előre. Most nyilvánítja egy osztály, amely leírja a ház és a ház végre a protokoll:

Ugyanígy osztályokat örökölni más osztályokba, akkor örökli és interfészek. Ebben az esetben a házat örökli a felület. Annak érdekében, hogy javítsa egy ilyen osztály, meg kell Bat összes módszert nyilvánítják a jelentésben, és nyitottnak kell lennie, különben nulla értelme tőlük. Most mi is létrehozhatunk az osztály interfész Home:

IInterface teszt = új Home (); Mivel a ház végrehajtja a protokollt, akkor az ügylet teljesen legális. Bár nincs különösebb előnyöket lehetett látni, de mi jön a pont, ahol a sugarak kezdi, hogy az utat a sötétben. Az a tény, hogy a kettős öröklési tilos a C #. Mi van, ha a beépülő modul kell örökölni néhány osztály? Ha azt szeretnénk, hogy végre terjeszkedés formájában elvont alap osztály, a fejlesztők ki írja bővítmények nem lesz képes arra, hogy egy osztályt, amely örökli az osztály és az osztály, hogy szükség van. Meg kell használni a torzítás, ami nem éri meg a gyertyát. Tehát nem kell egy absztrakt osztály, szükségünk van a felület nevét. Ebben az esetben a programozó írhat az Ön osztály végrehajtásához a felületet, és minden a helyére kerül.

Nézzük meg a teljes kód egy lehetséges példa:

Ebben a példában létrehoztunk két teljesen különböző osztály - és egy kacsa házban. Ezek származhatnak bármilyen más típusú, és lehet egészen más, de még mindig hasonlóak abban, hogy ugyanezt a protokollt (interface), és ez minden, amire szükségünk van. Az ő programja, mi is létrehozhatunk egy listát a felületek:

Listtests = new List ();

Ez a lista, amely a tárgyak bármilyen osztályba, de mindannyian észre felület felület. Aztán készítettem egy kacsa, és a házat ki a listából, és fuss egy ciklus, ami végre getTest módszer.

Munka a felület szinten, akkor egy lépést a végrehajtás és a tárgyakat. Vannak programozók, akik szeretnek írni szinte minden interfészeken keresztül. Ez saját jelentését. Joke az, hogy ha meg kell írni egy osztály, egy FTP szerver, akkor nem tud létrehozni egy objektumot, illetve használhatja a felületet:

Ebben az esetben már csak egy módszer FtpFlient, így nehéz elképzelni, hogy egy előny, de elképzelhető, hogy a több tucat osztály módszerek. Mi van, ha úgy döntött, hogy nem támogatja a saját FTP kliens kódot, és az oldalán a fejlődés? Ebben a harmadik féltől származó szoftvert lehet más módszerekkel, és ez az, ahol találja magát egy teljes csacsi, ha használja a tárgyakat közvetlenül.

Amikor használja interfészeket, akkor kell csak, hogy végre egy osztályt, amely megvalósítja IFtpInterface és változtatni egy sor elindulni. Minden varázslatosan működik.

Nem interfészeken mindenhol, bárhol, de igyekszem alkalmazni őket, ahol dolgozom a harmadik féltől származó kódra. Ha a Delphi munkája adatbázisokkal végeztünk interfészen keresztül, az átmenet a BDE ADO.NET vagy dbExpresst egyszerű lenne. De mivel ez nem lennék a helyedben, én intézett a bázis interfészeken keresztül. Létrehozásakor az interfész leírja a módszer a szempontból az ügyfél. Nem kell másolni a módszereket, amelyek már léteznek a ADO.NET, leírja a felületet úgy, hogy a módszerek látszott, hogy az ügyfél.

Interfészek segíteni és a kód tesztelés. Ismét, hogy az utolsó példa, ahol van egy fő módszer, amely bizonyos intézkedéseket, és letölti a fájlt a szerverre.

- Tudjuk, hogy FtpClient komponens működik, és kipróbálni, hogy a betegek lehetnek az egyes vizsgálatokban.
- Unit tesztek legyen a lehető legegyszerűbb, és ellenőrizze a funkciója valamit, ahelyett, hogy csak fut.
- Vizsgálati módszer, amely a letöltött valamit a szerveren, nem túl gyors (attól függően, hogy az FTP fájl hozzáférési sebesség és a méret) és kényelmetlen, mert a kivégzés után a módszert kell majd letölthető az FTP és a tartalom ellenőrzéséhez.

Mindezt úgy valósíthatjuk meg, interfészek.

Így hívjuk eljárás a valóságban:

És ez az egység vizsgálatok.

boo nem rendelkezik a koncepció olyan módszer, amely osztály fogunk adni neki, és nem is érdekli. Számára a legfontosabb dolog, mint a paraméter kell átadni egy osztályt, amely megvalósítja az interfészt ismert eléggé világos és szükséges eljárás. Kód rugalmas és könnyen alkalmazkodni a különböző körülmények között.

Nincs minden osztályban kell írni egy módszer végrehajtását uploadfile? Ugyanez az egyes osztályokban lesz sok az azonos inicializáló kódot FTP kapcsolatot és adatátvitelt.

Párhuzamos kódot minimális, és a rugalmasság meredekebb, mint az Alina Kabaeva. És ha figyelembe vesszük, hogy az osztályok öröklik számos interfész, tudjuk kombinálni néhány funkciója az ugyanabba az osztályba. Ez gyakran kell elvégezni a vezérlőt, és a modell jobb, hogy végre egy világos cél minden osztályban.