Na´vrhovy´ vzor Factory v JAVA API Martin Kot Katedra informatiky VSˇB - Technicka´ univerzita Ostrava
[email protected]
Abstrakt V trˇ´ıda´ch API jazyka JAVA je pouzˇito mnoho na´vrhovy´ch vzoru˚. Najdeme zde i tvorˇ´ıcı´ vzory Factory a Factory Method. V tomto textu je uvedeno neˇkolik konkre´tnı´ch prˇ´ıpadu˚. Aby o nich cˇtena´rˇ zı´skal lepsˇ´ı prˇedstavu, je ke kazˇde´mu prˇ´ıkladu vyobrazen diagram trˇ´ıd a strucˇny´ popis vysveˇtlujı´cı´, k cˇemu tova´rna v dane´ implementaci slouzˇ´ı. Nejveˇtsˇ´ı prostor je veˇnova´n trˇ´ıdeˇ java.awt.Toolkit a objektu˚m, ktere´ generuje.
1 1.1
´ vod U Na´vrhove´ vzory
Objektova´ orientace se v programova´nı´ prosazuje jizˇ rˇadu let. Za tu dobu se zjistilo, zˇe se cˇasto stejne´ proble´my opakujı´ pouze v maly´ch obmeˇna´ch. Na rˇadu z nich se nasˇla vhodna´ rˇesˇenı´. Tato rˇesˇenı´ nazy´va´me na´vrhove´ vzory. Kazˇdy´ na´vrhovy´ vzor tvorˇ´ı mnozˇina objektu˚ a trˇ´ıd, ktere´ jsou propojeny vazbami. Kdyzˇ se prˇi na´vrhu konkre´tnı´ho syste´mu objevı´ proble´m, ktery´ by mohl neˇjaky´ na´vrhovy´ vzor vyrˇesˇit, nahradı´me trˇ´ıdy na´vrhove´ho vzoru trˇ´ıdami z nasˇeho syste´mu. Prˇitom potrˇebujeme, aby navza´jem zameˇneˇne´ trˇ´ıdy meˇly v rˇesˇene´ situaci stejne´ chova´nı´. Protozˇe uzˇitı´m na´vrhove´ho vzoru rˇesˇ´ıme jen jeden proble´m, mohou se v teˇchto trˇ´ıda´ch vyskytovat i dalsˇ´ı metody, rˇesˇ´ıcı´ jine´ proble´my. Vsˇechny metody vyzˇadovane´ na´vrhovy´m vzorem musı´ by´t k dispozici, aby vy´sledny´ objektovy´ na´vrh mohl plnit svou funkci. Obdobneˇ musı´ zu˚stat zachova´ny vazby pozˇadovane´ na´vrhovy´m vzorem, ale mu˚zˇeme prˇidat dalsˇ´ı pro jine´ potrˇeby. Na´vrhove´ vzory deˇlı´me podle u´cˇelu do trˇ´ı skupin: Tvorˇ´ıcı´ vzory (Creational patterns) - Prˇenecha´vajı´ tvorbu neˇktery´ch objektu˚ podtrˇ´ıda´m nebo jiny´m objektu˚. Prˇ´ıklady jsou (ponecha´va´m uzˇ´ıvane´ anglicke´ na´zvy, i kdyzˇ se obcˇas objevujı´ pokusy o prˇeklad): - Factory (neˇkdy take´ Abstract Factory) - Poskytuje rozhranı´ pro tvorˇenı´ rodin prˇ´ıbuzny´ch objektu˚ bez specifikace konkre´tnı´ch trˇ´ıd. 1
- Factory Method - Definuje rozhranı´ pro tvorbu objektu˚, ale necha´ podtrˇ´ıdu rozhodnout, kterou trˇ´ıdu konkre´tneˇ instanciovat. - Prototype - Specifikuje druhy objektu˚, ktere´ tvorˇ´ı kopı´rova´nı´m prototypu. Struktura´lnı´ vzory (Structural patterns) - Popisujı´ obecne´ struktury objektu˚ a trˇ´ıd. Prˇ´ıklady jsou: - Composite - Skla´da´ objekty do stromove´ struktury. Klient mu˚zˇe zacha´zet s jednotlivy´mi prvky stejneˇ jako se slozˇeninou z vı´ce prvku˚. - Adapter - Prˇeva´dı´ rozhranı´ trˇ´ıdy na takove´, jake´ potrˇebuje klient. - Decorator - Prˇipojuje k objektu dynamicky dalsˇ´ı funkcˇnost. - Proxy - Poskytuje pro neˇjaky´ objekt za´stupce, ktery´ rˇ´ıdı´ prˇ´ıstup k tomuto objektu. Vzory chova´nı´ (Behavioral patterns) - Popisujı´ algoritmy nebo spolupra´ci objektu˚. Prˇ´ıklady jsou: - Chain of Responsibility - Snazˇ´ı se zabra´nit, aby zˇa´dost uzˇivatele mohlo zpracovat vı´ce objektu˚. Objekty se zrˇeteˇzı´ a zpra´va postupneˇ putuje po rˇeteˇzci, dokud ji neˇktery´ objekt nezpracuje. - Observer - Definuje za´vislost n objektu˚ na jednom jine´m. Pokud tento jeden objekt zmeˇnı´ stav, jsou o zmeˇneˇ informova´ny vsˇechny za´visle´ objekty. - Iterator - Umozˇnˇuje sekvencˇnı´ prˇ´ıstup k prvku˚m agregovane´ho objektu, anizˇ by klient musel zna´t vnitrˇnı´ strukturu agregace. - State - Umozˇnˇuje objektu meˇnit chova´nı´ na za´kladeˇ vnitrˇnı´ho stavu. - Strategy - Umozˇnˇuje zmeˇnu algoritmu neza´visle na klientovi, ktery´ algoritmus uzˇ´ıva´.
1.2
API jazyka JAVA
Aplikacˇnı´ programa´torske´ rozhranı´ (API - Application Program Interface) jazyka JAVA je soubor trˇ´ıd, ktere´ jsou k dispozici programa´toru˚m v tomto jazyce. V trˇ´ıda´ch API nalezneme implementaci neˇkolika na´vrhovy´ch vzoru˚. Naprˇ´ıklad graficke´ uzˇivatelske´ rozhranı´ (GUI - Graphic User Interface) umozˇnˇuje vnorˇova´nı´ komponent do sebe podle na´vrhove´ho vzoru Composite. V takto vnorˇeny´ch objektech GUI se uda´losti zpracova´vajı´ podle vzoru Chain of Responsibility. Prˇi implementaci na´vrhove´ho vzoru Observer stacˇ´ı sledovany´ objekt zdeˇdit z trˇ´ıdy Observer a pozorovatele´ musı´ implementovat rozhranı´ Observable. Samozrˇejmeˇ, zˇe pouzˇitı´ na´vrhovy´ch vzoru˚ v JAVeˇ nenı´ omezeno jen na ty, ktere´ jsou jizˇ prˇ´ımo v API. Kazˇdy´ uzˇivatel si mu˚zˇe vlastnı´ trˇ´ıdy navrhnout s vyuzˇitı´m neˇktere´ho vzoru. Tato pra´ce ma´ ale za cı´l zmapovat pouzˇitı´ na´vrhove´ho vzoru Factory v API jazyka JAVA a proto se mozˇnostmi uzˇitı´ na´vrhovy´ch vzoru˚ aplikacˇnı´mi programa´tory ve vlastnı´ch na´vrzı´ch zaby´vat nebude. V na´zvech API trˇ´ıd se slovo „factory“ vyskytuje pomeˇrneˇ cˇasto, ale jde spı´sˇe o implementace na´vrhove´ho vzoru Factory Method. Proto bude sekce textu oznacˇena´ 3 veˇnova´na tomuto vzoru. V sekci 2 bude popsa´n vzor Abstract Factory a jeho dveˇ implementace v API. 2
2 Abstract Factory 2.1 Abstraktnı´ popis Pro prˇedstavu, v cˇem je uzˇitı´ na´vrhove´ho vzoru vhodne´, si prˇedstavme na´sledujı´cı´ prˇ´ıklad. Meˇjme aplikaci, ktera´ pouzˇ´ıva´ komunikaci prˇes sı´t’. Mu˚zˇeme mı´t pozˇadavek na zabezpecˇenou komunikaci i nezabezpecˇenou. Aplikace se soucˇasneˇ mu˚zˇe chovat bud’ jako klient nebo jako server. Nezabezpecˇenou komunikaci prova´dı´ trˇ´ıdy UnsecureSocket na straneˇ klienta a UnsecureServerSocket na straneˇ serveru. Komunikaci zabezpecˇenou protokolem SSL obdobneˇ zajisˇt’ujı´ trˇ´ıdy SSLSocket a SSLServerSocket. Pokud bychom aplikaci psali bez pouzˇitı´ Factory, museli bychom prˇi prˇepsa´nı´ aplikace z nezabezpecˇene´ komunikace na zabezpecˇenou zmeˇnit v ko´du konstruktory pro tvorbeˇ socketu˚ na jine´ trˇ´ıdy. Pouzˇitı´m Abstract Factory si situaci mu˚zˇeme zjednodusˇit. SSLSocket a UnsecureSocket zdeˇdı´me ze spolecˇne´ trˇ´ıdy Socket nebo je necha´me implementovat interface Socket, abychom zajistili jejich jednotne´ rozhranı´. Pro SSLServerSocket a UnsecureServerSocket obdobneˇ vytvorˇ´ıme nadtrˇ´ıdu nebo interface ServerSocket. Prˇida´me trˇ´ıdu SocketFactory, ktera´ bude mı´t dveˇ metody: createSocket():Socket createServerSocket():ServerSocket Z nı´ zdeˇdı´me trˇ´ıdy SSLSocketFactory tvorˇ´ıcı´ v implementaci obou metod instance trˇ´ıd pro zabezpecˇene´ sockety a UnsecureSocketFactory tvorˇ´ıcı´ instance trˇ´ıd pro nezabezpecˇene´ sockety. Mı´sto prˇ´ıme´ho vola´nı´ konstruktoru˚ budeme sockety tvorˇit prostrˇednictvı´m SocketFactory. Prˇevod z nezabezpecˇene´ komunikace na zabezpecˇenou se provede jednodusˇe v ko´du na jednom mı´steˇ nahrazenı´m konstruktoru trˇ´ıdy UnsecureSocketFactory za SSLSocketFactory. Vy´hoda se mu˚zˇe projevit i v budoucnu. Azˇ se objevı´ novy´ protokol pro zabezpecˇenou komunikaci, vytvorˇ´ıme se novou podtrˇ´ıdu trˇ´ıdy SocketFactory a dveˇ trˇ´ıdy implementujı´cı´ sockety zabezpecˇene´ novy´m protokolem zdeˇdeˇne´ z nasˇich obecny´ch trˇ´ıd pro sockety. Nebudeme muset procha´zet cely´ rozsa´hly´ ko´d a meˇnit stare´ trˇ´ıdy za nove´. Pouze zase v jednom mı´steˇ nahradı´me starou podtrˇ´ıdu SocketFactory za novou. Cela´ situace je zna´zorneˇna na obra´zku 1. Podobny´ch situacı´ vhodny´ch pro pouzˇitı´ vzoru Abstract Factory je mnoho. Uvidı´me je i v API jazyka JAVA. Abstraktnı´ zobrazenı´ na´vrhove´ho vzoru je na obra´zku 2.
2.2 Toolkit Nejdu˚lezˇiteˇjsˇ´ım pouzˇitı´m na´vrhove´ho vzoru Factory v JAVeˇ je trˇ´ıda java.awt.Toolkit. Programa´tor s jejı´m vyuzˇitı´m mu˚zˇe psa´t programy vybavene´ graficky´m uzˇivatelsky´m rozhranı´m (GUI) prˇenositelne´ mezi platformami. Na kazˇde´ platformeˇ potom GUI mu˚zˇe mı´t odlisˇny´ vzhled a prˇ´ıpadneˇ i chova´nı´, ale z hlediska spolupra´ce s dalsˇ´ımi objekty ma´ GUI porˇa´d stejne´ rozhranı´. java.awt.Toolkit ma´ celou rˇadu metod tvorˇ´ıcı´ch ru˚zne´ druhy objektu˚. Na obra´zku 3 je zobrazen diagram trˇ´ıd zna´zornˇujı´cı´ tvorbu dvou produktu˚ - java.awt.peer.ButtonPeer 3
Obra´zek 1: Diagram trˇ´ıd motivacˇnı´ho prˇ´ıkladu uzˇitı´ Abstract Factory
Obra´zek 2: Diagram trˇ´ıd abstrakce na´vrhove´ho vzoru Abstract Factory
4
a java.awt.peer.LabelPeer. Konkre´tnı´ tova´rna sun.awt.windows.WToolkit je implementacı´ firmy Sun pro platformu Windows a sun.awt.motif.MToolkit pro XWindows v unixovy´ch syste´mech.
Obra´zek 3: Diagram trˇ´ıd zobrazujı´cı´ propojenı´ Toolkit se dveˇma druhy produktu˚ Kazˇdou tvorˇ´ıcı´ metodu z java.awt.Toolkit pouzˇ´ıva´ objekt jine´ trˇ´ıdy, protozˇe si tı´m tvorˇ´ı vlastnı´ vzhled. Na obra´zku 3 je java.awt.peer.ButtonPeer vytvorˇen a uzˇ´ıva´n objektem trˇ´ıdy java.awt.Button a obdobneˇ java.awt.peer.LabelPeer objektem trˇ´ıdy java.awt.Label. V tabulce 1 je seznam vsˇech tvorˇ´ıcı´ch metod trˇ´ıdy java.awt.Toolkit a trˇ´ıd, ktere´ vyuzˇ´ıvajı´ vola´nı´ teˇchto metod k vytvorˇenı´ sve´ho vzhledu. V diagramu trˇ´ıd na obra´zku 3 byly jen dva abstraktnı´ produkty a jim prˇ´ıslusˇne´ konkre´tnı´ produkty. Obra´zky 4, 5 a 6 zobrazujı´ celou hierarchii abstraktnı´ch produktu˚ a konkre´tnı´ch produktu˚ pro platformu Windows. Abstraktnı´mi produkty zde jsou vsˇechny interface z balı´ku java.awt.peer, ktere´ jsou na´vratovou hodnotou neˇktere´ metody v tabulce 1. Konkre´tnı´ produkty prˇedstavujı´ vsˇechny objekty implementujı´cı´ tato rozhranı´. Na zmı´neˇny´ch obra´zcı´ch to jsou ty, jejichzˇ na´zvy zacˇ´ınajı´cı´ ’W’ a nacha´zejı´ se v balı´ku sun.awt.windows. Pra´veˇ ony jsou tova´rnou sun.awt.windows.WToolkit ve skutecˇnosti tvorˇeny. Trˇ´ıdy v balı´ku sun.awt.motif majı´ hierarchii te´meˇrˇ stejnou jen s maly´mi odlisˇnostmi (naprˇ. MFileDialogPeer deˇdı´ z MDialogPeer). Take´ ony implementujı´ rozhranı´ z balı´ku 5
Metoda createButton():java.awt.peer.ButtonPeer createCanvas():java.awt.peer.CanvasPeer createCheckbox():java.awt.peer.CheckboxPeer createCheckboxMenuItem(): java.awt.peer.CheckboxMenuItemPeer createChoice():java.awt.peer.ChoicePeer createComponent():java.awt.peer.LightweightPeer createDialog():java.awt.peer.DialogPeer createFileDialog():java.awt.peer.FileDialogPeer createFrame():java.awt.peer.FramePeer createLabel():java.awt.peer.LabelPeer createList():java.awt.peer.ListPeer createMenu():java.awt.peer.MenuPeer createMenuBar():java.awt.peer.MenuBarPeer createPanel():java.awt.peer.PanelPeer createPopupMenu():java.awt.peer.PopupMenuPeer createScrollbar():java.awt.peer.ScrollbarPeer createScrollPane():java.awt.peer.ScrollPanePeer createTextArea():java.awt.peer.TextAreaPeer createTextField():java.awt.peer.TextFieldPeer createWindow():java.awt.peer.WindowPeer
Klient java.awt.Button java.awt.Canvas java.awt.Checkbox java.awt.CheckboxMenuItem java.awt.Choice java.awt.Component java.awt.Dialog java.awt.FileDialog java.awt.Frame java.awt.Label java.awt.List java.awt.Menu java.awt.MenuBar java.awt.Panel java.awt.PopupMenu java.awt.Scrollbar java.awt.ScrollPane java.awt.TextArea java.awt.TextField java.awt.Window
Tabulka 1: Tabulka tvorˇ´ıcı´ch metod trˇ´ıdy Toolkit a trˇ´ıd vyuzˇ´ıvajı´cı´ch tyto metody
6
java.awt.peer a prˇedstavujı´ konkre´tnı´ produkty. Jine´ firmy mohou vytvorˇit dalsˇ´ı konkre´tnı´ tova´rnu i produkty pro dalsˇ´ı platformy i alternativnı´ pro stejne´ platformy. Beˇzˇny´ programa´tor v jazyce JAVA vsˇak tvorˇ´ıcı´ metody trˇ´ıdy Toolkit prˇ´ımo nikdy volat nebude. Na rozdı´l od beˇzˇny´ch trˇ´ıd JAVA API, zdrojove´ ko´dy balı´ku sun.awt.windows nejsou soucˇa´stı´ distribuce JDK a tı´m ani API dokumentace. Jsou v distribuci obsazˇeny jen jako bina´rnı´ class soubory. Objekty graficke´ho rozhranı´, uvedene´ v tabulce 1 jako klienti, si vytva´rˇejı´ svu˚j objekt „peer“. Tento objekt se stara´ o vzhled a chova´nı´ objektu graficke´ho rozhranı´ po celou dobu jeho zˇivotnı´ho cyklu. Prˇ´ıkladem situace, kdy se „peer“ objekt vytvorˇ´ı, je prˇida´nı´ neˇjake´ komponenty (naprˇ. tlacˇ´ıtka) do kontejneru (naprˇ. okna). Diagram sekvencı´ zobrazujı´cı´ tuto situaci je na obra´zku 7. Je zde zanedba´no rusˇenı´ objektu˚, ktere´ nenı´ pro pochopenı´ funkce tova´rny podstatne´. Nalezenı´ konkre´tnı´ podtrˇ´ıdy trˇ´ıdy java.awt.Toolkit je zda vykona´no statickou metodou getProperty() trˇ´ıdy java.lang.System. V te´to trˇ´ıdeˇ jsou syste´move´ vlastnosti nastaveny nativnı´mi metodami. Metodeˇ getProperty() se da´ jako parametr na´zev vlastnosti („java.awt.Toolkit“) a na´vratovou hodnotou je rˇeteˇzec se jme´nem „toolkitu“ pro aktua´lnı´ syste´m, na ktere´m aplikace beˇzˇ´ı. Statickou metodou forName() trˇ´ıdy Class, ktere´ se jako parametr prˇeda´ zı´skany´ na´zev „toolkitu“, se vytvorˇ´ı novy´ objekt Class a z neˇj jizˇ je mozˇne´ vytvorˇit objekt nalezene´ podtrˇ´ıdy java.awt.Toolkit. Na konci sekvence je tak vytvorˇen syste´moveˇ za´visly´ „peer“ objekt syste´moveˇ neza´visly´mi metodami. Prvky rozhranı´ v teˇlech svy´ch metod prova´deˇjı´cı´ch syste´moveˇ za´visle´ operace (show() apod.) volajı´ prˇ´ıslusˇnou metodu sve´ho „peer“ objektu, ktery´ akci provede.
2.3 EditorKit Dalsˇ´ım prˇ´ıkladem uzˇitı´ Factory v Javeˇ je javax.swing.text.EditorKit. Roli klienta zde hraje javax.swing.JEditorPane. Objekty te´to trˇ´ıdy si prostrˇednictvı´m EditorKit vytva´rˇejı´ objekty Document a ViewFactory z balı´ku javax.swing.text. Situace je zna´zorneˇna diagramem trˇ´ıd na obra´zku 8. ViewFactory zde i prˇes sve´ jme´no hraje roli produktu. Jme´no te´to trˇ´ıdy souvisı´ s tı´m, zˇe jde o implementaci vzoru Factory Method pro tvorˇenı´ objektu˚ typu javax.swing.text.View pro neˇjakou komponentu. Pro ru˚zne´ typy dokumentu˚ se vytvorˇ´ı objekty ru˚zny´ch podtrˇ´ıd ViewFactory, aby potom generovaly jen vhodne´ objekty typu View. Objekty View jsou odpoveˇdne´ za zobrazenı´ dokumentu. Document slouzˇ´ı jako kontejner na text pro textove´ prvky rozhranı´ SWING. Standardneˇ poskytuje naprˇ. metody pro vracenı´ cele´ho nebo cˇa´sti textu, nahrazenı´ nebo vymaza´nı´ cˇa´sti textu atd. Konkre´tnı´ implementace mohou prˇidat prvky, jako naprˇ´ıklad deˇlenı´ na kapitoly, sekce apod. a dalsˇ´ı vlastnosti ru˚zny´ch forma´tu˚ dokumentu˚. Konkre´tnı´ produktova´ trˇ´ıda HTMLFactory je vnitrˇnı´ trˇ´ıdou HTMLEditorKit, obdobneˇ StyledViewFactory je vnitrˇnı´ trˇ´ıdou StyledEditorKit a PlainEditorKit je v JEditorPane. PlainEditorKit implementuje rozhranı´ ViewFactory a deˇdı´ z trˇ´ıdy DefaultEditorKit. To mu umozˇnˇuje se chovat jako tova´rna i produkt soucˇasneˇ. Pokud je na takovy´ objekt zavola´na metoda getViewFactory(), vracı´ sa´m sebe. Nevznika´ tak ani nova´ instance. 7
Obra´zek 4: Diagram trˇ´ıd - 1.cˇa´st hierarchie produktu˚ tvorˇeny´ch tova´rnou Toolkit 8
Obra´zek 5: Diagram trˇ´ıd - 2.cˇa´st hierarchie produktu˚ tvorˇeny´ch tova´rnou Toolkit
9
Obra´zek 6: Diagram trˇ´ıd - 3.cˇa´st hierarchie produktu˚ tvorˇeny´ch tova´rnou Toolkit
10
Obra´zek 7: Diagram sekvencı´ pro vlozˇenı´ tlacˇ´ıtka do okna
11
Obra´zek 8: Diagram trˇ´ıd pro EditorKit
12
3 Factory Method 3.1 Abstraktnı´ popis Na´vrhovy´ vzor Factory Method patrˇ´ı stejneˇ jako Abstract Factory do skupiny tvorˇ´ıcı´ch vzoru˚. Slouzˇ´ı k vytvorˇenı´ instance jedne´ z neˇkolika mozˇny´ch trˇ´ıd, cˇasto v za´vislosti na poskytnuty´ch datech. Obvykle vsˇechny trˇ´ıdy, ktere´ vracı´, majı´ shodnou nadtrˇ´ıdu a metody, ale kazˇda´ z nich prova´dı´ u´kol jiny´m zpu˚sobem a je optimalizova´na pro jiny´ typ dat. Rozhodnutı´ o tom, kterou trˇ´ıdu vra´tit necha´va´ tvorˇ´ıcı´ trˇ´ıda na sve´ podtrˇ´ıdeˇ a sama pracuje neza´visle na zvolene´ produktove´ trˇ´ıdeˇ. Na obra´zku 9 je abstraktnı´ zobrazenı´ tohoto vzoru.
Obra´zek 9: Diagram trˇ´ıd - abstrakce vzoru Factory Method Neˇkdy se za pouzˇitı´ vzoru Factory Method povazˇuje i situace, kdy o konkre´tnı´m produktu nerozhoduje podtrˇ´ıda, ale tvorˇ´ıcı´ metoda tvorˇ´ıcı´ trˇ´ıdy na za´kladeˇ dodany´ch dat. To je prˇ´ıpad neˇkolika trˇ´ıd v JAVA API obsahujı´cı´ch slovo „factory“. Rovneˇzˇ v neˇkolika prˇ´ıpadech je v API definova´no jen rozhranı´ tvorˇ´ıcı´ho objektu, ale nenı´ k dispozici zˇa´dna´ implementace.
3.2
PopupFactory
PopupFactory se nacha´zı´ v balı´ku javax.swing a, jak jme´no napovı´da´, je pouzˇ´ıva´na k zı´ska´va´nı´ instancı´ trˇ´ıdy Popup. Ty jsou uzˇ´ıva´ny k zobrazenı´ prvku (instance Component) nad vsˇemi ostatnı´mi prvky. Popup getPopup(Component owner, Component contents, int x, int y) rozhoduje o konkre´tnı´ podtrˇ´ıdeˇ trˇ´ıdy Popup na za´kladeˇ svy´ch parametru˚. Vsˇechny podtrˇ´ıdy jsou vnitrˇnı´mi trˇ´ıdami Popup. Situace je zobrazena diagramem trˇ´ıd na obra´zku 10.
3.3
KeyFactory
Trˇ´ıda KeyFactory se nacha´zı´ v balı´ku java.security. Slouzˇ´ı k prˇevodu specifikacı´ kryptograficky´ch klı´cˇu˚ (instance KeySpec) na objekty reprezentujı´cı´ klı´cˇe samotne´ (instance Key) a opacˇneˇ. Metody
13
Obra´zek 10: Diagram trˇ´ıd - PopupFactory PrivateKey generatePrivate(KeySpec keySpec) PublicKey generatePublic(KeySpec keySpec) tedy rozhodujı´ o konkre´tnı´ na´vratove´ trˇ´ıdeˇ klı´cˇe podle dodane´ specifikace v argumentu. Diagram trˇ´ıd zobrazujı´cı´ trˇ´ıdy generovane´ touto tova´rnou je na obra´zku 11. Trˇ´ıda KeyFactory prˇi tvorbeˇ klı´cˇu˚ vyuzˇ´ıva´ KeyFactorySpi. Tato trˇ´ıda je abstraktnı´ a ve zdrojovy´ch ko´dech obsazˇeny´ch v distribucı´ JDK a tı´m ani v API dokumentaci nenı´ zˇa´dna´ jejı´ podtrˇ´ıda. Take´ tam nenı´ zˇa´dna´ implementace rozhranı´ odvozeny´ch z PrivateKey a PublicKey. Mezi bina´rnı´mi trˇ´ıdami jsou vsˇak v balı´ku sun.security.provider implementace rozhranı´ DSAPublicKey a DSAPrivateKey pod stejny´m jme´nem. Take´ tam existuje podtrˇ´ıda KeyFactorySpi se jme´nem DSAKeyFactory. Pro ostatnı´ protokoly by musely prˇi pouzˇitı´ by´t podobne´ trˇ´ıdy vytvorˇeny.
3.4
SocketImplFactory
Trˇ´ıda Socket reprezentuje klientsky´ konec sı´t’ove´ho spojenı´. Skutecˇnou pra´ci ale prova´deˇjı´ objekty trˇ´ıd implementujı´cı´ch SocketImpl. Socket si takovy´ objekt vytvorˇ´ı pomocı´ metody SocketImpl createSocketImpl() tova´rny SocketImplFactory. Diagram trˇ´ıd pro tuto aplikaci Factory Method je na obra´zku 12.
3.5
DocumentBuilderFactory
Trˇ´ıda DocumentBuilderFactory definuje tova´rnu, ktera´ umozˇnˇuje aplikacı´m zı´skat parser. Ten potom vytva´rˇ´ı stromy DOM objektu˚ z XML dokumentu˚. Jak je videˇt na diagramu trˇ´ıd na obra´zku 13, k dispozici je jedna neabstraktnı´ implementace tvorˇ´ıcı´ho objektu i produktu. Obeˇ se nacha´zejı´ v balı´ku org.apache.crimson.jaxp.
14
Obra´zek 11: Diagram trˇ´ıd - KeyFactory
Obra´zek 12: Diagram trˇ´ıd - SocketImplFactory 15
Obra´zek 13: Diagram trˇ´ıd - DocumentBuilderFactory
4
Za´veˇr
V tomto textu je uvedeno jen neˇkolik prˇ´ıkladu˚ pouzˇitı´ na´vrhovy´ch vzoru˚ Factory nebo Factory Method v API jazyka JAVA. Ostatnı´ aplikace tohoto vzoru jsou obdobne´. Cˇasto tova´rnı´ trˇ´ıdu vyuzˇ´ıvajı´ jine´ trˇ´ıdy z API a aplikacˇnı´ programa´tor tvorˇ´ıcı´ metody prˇ´ımo neuzˇije. Velky´ vy´znam ma´ hlavneˇ Toolkit, ktery´ take´ pracuje skryteˇ prˇed programa´tory a zajisˇt’uje mozˇnost psa´t platformoveˇ neza´visle´ aplikace s graficky´m uzˇivatelsky´m rozhranı´m.
16