Rychlé a jednoduché schéma pro urychlení vývoje rozsáhlých aplikací Java zahrnuje použití rozhraní. Rozhraní Java jsou plánem funkcí obsažených v přidruženém objektu.
Začleněním rozhraní do dalšího projektu si všimnete výhod po celou dobu životnosti vašeho vývojového úsilí. Technika kódování na rozhraní, nikoli na objekty, zlepší efektivitu vývojového týmu tím, že:
- Umožnění vývojovému týmu rychle navázat interakce mezi nezbytnými objekty, aniž by bylo nutné včasně definovat podpůrné objekty
- Umožnění vývojářům soustředit se na své vývojové úkoly s vědomím, že integrace již byla zohledněna
- Poskytování flexibility, aby bylo možné do stávajícího systému přidat nové implementace rozhraní bez zásadní úpravy kódu
- Vymáhání smluv dohodnutých členy vývojového týmu, aby se zajistilo, že všechny objekty budou interagovat tak, jak jsou navrženy
Přehled
Protože snahy o objektově orientovaný vývoj zahrnují interakce objektů, je nezbytné rozvíjet a prosazovat silné smlouvy mezi těmito objekty. Technika kódování do rozhraní zahrnuje použití rozhraní, nikoli objektů, jako primární metodu komunikace.
Tento článek představí uživateli koncept kódování rozhraní prostřednictvím jednoduchého příkladu. Následuje podrobný příklad, který pomůže demonstrovat hodnotu tohoto schématu ve větším systému vyžadujícím více vývojářů. Než se ale dostaneme k ukázkovému kódu, pojďme se podívat na výhody kódování do rozhraní.
Proč kódovat rozhraní?
Rozhraní Java je smlouva o vývoji. Zajišťuje, že určitý objekt splňuje danou sadu metod. Rozhraní se používají v celém Java API k určení funkcí nezbytných pro interakci s objekty. Příklady použití rozhraní jsou mechanismy zpětného volání (Posluchači událostí), vzory (Pozorovatel) a specifikace (Spustitelný, Serializovatelné).
Kódování na rozhraní je technika, pomocí které mohou vývojáři vystavit určité metody objektu jiným objektům v systému. Vývojáři, kteří dostávají implementace těchto rozhraní, mají možnost kódovat rozhraní namísto kódování samotného objektu. Jinými slovy, vývojáři by psali kód, který neinteragoval přímo s objektem jako takovým, ale spíše s implementací rozhraní daného objektu.
Dalším důvodem pro kódování na rozhraní, nikoli na objekty, je to, že poskytuje vyšší účinnost v různých fázích životního cyklu systému:
- Design: metody objektu lze rychle specifikovat a publikovat všem dotčeným vývojářům
- Rozvoj: kompilátor Java zaručuje, že všechny metody rozhraní jsou implementovány se správným podpisem a že všechny změny rozhraní jsou okamžitě viditelné pro ostatní vývojáře
- Integrace: existuje možnost rychlého propojení tříd nebo subsystémů dohromady díky jejich dobře zavedeným rozhraním
- Testování: rozhraní pomáhají izolovat chyby, protože omezují rozsah možné logické chyby na danou podmnožinu metod
S touto technikou vývoje je spojená nějaká režie kvůli požadované infrastruktuře kódu. Tato infrastruktura zahrnuje obě rozhraní pro interakce mezi objekty a vyvolávací kód k vytváření implementací rozhraní. Tato režie je nevýznamná ve srovnání s jednoduchostí a výhodou používání rozhraní, jak je popsáno.
Základní příklad
Pro další vysvětlení konceptu kódování rozhraní jsem vytvořil jednoduchý příklad. I když je tento příklad zjevně triviální, ukazuje některé z výše zmíněných výhod.
Zvažte jednoduchý příklad třídy Auto který implementuje rozhraní Vozidlo. Rozhraní Vozidlo má jedinou metodu nazvanou Start(). Třída Auto implementuje rozhraní poskytnutím Start() metoda. Další funkce v Auto třída byla kvůli jasnosti vynechána.
interface Vehicle {// Všechny implementace vozidel musí implementovat metodu start public void start (); } třída Car implementuje Vehicle {// Vyžadováno k implementaci Vehicle public void start () {...}} Po položení základů Auto objekt, můžeme vytvořit další objekt s názvem Komorník. To je Komorníkmá za úkol zahájit Auto a dones to patronovi restaurace. The Komorník objekt lze psát bez rozhraní, a to následovně:
třída Valet {veřejné auto getCar (auto c) {...}} The Komorník objekt má metodu nazvanou getCar který vrací a Auto objekt. Tento příklad kódu splňuje funkční požadavky systému, ale navždy propojuje Komorník objekt s objektem Auto. V této situaci se říká, že tyto dva objekty jsou úzce spojeno. The Komorník objekt vyžaduje znalost Auto objekt a má přístup ke všem veřejným metodám a proměnným obsaženým v tomto objektu. Nejlepší je vyhnout se tak těsnému propojení kódu, protože to zvyšuje závislosti a snižuje flexibilitu.
Chcete-li kódovat Komorník objekt pomocí rozhraní, lze použít následující implementaci:
třída Valet {veřejné vozidlo getVehicle (vozidlo c) {...}} Zatímco změny kódu jsou poměrně malé - změna odkazů z Auto na Vozidlo - dopady na vývojový cyklus jsou značné. Pomocí druhé implementace Komorník má znalosti pouze o metodách a proměnných definovaných v Vozidlo rozhraní. Jakékoli další veřejné metody a údaje obsažené ve specifické implementaci Vozidlo uživatelské rozhraní je skryto před uživatelem Vozidlo objekt.
Tato jednoduchá změna kódu zajistila správné utajení informací a implementaci před jinými objekty, a proto vyloučila možnost, že vývojáři použijí nežádoucí metody.
Vytváření objektu rozhraní
Posledním problémem, který je třeba v souvislosti s touto vývojovou technikou prodiskutovat, je vytvoření objektů rozhraní. I když je možné vytvořit novou instanci třídy pomocí Nový operátor, není možné přímo vytvořit instanci rozhraní. Chcete-li vytvořit implementaci rozhraní, musíte vytvořit instanci objektu a vložit jej do požadovaného rozhraní. Proto může být vývojář, který vlastní kód objektu, zodpovědný jak za vytvoření instance objektu, tak za provedení castingu.
Tohoto procesu vytváření lze dosáhnout pomocí a Továrna vzor, ve kterém externí objekt volá statický createXYZ () metoda na a Továrna a vrátí rozhraní. Lze jej také dosáhnout, pokud vývojář zavolá metodu na jiný objekt a předá mu rozhraní místo skutečné třídy. To by bylo analogické s předáním Výčet rozhraní místo a Vektor nebo Hashtable.
Podrobný příklad
Abychom demonstrovali použití tohoto schématu na větším projektu, vytvořil jsem příklad plánovače schůzek. Tento plánovač má tři hlavní součásti: zdroje (konferenční místnost a účastník schůzky), výskyt (samotná schůze) a plánovač (ten, kdo udržuje kalendář zdrojů).
Předpokládejme, že tyto tři komponenty měly být vyvinuty třemi různými vývojáři. Cílem každého vývojáře by mělo být zjistit využití jeho komponenty a publikovat jej ostatním vývojářům na projektu.
Zvažte příklad a Osoba. A Osoba může implementovat řadu metod, ale bude implementovat Zdroj rozhraní pro tuto aplikaci. Vytvořil jsem Zdroj rozhraní se všemi nezbytnými přístupovými metodami pro všechny prostředky použité v tomto příkladu (viz níže):
veřejné rozhraní Zdroj {public String getID (); public String getName (); public void addOccurrence (Výskyt o); } V tomto okamžiku vývojář Osoba zveřejnila rozhraní, pomocí kterého mají všichni uživatelé přístup k informacím uloženým v Osoba objekt. Kódování rozhraní pomáhá zajistit, aby žádný vývojář nepoužíval Osoba objekt nesprávným způsobem. Vývojář Plánovač objekt nyní může používat metody obsažené v souboru Zdroj rozhraní pro přístup k informacím a funkcím nezbytným k vytvoření a udržování harmonogramu Osoba objekt.
The Výskyt Rozhraní obsahuje metody nezbytné pro plánování Výskyt. Může to být konference, cestovní plán nebo jakákoli jiná událost plánování. The Výskyt rozhraní je zobrazeno níže:
veřejné rozhraní Výskyt {public void setEndDatetime (datum d); public Date getEndDatetime (); public void setStartDatetime (datum d); public Date getStartDatetime (); public void setDescription (popis řetězce); public String getDescription (); public void addResource (zdroj r); public Resource [] getResources (); public boolean occursOn (datum d); } The Plánovač kód používá Zdroj rozhraní a Výskyt rozhraní k udržení harmonogramu zdroje. Všimněte si, že Plánovač nemá žádné znalosti o subjektu, pro který udržuje plán:
public class Scheduler implementuje Schedule {Vector schedule = null; public Scheduler () {schedule = new Vector (); } public void addOccurrence (Occurrence o) {schedule.addElement (o); } public void removeOccurrence (výskyt o) {schedule.removeElement (o); } veřejný výskyt getOccurrence (datum d) {Enumeration scheduleElements = schedule.elements (); Výskyt o = null; while (scheduleElements.hasMoreElements ()) {o = (Occurrence) scheduleElements.nextElement (); // V tomto jednoduchém příkladu se výskyt shoduje, pokud // datetime je čas zahájení schůzky. Tato logika // může být podle potřeby složitější. if (o.getStartDatetime () == d) {break; }} vrátit o; }} Tento příklad ukazuje sílu rozhraní ve vývojových fázích systému. Každý ze subsystémů má znalosti pouze o rozhraní, přes které musí komunikovat - není nutná žádná znalost implementace. Pokud by každý ze stavebních bloků ve výše uvedeném příkladu měl být dále vyvíjen týmy vývojářů, jejich úsilí by se zjednodušilo kvůli vynucování těchto smluv o rozhraní.
Závěrečné myšlenky na rozhraní
Tento článek demonstroval některé výhody kódování rozhraní. Tato technika umožňuje vyšší efektivitu v každé fázi životního cyklu vývoje.
Během fází návrhu projektu umožňují rozhraní rychlé navázání požadovaných interakcí mezi objekty. Objekty implementace spojené s daným rozhraním lze definovat po zadání metod a požadavků pro dané rozhraní. Čím rychleji dojde k navázání interakce, tím rychleji může fáze návrhu přejít do vývoje.
Rozhraní dávají vývojářům možnost vystavit a omezit určité metody a informace na uživatele svých objektů, aniž by museli měnit oprávnění a vnitřní strukturu samotného objektu. Použití rozhraní může pomoci eliminovat otravné chyby, které se objevují při integraci kódu vyvinutého několika vývojovými týmy.
Vymáhání smlouvy zajišťuje rozhraní. Protože rozhraní je obecně dohodnuto během fáze návrhu projektu, vývojáři mají schopnost soustředit se na své jednotlivé moduly, aniž by se museli starat o moduly svých kolegů. Integraci těchto subsystémů zefektivňuje skutečnost, že smlouvy byly vynucovány již během vývojové fáze.
Pro účely testování lze vytvořit jednoduchý objekt ovladače pro implementaci dohodnutých rozhraní. Pomocí tohoto objektu mohou vývojáři pokračovat ve své práci s vědomím, že pro přístup k objektu používají správné metody. Když jsou objekty nasazeny v testovacím prostředí, třídy ovladačů jsou nahrazeny třídami true, což umožňuje testování objektu bez změn kódu nebo vlastností.
Toto schéma poskytuje možnost snadného rozšíření tohoto systému; v našem příkladu bychom mohli rozšířit kód tak, aby zahrnoval více forem zdrojů, jako jsou zasedací místnosti a audio / video zařízení. Jakákoli další implementace Zdroj rozhraní zapadne do zavedeného mechanismu bez úpravy stávajícího kódu. Velké projekty využívající toto schéma by mohly být navrženy a implementovány takovým způsobem, že je možné přidat další funkce bez větších úprav infrastruktury. Jako příklad lze uvést Konferenční místnost objekt byl vytvořen. Tento objekt implementuje Zdroj rozhraní a může komunikovat s Plán a Výskyt implementátory beze změny infrastruktury.
Další výhodou je centralizované umístění kódu. Pokud mají být do metody přidány nové metody Zdroj budou všechny implementace tohoto rozhraní označeny jako vyžadující změnu. Tím se sníží potřeba šetření k určení možného dopadu změn rozhraní.
Kromě výhod pro vývoj poskytuje technika představená v tomto článku řízení projektů se zárukou, že během celého vývojového cyklu byly zavedeny a vynucovány interobjektové nebo mezisystémové komunikační vzory. To snižuje riziko selhání během fáze integrace a testování projektu.
