Kādu dienu es klausījos Nacionālā sabiedriskā radio Auto saruna, populāra nedēļas pārraide, kuras laikā zvanītāji uzdod jautājumus par saviem transportlīdzekļiem. Pirms katras programmas pārtraukuma raidījuma vadītāji aicina zvanītājus sastādīt numuru 1-800-CAR-TALK, kas atbilst numuram 1-800-227-8255. Protams, pirmais ir daudz vieglāk iegaumējams nekā otrs, daļēji tāpēc, ka vārdi "AUTO RUNA" ir salikti: divi vārdi, kas apzīmē septiņus ciparus. Cilvēkiem parasti ir vieglāk tikt galā ar kompozītmateriāliem, nevis ar atsevišķiem komponentiem. Tāpat, izstrādājot objektorientētu programmatūru, bieži ir ērti manipulēt ar kompozītiem tāpat kā ar atsevišķiem komponentiem. Šis priekšnoteikums ir kompozītmateriālu dizaina modeļa pamatprincips, šī tēma Java dizaina modeļi iemaksa.
Saliktais modelis
Pirms mēs ienirstam saliktajā modelī, man vispirms ir jādefinē saliktie objekti: objekti, kas satur citus objektus; piemēram, zīmējums var sastāvēt no grafiskiem primitīviem, piemēram, līnijām, apļiem, taisnstūriem, teksta utt.
Java izstrādātājiem ir nepieciešams saliktais modelis, jo mums bieži ir jārīkojas ar kompozītiem tieši tāpat kā ar primitīviem objektiem. Piemēram, grafiskie primitīvi, piemēram, līnijas vai teksts, ir jāvelk, jāpārvieto un jāmaina izmērs. Bet mēs arī vēlamies veikt to pašu darbību ar kompozītiem, piemēram, zīmējumiem, kas sastāv no šiem primitīviem. Ideālā gadījumā mēs vēlētos veikt darbības ar primitīviem objektiem un kompozītiem tieši tādā pašā veidā, neatšķirot abus. Ja mums ir jānošķir primitīvi objekti un kompozīti, lai veiktu vienas un tās pašas darbības ar šiem diviem objektu veidiem, mūsu kods kļūtu sarežģītāks un grūtāk īstenojams, uzturams un paplašināms.
In Dizaina modeļi, autori raksturo salikto modeli šādi:
Komponējiet objektus koku struktūrās, lai attēlotu visu daļu hierarhijas. Kompozīts ļauj klientiem vienveidīgi izturēties pret atsevišķiem objektiem un objektu kompozīcijām.Composite modeļa ieviešana ir vienkārša. Saliktās klases paplašina pamatklasi, kas attēlo primitīvus objektus. 1. attēlā parādīta klases diagramma, kas ilustrē kombinētā modeļa struktūru.
1. attēla klases diagrammā es izmantoju klašu nosaukumus no Dizaina paraugs 's Kompozitā modeļa diskusija: Komponents ir primitīvu objektu bāzes klase (vai, iespējams, saskarne), un Kompozīts pārstāv saliktu klasi. Piemēram, Komponents klase var būt grafisko primitīvu bāzes klase, turpretim Kompozīts klase varētu pārstāvēt a Zīmēšana klasē. 1. attēls Lapu klase apzīmē konkrētu primitīvu objektu; piemēram, a Līnija klase vai a Teksts klasē. The Operation1 () un Operation2 () metodes apzīmē domēna specifiskas metodes, kuras īsteno gan Komponents un Kompozīts klases.
The Kompozīts klase uztur komponentu kolekciju. Parasti Kompozīts metodes tiek ieviestas, atkārtojot šo kolekciju un katram piemērojot piemērotu metodi Komponents kolekcijā. Piemēram, a Zīmēšana klase varētu to īstenot izdarīt () šāda metode:
// Šī metode ir salikta metode public void draw () {// Atkārtot komponentus (int i = 0; i <getComponentCount (); ++ i) {// Iegūt atsauci uz komponentu un izsaukt tā izlozi metode Komponenta komponents = getComponent (i); komponents.zīmēt (); }} Par katru sistēmā ieviesto metodi Komponents klase, Kompozīts klase ievieš metodi ar tādu pašu parakstu, kas atkārto kompozīta komponentus, kā parādīts izdarīt () metodi, kas uzskaitīta iepriekš.
The Kompozīts klase paplašina Komponents klase, lai jūs varētu nodot saliktu metodi, kas sagaida komponentu; piemēram, apsveriet šādu metodi:
// Šī metode tiek ieviesta klasē, kas nav saistīta ar // Component un Composite klasēm public void repaint (Component component) {// Komponents var būt salikts, taču, tā kā tas paplašina // Component klasi, šai metodei nav jābūt // atšķirt komponentus no kompozītiem component.draw (); } Iepriekšējai metodei tiek nodots komponents - vai nu vienkāršs komponents, vai kompozīts -, tad tā izsauc šī komponenta komponentus izdarīt () metodi. Tāpēc ka Kompozīts klase pagarinās Komponents, pārkrāsot () metodei nav jānošķir komponenti no kompozītiem - tā vienkārši izsauc izdarīt () metode komponentam (vai saliktajam).
1. attēlā ir salikto modeļu klases diagramma, kas ilustrē vienu modeļa problēmu: jums jānošķir komponenti un kompozīti, atsaucoties uz Komponents, un jums ir jāizmanto īpaša salikta metode, piemēram, addComponent (). Parasti jūs izpildāt šo prasību, pievienojot metodi, piemēram, isComposite (), uz Komponents klasē. Šī metode atgriežas nepatiesa komponentiem un tiek ignorēts Kompozīts klasei, lai atgrieztos taisnība. Turklāt jums ir jāraida arī Komponents atsauce uz a Kompozīts piemēram, šādi:
... if (component.isComposite ()) {Composite composite = (kompozīts) komponents; composite.addComponent (someComponentThatCouldBeAComposite); } ... Ievērojiet, ka addComponent () metode ir nodota a Komponents atsauce, kas var būt vai nu primitīvs komponents, vai salikts. Tā kā šī sastāvdaļa var būt salikta, jūs varat komponēt komponentus koka struktūrā, kā norādīts iepriekšminētajā citātā no Dizaina modeļi.
2. attēlā parādīta alternatīva kombinētā modeļa ieviešana.
Ja jūs ieviešat 2. attēla salikto modeli, jums nekad nav jānošķir komponenti un kompozīti, un jums nav jāizdod Komponents atsauce uz a Kompozīts instancē. Tātad iepriekš uzskaitītais koda fragments tiek samazināts līdz vienai rindai:
... component.addComponent (someComponentThatCouldBeAComposite); ...
Bet, ja Komponents atsauce iepriekšējā koda fragmentā neattiecas uz a Kompozīts, kam vajadzētu būt addComponent () darīt? Tas ir galvenais strīds ar 2. attēla salikto modeļu ieviešanu. Tā kā primitīvajos komponentos nav citu komponentu, komponenta pievienošanai citam komponentam nav jēgas, tāpēc Component.addComponent () metode var vai nu klusi neizdoties, vai arī radīt izņēmumu. Parasti komponenta pievienošana citam primitīvam komponentam tiek uzskatīta par kļūdu, tāpēc izņēmuma mešana ir varbūt labākā rīcība.
Tātad, kura kombinētā modeļa ieviešana - 1. attēlā vai 2. attēlā - darbojas vislabāk? Tas vienmēr ir lielu diskusiju temats starp salikto modeļu ieviesējiem; Dizaina modeļi dod priekšroku 2. attēla ieviešanai, jo jums nekad nav jānošķir komponenti un konteineri, un jums nekad nav jāveic cast. Personīgi es dodu priekšroku 1. attēla ieviešanai, jo man ir liela nepatika pret tādu metožu ieviešanu klasē, kurām nav jēgas šim objekta tipam.
Tagad, kad esat sapratis salikto modeli un kā to varat ieviest, pārbaudīsim salikta modeļa piemēru ar Apache Struts JavaServer Pages (JSP) sistēmu.
Saliktais modelis un statņu flīzes
Apache Struts ietvars ietver JSP tagu bibliotēku, kas pazīstama kā Flīzes, kas ļauj jums izveidot tīmekļa lapu no vairākiem JSP. Flīzes faktiski ir J2EE (Java 2 Platform, Enterprise Edition) CompositeView modeļa ieviešana, kas pati balstās uz Dizaina modeļi Saliktais raksts. Pirms mēs apspriedīsim kombinētā modeļa atbilstību flīžu tagu bibliotēkai, vispirms pārskatīsim flīžu pamatojumu un to, kā jūs to izmantojat. Ja jūs jau esat iepazinies ar statņu elementiem, varat izlaist šīs sadaļas un sākt lasīšanu sadaļā "Kompozītā modeļa izmantošana ar statņu flīzēm"
Piezīme: Jūs varat uzzināt vairāk par J2EE CompositeView modeli manā tīmekļa vietnē Componite View Easy Made Composite View (JavaWorld, 2001. gada decembris) raksts.
Dizaineri bieži izveido tīmekļa vietnes ar atsevišķu reģionu kopumu; piemēram, 3. attēla vietne satur sānjoslu, galveni, satura reģionu un kājeni.
Vietnēs bieži ir vairākas tīmekļa lapas ar identiskiem izkārtojumiem, piemēram, 3. attēla sānjoslas / galvenes / satura / kājenes izkārtojums. Struts Flīzes ļauj atkārtoti izmantot gan saturu, gan izkārtojumu vairākās vietnēs. Pirms mēs apspriedīsim šo atkārtotu izmantošanu, redzēsim, kā 3. attēla izkārtojums tradicionāli tiek ieviests tikai ar HTML.
Ievietojiet sarežģītus izkārtojumus ar rokām
1. piemērā parādīts, kā jūs varat ieviest 3. attēla tīmekļa lapu ar HTML:
1. piemērs. Sarežģīts izkārtojums, kas ieviests ar rokām
Sarežģītu izkārtojumu ieviešana ar roku <% - vienā tabulā ir parādīts viss šīs lapas saturs -%>
|
|
Iepriekšējam JSP ir divi galvenie trūkumi: Pirmkārt, lapas saturs ir iestrādāts JSP, tāpēc nevienu no tiem nevar atkārtoti izmantot, lai gan sānjosla, galvene un kājene, iespējams, daudzās vietnēs ir vienādas. Otrkārt, lapas izkārtojums ir iestrādāts arī šajā JSP, tāpēc arī jūs to nevarat atkārtoti izmantot, kaut arī daudzas citas tās pašas vietnes tīmekļa vietnes izmanto to pašu izkārtojumu. Mēs varam izmantot darbība, lai novērstu pirmo trūkumu, kā es apspriedīšu tālāk.
Īstenot sarežģītus izkārtojumus ar JSP ietver
2. piemērā parādīta 3. attēla tīmekļa vietnes ieviešana, kas izmanto :
