Automatické generovanie kódu je pri vývoji softvéru čoraz bežnejšie, čo je výsledkom potreby zakryť zložitosť pred vývojárom softvéru a prijatia rôznych štandardných a de facto štandardných rozhraní pre programovanie aplikácií. Skrývanie zložitosti pred vývojárom možno demonštrovať vytvorením tried stub a skeleton v CORBA z ich popisov jazykov definície rozhraní a niektorými objektovo orientovanými databázami, ktoré vytvárajú potrebný kód adaptéra na pretrvávanie a načítanie objektov z databázy.
Java obsahuje mnoho rozhraní API, ktoré vývojári Java považujú za de facto štandardy. Zložitosť týchto rozhraní API sa pohybuje od tých, ktoré tvoria „jadro“ jazyka Java, až po tie, ktoré sa nachádzajú v platforme Java 2 Enterprise Edition. Napríklad rozhranie Java Database Connectivity API predstavuje zjednocujúce rozhranie pre interakciu s databázami od rôznych spoločností. Predpokladajme, že chcete, aby bol objekt Java schopný pretrvávať v databáze implementáciou jednoduchého uložiť () metóda mapujúca atribúty objektu na databázovú tabuľku. Táto metóda by extrahovala atribúty z objektu a použila rozhranie JDBC API na vytvorenie príkazu JDBC, ktorý sa vykoná proti databáze. Po zavedení uložiť () metóda pre niekoľko tried, začnete vidieť podobnosti v štruktúre kódu a opakovanú povahu implementácie tejto metódy. Základné atribúty objektu musia byť často prepisované a „zapojené“ do príslušného Java API. To je prípad, kedy môže byť generátor kódu užitočným nástrojom, ktorý môžete mať vo svojom paneli programovacích nástrojov.
Použitím generátora kódu môžete automatizovať proces niektorých zdĺhavých, opakujúcich sa úloh a úloh kódovania náchylných na chyby. Skutočnosť, že sa pripájate k známym API, zvyšuje užitočnosť takéhoto nástroja, pretože je použiteľný pre široké spektrum vývojárov. Niektoré typicky „vlastné“ rámce špecifické pre doménu možno ďalej považovať za fixné ciele API pre generátory kódu.
Generátor kódu môže byť nástrojom na úsporu času, ktorý zvyšuje kvalitu kódu a zavádza formálnejší a automatizovanejší prístup k časti vývojového cyklu. Ďalšou výhodou automatizovaného generovania kódu je synchronizácia definícií objektov v rôznych programovacích jazykoch. V mnohých úzko prepojených aplikáciách musí byť rovnaký obchodný objekt (napríklad objednávka na nákup skladového materiálu) konzistentne zastúpený v jazykoch C ++, Java a SQL. Schopnosť vydávať rôzne reprezentácie zo spoločného modelu je k dispozícii v rôznych modelovacích nástrojoch; zistil som však, že je nepríjemné používať tieto nástroje na dosiahnutie požadovanej úrovne prispôsobenia. Vyhradený generátor vlastných kódov je dosť jednoduchý na vytvorenie a nespája vás s konkrétnym nástrojom na modelovanie.
Cesta na Javadoc
Cesta, ktorú môj tím zvolil Javadoc na účely generovania kódu, bola trochu dlhá a pravdepodobne bežná. V raných implementáciách sme pomocou skriptov Perl analyzovali vlastnú gramatiku metadát v textovom súbore. Toto bolo riešenie ad hoc a bolo ťažké pridať ďalšie výstupné formáty. Náš druhý, krátkodobý pokus bol upraviť existujúci kompilátor IDL založený na Jave. Čoskoro sme si uvedomili, že na zasielanie rád do generátora kódu bude treba zaviesť ďalšie kľúčové slová IDL. Vytvorenie rozšírenia IDL alebo dokonca úplne od nuly pomocou nástrojov ako lex a yacc (ktoré rozdelia zdrojový súbor na tokeny a definujú kód, ktorý sa použije pre každý rozpoznaný token) neboli osobne chutné. (Ďalšie informácie nájdete v zdrojoch.)
Tretie sľubnejšie riešenie bolo popísať metaúdaje triedy pomocou XML. Definovanie schémy XML DTD a vytváranie dokumentov XML na opis tried sa javilo ako prirodzené riešenie. Súbor potom bolo možné overiť a ľahko analyzovať. Aby som nezačal od nuly, domyslel som si, že sa niekto musel pokúsiť o vytvorenie podobného XML DTD, a čoskoro som narazil na XMI. XMI je podrobný popis UML pomocou XML a teraz sa používa ako výmenný formát medzi UML nástrojmi. (Ďalšie informácie nájdete v zdrojoch.)
Dokumenty XML, ktoré popisovali triedy, však boli mimoriadne podrobné a manuálne sa ťažko upravovali. Existuje iba príliš veľa zdanlivo nadbytočných značiek a popisov, ktoré je potrebné prekonať, aby ste mohli zmeniť jeden atribút triedy. Manipulácia so súbormi XML na úrovni aplikačnej domény môže byť tiež dosť namáhavá. IBM alphaWorks vyrába sadu nástrojov XMI, ktorá výrazne uľahčuje spracovanie dokumentov XML založených na XMI, ale rozhranie API sady XMI na manipuláciu s popismi tried je veľmi podobné rozhraniu Java Reflection alebo Doclet API. S ohľadom na to sa moja organizácia rozhodla použiť prístup doclet, ktorý bol úspešný.
Predstavujeme Javadoc
Javadoc je program, ktorý sa používa na vytvorenie dokumentácie rozhrania Java API vo formáte HTML. Je distribuovaný ako súčasť Java SDK a jeho výstupná fáza je navrhnutá tak, aby bola rozšíriteľná prostredníctvom vytvárania doclet. Rozhranie Doclet API poskytuje infraštruktúru na prístup ku všetkým aspektom súboru zdrojového kódu Java, ktorý bol analyzovaný Javadocom. Pomocou rozhrania Doclet API, ktoré je podobné rozhraniu Reflection API, môžete prejsť popisom triedy Java, získať prístup k vlastným značkám Javadoc a zapisovať výstup do súboru. Štandardný doclet, ktorý sa použil na vytvorenie dokumentácie HTML, to robí; pri prechode celým zdrojovým kódom Java zapisuje súbory HTML. Podrobnejšie informácie o Javadoc nájdete v Zdrojoch.
Vytvorením jednoduchých tried Java, ktoré obsahujú atribúty a niektoré vlastné značky Javadoc, umožníte týmto triedam slúžiť ako jednoduchý popis metadát na generovanie kódu. Javadoc tieto triedy metaúdajov analyzuje a vlastné dolety majú prístup k informáciám o triedach metaúdajov, aby vytvorili konkrétne implementácie triedy metaúdajov v konkrétnych programovacích jazykoch, ako sú Java, C ++ alebo SQL. Môžete tiež vytvoriť variácie štandardného docletu, ktorý vytvára jednoduché tabuľky HTML popisujúce triedu metadát, ktoré by bolo vhodné zahrnúť do dokumentu textového procesora. Tieto metaúdaje triedy Java slúžia na rovnaký účel ako popis IDL, ktorého syntax je podobná ako v C ++.
Používanie Javadocu ako nástroja na generovanie kódu má niekoľko výhod:
- Nemusíte písať žiadny kód analýzy; analýzu tried metadát vykonáva Javadoc a je prezentovaná v ľahko použiteľnom rozhraní API.
- Používaním vlastných značiek Javadoc pridávate dostatočnú flexibilitu na definovanie špeciálnych prepojení počas generovania kódu.
- Pretože typy Java sú dobre definované, int je 32 bitov; na dosiahnutie tejto úrovne prehľadnosti preto nemusíte zavádzať ďalšie kľúčové slová primitívneho typu.
- Triedy metadát Java môžete skontrolovať syntax a ďalšie chyby kompiláciou.
Predstavujeme vám tabuľky
Predtým, ako skočím do docletu používaného na generovanie kódu, uvediem jednoduchý príklad „Hello World“, ktorý odhalí príslušné časti toho, ako vytvárať, bežať a hrať sa s Doclet API. Ukážkový kód pre SimpleDoclet je uvedený nižšie. (Zdrojový kód tohto článku nájdete v dokumente Zdroje.) Ak považujete tento kód za skutočne zdĺhavý pre skutočný program „Hello World“, webová stránka spoločnosti Sun predstavuje ešte jednoduchší program doclet, ktorý vám pomôže začať. (Pozri zdroje.)
balíček codegen.samples; import com.sun.javadoc. *; import java.text. *; public static boolean start (RootDoc root) {// opakuje všetky triedy. ClassDoc [] triedy = root.classes (); for (int i = 0; i <classes.length; i ++) {// opakujte všetky metódy a vytlačte ich názvy. MethodDoc [] metódy = triedy [i] .methods (); out („Metódy“); von("-------"); pre (int j = 0; jVyššie uvedený doclet vypíše popisné informácie o triedach, metódach, poliach a niektoré informácie o značkách Javadoc triedy SimpleOrder.java uvedené nižšie:
public class SimpleOrder {public SimpleOrder () {} public String getSymbol () {return Symbol; } public int getQuantity () {{popisné návratové množstvo; } / ** * Platný symbol akcií. * * @see Ďalšie informácie nájdete vo veľkej knihe platných symbolov. * / súkromný reťazcový symbol; / ** * Celkový objem objednávky. * * @mytag Moja vlastná značka. * / private int Množstvo; private String OrderType; súkromný plavák Cena; trvanie súkromného reťazca; private int AccountType; private int TransactionType; } Po kompilácii týchto súborov vyvoláte nástroj Javadoc pomocou tohto príkazu:
javadoc -private -doclet codegen.samples.SimpleDoclet SimpleOrder.java
The -súkromné Táto voľba povie Javadocu, aby vystavil informácie o súkromnom poli a metóde, a -doklet voľba povie Javadoc, čo má doclet vyvolať. Posledným parametrom je súbor, ktorý sa má analyzovať. Výstupom z programu je:
Načítava sa zdrojový súbor SimpleOrder.java ... Vytvára sa informácie o Javadoc ... Metódy ------- Metóda: name = getSymbol Metóda: name = getQuantity Fields ------ Pole: name = Symbol, comment = A valid burzový symbol., typ = java.lang.String; Názov značky poľa = @ pozri Hodnota značky poľa = Pre viac informácií veľká kniha platných symbolov. Pole: názov = množstvo, komentár = celkový objem objednávky., Typ = int; Názov značky poľa = @mytag Hodnota značky poľa = Moja vlastná značka. Pole: name = OrderType, comment =, type = java.lang.String; Pole: meno = cena, komentár =, typ = float; Pole: name = Duration, comment =, type = java.lang.String; Pole: name = AccountType, comment =, type = int; Pole: name = TransactionType, comment =, type = int;
Ukážkový kód ukazuje, že Doclet API je obsiahnuté v balíku com.sun.javadoc. Pretože sa pripájate k nástroju Javadoc a nevytvárate samostatnú aplikáciu, Javadoc zavolá váš doclet z metódy verejný statický boolovský štart (root RootDoc).
Raz začať metóda sa vykoná, RootDoc uchováva všetky informácie analyzované Javadocom. Potom môžete začať prechádzať všetkými analyzovanými triedami vyvolaním metódy triedy () na RootDoc. Táto metóda vráti a ClassDoc pole popisujúce všetky analyzované triedy. ClassDoc zase obsahuje metódy ako napr polia () a metódy (). Tieto metódy sa vracajú FieldDoc a MethodDoc polia, ktoré popisujú všetky polia a metódy analyzovanej triedy. Metódu obsahujú všetky triedy „Doc“ značky, ktorá vracia a Označiť pole popisujúce vlastné aj štandardné značky Javadoc. Štandardná značka použitá v tomto príklade je @ pozri.
The von() metóda jednoducho zabalí štandardný výstup a MessageFormat trieda pomáha formátovať výstup podľa pevnej šablóny.
Opätovne použiteľné triedy na generovanie kódu
Vo svetle vyššie uvedeného príkladu dúfam, že súhlasíte s tým, že vytvorenie vlastných dokletov a extrahovanie informácií o triedach pomocou rozhrania Doclet API je jednoduché. Ďalší krok k analýze tried Java a generovaniu kódu do súboru je pomerne priamy. Na uľahčenie vytvárania tabuliek na generovanie kódu som vyvinul malú sadu rozhraní a abstraktných základných tried. Schéma tried týchto tried obslužných programov je uvedená nižšie.
Rozhranie Tvorca definuje podpis metódy public void make (ClassDoc classdoc) ktoré budete používať na interakciu so svojimi generátormi kódu. Abstraktná trieda CodeMaker poskytuje predvolené implementácie na manipuláciu so súbormi a zarážkami, ktoré sú spoločné pre všetky generátory kódu. Špecifické generátory kódu dedia z abstraktnej základnej triedy a poskytujú implementáciu urobiť metóda. The urobiť metóda má triedu ClassDoc ako argument nie RootDoc. To spôsobuje Tvorca zadať logiku generovania kódu na úrovni triedy.
Všetky triedy analyzované Javadocom sú prekrútené v metóde doplnku doclets začať. Príklad toho, ako sa to deje (popísané v súbore SimpleMakerDoclet.java), je uvedený nižšie:
public static boolean start (root RootDoc) {ClassDoc [] classes = root.classes (); // Nastaviť CodeMakers tak, aby spúšťali Maker simplemaker = nový SimpleCodeMaker ("Description Maker"); // Iterácia vo všetkých triedach a vykonanie metódy „make“, ktorú tvorca vytvoril (int i = 0; i <classes.length; i ++) {ClassDoc classdoc = classes [i]; simplemaker.make (classdoc); } návrat pravdivý; } Nasledujú časti kódu z jednoduchého generátora kódu, ktorý sa volá SimpleCodeMaker, ktorá vykonáva rovnakú úlohu ako SimpleDoclet predtým uvedené. Namiesto odosielania výstupu na obrazovku SimpleCodeMaker uloží do súboru v podadresári genclasses. Vykonávanie urobiť metóda sa tiež stáva štruktúrovanejšou so samostatnými metódami na spracovanie polí a metód. Iba metódy urobiť a processMethods sú tu uvedené pre stručnosť.
