Nopea ja yksinkertainen järjestelmä suurten Java-sovellusten kehityksen nopeuttamiseksi edellyttää käyttöliittymien käyttöä. Java-käyttöliittymät ovat suunnitelma liittyvän objektin toiminnoille.
Sisältämällä käyttöliittymiä seuraavaan projektiisi, huomaat edut koko kehitystyön elinkaaren ajan. Rajapintojen eikä objektien koodaustekniikka parantaa kehitystiimin tehokkuutta:
- Kehitystiimin sallitaan luoda nopeasti vuorovaikutus tarvittavien kohteiden välillä pakottamatta tukikohteiden varhaista määrittelyä
- Kehittäjät voivat keskittyä kehitystehtäviinsä tietäen, että integraatio on jo otettu huomioon
- Tarjotaan joustavuutta, jotta rajapintojen uudet toteutukset voidaan lisätä olemassa olevaan järjestelmään ilman suuria koodimuutoksia
- Kehitystiimin jäsenten sopimien sopimusten täytäntöönpano sen varmistamiseksi, että kaikki objektit ovat vuorovaikutuksessa suunnitellulla tavalla
Yleiskatsaus
Koska olio-suuntautuneisiin kehitystoimiin liittyy esineiden vuorovaikutusta, on välttämätöntä kehittää ja valvoa vahvoja sopimuksia näiden objektien välillä. Rajapintojen koodaustekniikka sisältää käyttöliittymien, ei esineiden, käytön ensisijaisena viestintämenetelmänä.
Tämä artikkeli tutustuttaa käyttäjän rajapintojen koodaamisen käsitteeseen yksinkertaisen esimerkin avulla. Seuraava yksityiskohtainen esimerkki auttaa osoittamaan tämän järjestelmän arvon suuremmassa järjestelmässä, joka vaatii useita kehittäjiä. Ennen kuin pääsemme mallikoodiin, tarkastellaan kuitenkin rajapintojen koodaamisen etuja.
Miksi koodata käyttöliittymiin?
Java-käyttöliittymä on kehityssopimus. Se varmistaa, että tietty kohde täyttää tietyn menetelmien joukon. Liitäntöjä käytetään kaikkialla Java-sovellusliittymässä määrittelemään tarvittavat toiminnot objektien vuorovaikutukselle. Esimerkkejä käyttöliittymän käytöstä ovat soittopyynnöt (Tapahtumakuuntelijat), kuviot (Tarkkailija) ja eritelmät (Ajettava, Sarjattavissa).
Rajapintojen koodaus on tekniikka, jolla kehittäjät voivat altistaa tietyt objektin menetelmät muille järjestelmän kohteille. Kehittäjillä, jotka vastaanottavat näiden rajapintojen toteutukset, on mahdollisuus koodata käyttöliittymään itse objektin koodaamisen sijaan. Toisin sanoen kehittäjät kirjoittavat koodin, joka ei ole suoraan vuorovaikutuksessa objektin sellaisenaan, vaan pikemminkin kyseisen objektin käyttöliittymän toteuttamisen kanssa.
Toinen syy koodata rajapinnoille eikä esineille on, että se tarjoaa paremman tehokkuuden järjestelmän elinkaaren eri vaiheissa:
- Design: objektin menetelmät voidaan määrittää nopeasti ja julkaista kaikille kehittäjille, joita asia koskee
- Kehitys: Java-kääntäjä takaa, että kaikki käyttöliittymän menetelmät toteutetaan oikealla allekirjoituksella ja että kaikki käyttöliittymän muutokset näkyvät välittömästi muille kehittäjille
- Liittäminen: on kyky yhdistää luokat tai alijärjestelmät nopeasti yhteen niiden vakiintuneiden rajapintojen ansiosta
- Testaus: rajapinnat auttavat eristämään vikoja, koska ne rajoittavat mahdollisen logiikkavirheen laajuuden tiettyyn menetelmien osajoukkoon
Tähän kehitystekniikkaan liittyy joitain yleiskustannuksia vaaditun koodiinfrastruktuurin vuoksi. Tämä infrastruktuuri sisältää molemmat rajapinnat objektien ja kutsukoodin välistä vuorovaikutusta varten rajapintojen toteuttamisen luomiseksi. Tämä yleiskustannus on merkityksetön verrattuna kuvattujen rajapintojen käytön helppouteen ja hyötyyn.
Perusesimerkki
Selittämään tarkemmin rajapintojen koodaamisen käsitettä, olen luonut yksinkertaisen esimerkin. Vaikka tämä esimerkki on selvästi triviaali, se osoittaa joitakin edellä mainituista eduista.
Harkitse yksinkertaista esimerkkiä luokasta Auto joka toteuttaa käyttöliittymän Ajoneuvo. Käyttöliittymä Ajoneuvo on yksi menetelmä nimeltä alkaa(). Luokka Auto toteuttaa käyttöliittymän tarjoamalla a alkaa() menetelmä. Muut toiminnot Auto luokka on jätetty pois selkeyden vuoksi.
käyttöliittymä Ajoneuvo {// Kaikkien ajoneuvototeutusten on toteutettava aloitustapa public void start (); } luokka Autotyökalut Ajoneuvo {// Vaaditaan ajoneuvon julkisen tyhjäkäynnistyksen () toteuttamiseksi {...}} Kun olet luonut perustan Auto objektin, voimme luoda toisen objektin nimeltä Miespalvelija. Se on Miespalvelijaon aloittaa Auto ja tuo se ravintolan suojelijalle. Miespalvelija objekti voidaan kirjoittaa ilman rajapintoja seuraavasti:
luokan Valet {julkinen auto getCar (auto c) {...}} Miespalvelija objektilla on menetelmä nimeltä getCar joka palauttaa a Auto esine. Tämä koodiesimerkki täyttää järjestelmän toiminnalliset vaatimukset, mutta se linkittää ikuisesti Miespalvelija esine Auto. Tässä tilanteessa näiden kahden kohteen sanotaan olevan tiukasti kytketty. Miespalvelija esine vaatii tietoa Auto ja sillä on pääsy kaikkiin kyseisen objektin sisältämiin julkisiin menetelmiin ja muuttujiin. On parasta välttää tällaista tiukkaa koodin kytkentää, koska se lisää riippuvuuksia ja vähentää joustavuutta.
Koodata Miespalvelija rajapintoja käyttävä objekti, seuraavaa toteutusta voitaisiin käyttää:
luokan Valet {julkinen ajoneuvo getVehicle (ajoneuvo c) {...}} Vaikka koodimuutokset ovat melko pieniä - viitteiden muuttaminen Auto että Ajoneuvo - vaikutukset kehityssykliin ovat huomattavat. Toista toteutusta käyttämällä Miespalvelija hänellä on tietoa vain järjestelmässä määritellyistä menetelmistä ja muuttujista Ajoneuvo käyttöliittymä. Kaikki muut julkiset menetelmät ja tiedot, jotka sisältyvät ohjelman erityistoteutukseen Ajoneuvo käyttöliittymä on piilotettu Ajoneuvo esine.
Tämä yksinkertainen koodimuutos on varmistanut tietojen asianmukaisen piilottamisen ja toteutuksen muilta kohteilta, ja sen vuoksi on poistettu mahdollisuus, että kehittäjät käyttävät ei-toivottuja menetelmiä.
Liitäntäobjektin luominen
Viimeinen asia, josta on keskusteltava tämän kehitystekniikan suhteen, on käyttöliittymäkohteiden luominen. Vaikka on mahdollista luoda uusi luokan ilmentymä käyttämällä Uusi operaattorilla, ei ole mahdollista luoda suoraan rajapinnan esiintymää. Jotta voit luoda käyttöliittymän toteutuksen, sinun on instantioitava objekti ja heitettävä se haluamaasi käyttöliittymään. Siksi kehittäjä, joka omistaa objektikoodin, voi olla vastuussa sekä objektin esiintymän luomisesta että suoratoistosta.
Tämä luomisprosessi voidaan saavuttaa käyttämällä a Tehdas kuvio, jossa ulkoinen objekti kutsuu staattista createXYZ () menetelmä a Tehdas ja palauttaa käyttöliittymän. Se voidaan saavuttaa myös, jos kehittäjä kutsuu menetelmän toiselle objektille ja välittää sen käyttöliittymän varsinaisen luokan sijaan. Tämä olisi analogista Luettelointi käyttöliittymä a. sijasta Vektori tai Hashtable.
Yksityiskohtainen esimerkki
Osoittaakseni tämän järjestelmän käytön suuremmassa projektissa olen luonut esimerkin kokousaikataulusta. Tällä ajastimella on kolme pääkomponenttia: resurssit (neuvotteluhuone ja kokouksen osallistujat), tapahtuma (itse kokous) ja aikatauluttaja (joka ylläpitää resurssikalenteria).
Oletetaan, että nämä kolme komponenttia oli kehitettävä kolmella eri kehittäjällä. Kunkin kehittäjän tavoitteena tulisi olla selvittää komponentinsa käyttö ja julkaista se muille projektin kehittäjille.
Tarkastellaan esimerkkiä a Henkilö. A Henkilö voi toteuttaa useita menetelmiä, mutta toteuttaa Resurssi käyttöliittymä tälle sovellukselle. Olen luonut Resurssi käyttöliittymä kaikkien tarvittavien käyttömenetelmien kanssa kaikille tässä esimerkissä käytetyille resursseille (esitetty alla):
julkinen käyttöliittymä Resurssi {public String getID (); public String getName (); public void addOccurrence (esiintyminen o); } Tässä vaiheessa kehittäjä Henkilö - toiminnallisuus on julkaissut käyttöliittymän, jolla kaikki käyttäjät voivat käyttää Henkilö esine. Koodaaminen käyttöliittymälle auttaa varmistamaan, että kukaan kehittäjä ei käytä Henkilö esine väärällä tavalla. Kehittäjä Aikataulu objekti voi nyt käyttää Resurssi - käyttöliittymä päästäksesi käyttämään tietoja ja toimintoja, jotka ovat tarpeen järjestelmän aikataulun luomiseksi ja ylläpitämiseksi Henkilö esine.
Tapahtuma käyttöliittymä sisältää tarvittavat menetelmät Tapahtuma. Tämä voi olla konferenssi, matkasuunnitelma tai mikä tahansa muu aikataulutustapahtuma. Tapahtuma käyttöliittymä on esitetty alla:
julkinen käyttöliittymä esiintyminen {public void setEndDatetime (päivämäärä d); public Date getEndDatetime (); public void setStartDatetime (päivämäärä d); julkinen päivämäärä getStartDatetime (); public void setDescription (Merkkijonon kuvaus); julkinen merkkijono getDescription (); public void addResource (resurssi r); julkinen resurssi [] getResources (); julkinen totuusarvo tapahtuu On (Päivämäärä d); } Aikataulu koodi käyttää Resurssi käyttöliittymä ja Tapahtuma käyttöliittymä resurssin aikataulun ylläpitämiseksi. Huomaa, että Aikataulu hänellä ei ole tietoa yhteisöstä, jolle se ylläpitää aikataulua:
public class Scheduler toteuttaa aikataulun {Vektoriaikataulu = null; public Scheduler () {aikataulu = uusi vektori (); } public void addOccurrence (esiintyminen o) {aikataulu.addElement (o); } public void removeOccurrence (esiintyminen o) {aikataulu.removeElement (o); } public esiintyminen getOccurrence (päivämäärä d) {Enumeration aikatauluElements = aikataulu.elementit (); Esiintyminen o = nolla; while (scheduleElements.hasMoreElements ()) {o = (esiintyminen) aikatauluElements.nextElement (); // Tässä yksinkertaisessa esimerkissä esiintyminen vastaa, jos // päivämäärä on kokouksen alkamisaika. Tämä logiikka // voidaan tehdä monimutkaisemmaksi tarpeen mukaan. if (o.getStartDatetime () == d) {tauko; }} paluu o; }} Tämä esimerkki osoittaa rajapintojen voiman järjestelmän kehitysvaiheissa. Jokaisella osajärjestelmällä on tietoa vain rajapinnasta, jonka kautta sen on kommunikoitava - toteutuksesta ei tarvita tietoa. Jos kehittäjäryhmät kehittäisivät kutakin yllä olevan esimerkin rakennuspalikoita edelleen, heidän ponnistelunsa yksinkertaistuisivat näiden liitäntäsopimusten täytäntöönpanon vuoksi.
Viimeiset ajatukset rajapinnoista
Tämä artikkeli on osoittanut joitain käyttöliittymiin koodaamisen etuja. Tämä tekniikka mahdollistaa paremman tehokkuuden kehityksen kaikissa elinkaaren vaiheissa.
Projektin suunnitteluvaiheessa rajapinnat mahdollistavat halutun vuorovaikutuksen löytämisen esineiden välillä nopeasti. Tiettyyn rajapintaan liittyvät toteutusobjektit voidaan määrittää sen jälkeen, kun kyseisen käyttöliittymän menetelmät ja vaatimukset on määritelty. Mitä nopeammin vuorovaikutus muodostuu, sitä nopeammin suunnitteluvaihe voi edetä kehitykseen.
Liitännät antavat kehittäjille mahdollisuuden paljastaa ja rajoittaa tiettyjä menetelmiä ja tietoja esineiden käyttäjille muuttamatta itse objektin oikeuksia ja sisäistä rakennetta. Rajapintojen käyttö voi auttaa poistamaan ärsyttävät virheet, jotka ilmenevät, kun useiden kehitystiimien kehittämä koodi integroidaan.
Sopimusten täytäntöönpano tapahtuu käyttöliittymän kautta. Koska käyttöliittymästä sovitaan yleensä projektin suunnitteluvaiheessa, kehittäjillä on mahdollisuus keskittyä yksittäisiin moduuleihinsa ilman, että heidän on huolehdittava kollegoidensa moduuleista. Näiden osajärjestelmien integrointia tehostaa se, että sopimukset on jo pantu täytäntöön koko kehitysvaiheen ajan.
Testaustarkoituksiin voidaan luoda yksinkertainen ohjainobjekti sovittujen rajapintojen toteuttamiseksi. Tämän objektin avulla kehittäjät voivat jatkaa työtään tietäen, että he käyttävät oikeita menetelmiä päästäessään objektiin. Kun objektit otetaan käyttöön testiympäristössä, ohjainluokat korvataan todellisilla luokilla, jolloin objektia voidaan testata ilman koodia tai ominaisuusmuutoksia.
Tämä järjestelmä tarjoaa mahdollisuuden järjestelmän laajentamiseen helposti; esimerkissämme voisimme laajentaa koodia sisältämään enemmän resurssimuotoja, kuten kokoushuoneita ja ääni- / videolaitteita. Ohjelman mahdollinen lisätoimenpide Resurssi käyttöliittymä sopii vakiintuneeseen mekanismiin muuttamatta olemassa olevaa koodia. Tätä järjestelmää käyttävät laajamittaiset projektit voitaisiin suunnitella ja toteuttaa siten, että lisätoimintoja voidaan lisätä ilman suuria muutoksia infrastruktuuriin. Esimerkiksi Kokoustila esine luotiin. Tämä esine toteuttaa Resurssi käyttöliittymä ja voi olla vuorovaikutuksessa Ajoittaa ja Tapahtuma toteuttajia muuttamatta infrastruktuuria.
Toinen etu on koodin keskitetty sijainti. Jos ohjelmaan lisätään uusia menetelmiä Resurssi käyttöliittymän, kaikki tämän käyttöliittymän toteutukset tunnistetaan muutosta vaativiksi. Tämä vähentää tutkimusta, joka tarvitaan rajapinnan muutosten mahdollisten vaikutusten määrittämiseksi.
Kehitysetujen lisäksi tässä artikkelissa esitetty tekniikka antaa projektinhallinnalle varmuuden siitä, että objektien tai järjestelmien väliset viestintämallit on luotu ja toteutettu koko kehitysjakson ajan. Tämä vähentää epäonnistumisten riskiä projektin integrointi- ja testausvaiheessa.
