Ātra un vienkārša shēma, lai paātrinātu liela mēroga Java lietojumprogrammu izstrādi, ietver saskarņu izmantošanu. Java saskarnes ir saistītā objekta funkcionalitātes rasējums.
Iekļaujot saskarnes nākamajā projektā, jūs pamanīsit ieguvumus visā izstrādes darba ciklā. Saskarņu, nevis objektu kodēšanas tehnika uzlabos izstrādes komandas efektivitāti, veicot šādas darbības:
- Ļaujot izstrādes komandai ātri izveidot mijiedarbību starp nepieciešamajiem objektiem, nepiespiežot agrīnu atbalsta objektu definēšanu
- Ļaujot izstrādātājiem koncentrēties uz attīstības uzdevumiem, zinot, ka integrācija jau ir ņemta vērā
- Nodrošina elastību, lai esošajā sistēmā bez lielām koda izmaiņām varētu pievienot jaunas saskarņu ieviešanas iespējas
- Izpildes grupas locekļu saskaņoto līgumu izpilde, lai nodrošinātu, ka visi objekti mijiedarbojas, kā paredzēts
Pārskats
Tā kā uz objektu vērsti izstrādes centieni ir saistīti ar objektu mijiedarbību, ir svarīgi izstrādāt un ieviest stingrus līgumus starp šiem objektiem. Saskarņu kodēšanas paņēmiens ietver saskarņu, nevis objektu izmantošanu kā galveno saziņas metodi.
Šis raksts, izmantojot vienkāršu piemēru, iepazīstinās lietotāju ar saskarņu kodēšanas jēdzienu. Sekos detalizēts piemērs, kas palīdzēs parādīt šīs shēmas vērtību lielākā sistēmā, kurā nepieciešami vairāki izstrādātāji. Pirms mēs nonākam pie koda parauga, apskatīsim saskarņu kodēšanas priekšrocības.
Kāpēc kodēt saskarnēm?
Java saskarne ir izstrādes līgums. Tas nodrošina, ka konkrēts objekts atbilst noteiktajam metožu kopumam. Saskarnes tiek izmantotas visā Java API, lai norādītu objektu mijiedarbībai nepieciešamo funkcionalitāti. Saskarnes izmantošanas piemēri ir atzvanīšanas mehānismi (Pasākumu klausītāji), modeļi (Novērotājs) un specifikācijas (Skrienams, Serializējams).
Saskarņu kodēšana ir metode, ar kuras palīdzību izstrādātāji var pakļaut noteiktas objekta metodes citiem sistēmas objektiem. Izstrādātājiem, kuri saņem šo saskarņu ieviešanu, ir iespēja kodēt interfeisu tā vietā, lai kodētu pašu objektu. Citiem vārdiem sakot, izstrādātāji rakstīs kodu, kas tieši nesadarbojās ar objektu kā tādu, bet drīzāk ar šī objekta saskarnes ieviešanu.
Vēl viens iemesls kodēt saskarnēm, nevis objektiem ir tas, ka tas nodrošina lielāku efektivitāti dažādos sistēmas dzīves cikla posmos:
- Dizains: objekta metodes var ātri norādīt un publicēt visiem ietekmētajiem izstrādātājiem
- Attīstība: Java kompilators garantē, ka visas saskarnes metodes tiek ieviestas ar pareizu parakstu un ka visas saskarnes izmaiņas ir uzreiz redzamas citiem izstrādātājiem
- Integrācija: ir iespēja ātri savienot klases vai apakšsistēmas, pateicoties to labi izveidotajām saskarnēm
- Testēšana: saskarnes palīdz izolēt kļūdas, jo tās ierobežo iespējamās loģiskās kļūdas apjomu līdz noteiktai metožu apakškopai
Nepieciešamās koda infrastruktūras dēļ ar šo izstrādes tehniku ir saistītas dažas izmaksas. Šī infrastruktūra ietver gan saskarnes objektu mijiedarbībai, gan izsaukuma kodu, lai izveidotu saskarņu ieviešanu. Šī pieskaitāmā summa ir nenozīmīga, salīdzinot ar saskarņu izmantošanas vienkāršību un priekšrocībām, kā aprakstīts.
Pamata piemērs
Lai sīkāk izskaidrotu saskarņu kodēšanas jēdzienu, esmu izveidojis vienkāršu piemēru. Lai gan šis piemērs ir acīmredzami niecīgs, tas parāda dažus no iepriekš minētajiem ieguvumiem.
Apsveriet vienkāršo klases piemēru Automašīna kas īsteno saskarni Transportlīdzeklis. Saskarne Transportlīdzeklis ir viena metode, ko sauc sākt(). Klase Automašīna ieviesīs saskarni, nodrošinot sākt() metodi. Citas funkcionalitātes Automašīna klase skaidrības labad ir izlaista.
saskarne Transportlīdzeklis {// Visiem transportlīdzekļa ieviešanas gadījumiem ir jāievieš sākuma metode public void start (); } klase Automašīnas transportlīdzeklis {// Nepieciešams, lai ieviestu Transportlīdzekļa publisko starta vietu () {...}} Liekot pamatus Automašīna objektu, mēs varam izveidot vēl vienu objektu ar nosaukumu Sulainis. Tas ir Sulainisuzdevums sākt Automašīna un nogādājiet to restorāna patronā. The Sulainis objektu var rakstīt bez saskarnēm šādi:
klases Valet {public Car getCar (Car c) {...}} The Sulainis objektam ir metode, ko sauc getCar kas atgriež a Automašīna objekts. Šis koda piemērs atbilst sistēmas funkcionālajām prasībām, taču tas uz visiem laikiem saista Sulainis objekts ar Automašīna. Šajā situācijā tiek uzskatīts, ka abi objekti ir cieši savienoti. The Sulainis objekts prasa zināšanas par Automašīna objektam un tam ir piekļuve visām publiskajām metodēm un mainīgajiem, kas atrodas šajā objektā. Vislabāk ir izvairīties no tik ciešas koda savienošanas, jo tas palielina atkarību un samazina elastību.
Lai kodētu Sulainis izmantojot saskarnes, var izmantot šādu ieviešanu:
klases Valet {publiskā transportlīdzekļa getVehicle (transportlīdzeklis c) {...}} Kaut arī koda izmaiņas ir diezgan nelielas, atsauces mainot no Automašīna uz Transportlīdzeklis - ietekme uz attīstības ciklu ir ievērojama. Izmantojot otro ieviešanu, Sulainis ir zināšanas tikai par metodēm un mainīgajiem, kas definēti Transportlīdzeklis interfeiss. Visas citas publiskas metodes un dati, kas ietverti īpašajā programmas ieviešanā Transportlīdzeklis saskarne ir paslēpta no lietotāja Transportlīdzeklis objekts.
Šī vienkāršā koda maiņa ir nodrošinājusi pareizu informācijas slēpšanu un ieviešanu no citiem objektiem, un tāpēc ir izslēgta iespēja, ka izstrādātāji izmantos nevēlamas metodes.
Interfeisa objekta izveide
Pēdējais jautājums, kas jāapspriež saistībā ar šo izstrādes tehniku, ir saskarnes objektu izveide. Lai gan ir iespējams izveidot jaunu klases instanci, izmantojot jauns operatoru, nav iespējams tieši izveidot saskarnes instanci. Lai izveidotu saskarnes ieviešanu, objekts ir jāpapildina un jāpārnes uz vēlamo interfeisu. Tāpēc izstrādātājs, kuram pieder objekta kods, var būt atbildīgs gan par objekta instances izveidošanu, gan liešanu.
Šo radīšanas procesu var panākt, izmantojot a Rūpnīca modelis, kurā ārējs objekts izsauc statisku izveidotXYZ () metode uz Rūpnīca un atgriež saskarni. To var panākt arī tad, ja izstrādātājs izsauc metodi uz citu objektu un nodod tam saskarni faktiskās klases vietā. Tas būtu līdzīgi kā nokārtot Uzskaitīšana saskarne a Vector vai Hashtable.
Detalizēts piemērs
Lai parādītu šīs shēmas izmantošanu lielākā projektā, esmu izveidojis sapulču plānotāja piemēru. Šim plānotājam ir trīs galvenie komponenti: resursi (konferenču zāle un sapulces dalībnieks), notikums (pati sapulce) un plānotājs (tas, kurš uztur resursu kalendāru).
Pieņemsim, ka šīs trīs sastāvdaļas bija jāizstrādā trim dažādiem izstrādātājiem. Katra izstrādātāja mērķim vajadzētu būt noteikt sava komponenta lietojumu un publicēt to citiem projekta izstrādātājiem.
Apsveriet a. Piemēru Persona. A Persona var ieviest daudzas metodes, bet ieviesīs Resurss saskarne šai lietojumprogrammai. Esmu izveidojis Resurss saskarne ar visām nepieciešamajām piekļuves metodēm visiem šajā piemērā izmantotajiem resursiem (parādīts zemāk):
publiskā saskarne Resurss {public String getID (); publiskā virkne getName (); public void addOccurrence (Notikums o); } Šajā brīdī izstrādātājs Persona funkcionalitāte ir publicējusi saskarni, ar kuras palīdzību visi lietotāji var piekļūt Persona objekts. Kodēšana interfeisam palīdz nodrošināt, ka neviens izstrādātājs neizmanto Persona objektu nepareizi. Izstrādātājs Plānotājs objekts tagad var izmantot Resurss interfeiss, lai piekļūtu informācijai un funkcionalitātei, kas nepieciešama, lai izveidotu un uzturētu Persona objekts.
The Notikums interfeiss satur metodes, kas nepieciešamas Notikums. Tas var būt konference, ceļojuma plāns vai jebkurš cits plānošanas pasākums. The Notikums interfeiss ir parādīts zemāk:
publiskā saskarne Notikums {public void setEndDatetime (Datums d); publiskais datums getEndDatetime (); public void setStartDatetime (datums d); publiskais datums getStartDatetime (); public void setDescription (virknes apraksts); publiskā virkne getDescription (); public void addResource (Resurss r); publiskais resurss [] getResources (); notiek publiska būla vērtība On (Datums d); } The Plānotājs kods izmanto Resurss interfeiss un Notikums saskarne resursa grafika uzturēšanai. Ievērojiet, ka Plānotājs nav zināšanu par entītiju, kurai tā uztur grafiku:
publiskās klases plānotājs īsteno grafiku {Vektoru grafiks = null; public Scheduler () {schedule = new Vector (); } public void addOccurrence (Notikums o) {schedule.addElement (o); } public void removeOccurrence (Notikums o) {schedule.removeElement (o); } public Notikums getOccurrence (Datums d) {Uzskaites grafiksElementi = grafiks.elementi (); Notikums o = nulle; while (scheduleElements.hasMoreElements ()) {o = (Notikums) scheduleElements.nextElement (); // Šajā vienkāršajā piemērā notikums sakrīt, ja // datuma laiks ir sapulces sākuma laiks. Šo loģiku // pēc vajadzības var padarīt sarežģītāku. if (o.getStartDatetime () == d) {pārtraukums; }} atgriezties o; }} Šis piemērs parāda saskarņu spēku sistēmas izstrādes fāzēs. Katrai no apakšsistēmām ir zināšanas tikai par saskarni, caur kuru tai ir jāsazinās, - zināšanas par ieviešanu nav nepieciešamas. Ja katru no iepriekšminētajā piemērā iekļautajiem elementiem tālāk attīstītu izstrādātāju komandas, viņu centieni tiktu vienkāršoti, pateicoties šo saskarnes līgumu izpildei.
Pēdējās domas par saskarnēm
Šis raksts ir parādījis dažas saskarņu kodēšanas priekšrocības. Šis paņēmiens nodrošina lielāku efektivitāti visā attīstības dzīves cikla posmā.
Projekta projektēšanas fāzēs saskarnes ļauj ātri noteikt vēlamo mijiedarbību starp objektiem. Ar konkrēto saskarni saistītos ieviešanas objektus var definēt pēc tam, kad ir norādītas šīs saskarnes metodes un prasības. Jo ātrāk tiek izveidota mijiedarbība, jo ātrāk projektēšanas fāze var pāriet uz attīstību.
Saskarnes dod izstrādātājiem iespēju atklāt un ierobežot noteiktas metodes un informāciju viņu objektu lietotājiem, nemainot paša objekta atļaujas un iekšējo struktūru. Saskarņu izmantošana var palīdzēt novērst nepatīkamās kļūdas, kas parādās, integrējot vairāku izstrādātāju komandu izstrādāto kodu.
Līguma izpildi nodrošina interfeiss. Tā kā saskarne parasti tiek saskaņota projekta projektēšanas posmā, izstrādātājiem ir iespēja koncentrēties uz atsevišķiem moduļiem, neuztraucoties par kolēģu moduļiem. Šo apakšsistēmu integrāciju efektīvāk padara fakts, ka līgumi jau ir izpildīti visā izstrādes posmā.
Testēšanas vajadzībām var izveidot vienkāršu draivera objektu, lai ieviestu saskaņotās saskarnes. Izmantojot šo objektu, izstrādātāji var turpināt darbu, apzinoties, ka izmanto pareizas metodes, lai piekļūtu objektam. Kad objekti tiek izvietoti testa vidē, draiveru klases tiek aizstātas ar patiesajām klasēm, ļaujot objektu pārbaudīt bez koda vai rekvizītu izmaiņām.
Šī shēma nodrošina iespēju viegli paplašināt šo sistēmu; mūsu piemērā mēs varētu paplašināt kodu, iekļaujot vairāk veidu resursus, piemēram, sanāksmju zāles un audio / video aprīkojumu. Jebkura papildu programmas ieviešana Resurss interfeiss iekļausies izveidotajā mehānismā, nemainot esošo kodu. Liela mēroga projektus, kas izmanto šo shēmu, varētu izstrādāt un īstenot tā, lai varētu bez papildu izmaiņām infrastruktūrā pievienot papildu funkcionalitāti. Kā piemēru Konferences telpa objekts tika izveidots. Šis objekts īsteno Resurss saskarni un var mijiedarboties ar Grafiks un Notikums īstenotājiem, nemainot infrastruktūru.
Vēl viens ieguvums ir koda centralizētā atrašanās vieta. Ja programmai jāpievieno jaunas metodes Resurss saskarni, tiks identificētas visas šīs saskarnes ieviešanas iespējas, kas prasa izmaiņas. Tas samazinās nepieciešamo izmeklēšanu, lai noteiktu saskarnes izmaiņu iespējamo ietekmi.
Papildus attīstības priekšrocībām šajā rakstā sniegtā tehnika nodrošina projekta vadību ar pārliecību, ka visā attīstības ciklā ir izveidoti un ieviesti starpobjektu vai starpsistēmu komunikācijas modeļi. Tas samazina neveiksmju risku projekta integrācijas un testēšanas fāzēs.
