To objavo je nazadnje uredila Summer 27. 9. 2017 ob 15:32
Ta članek je kratka zgodba, ki posnema vprašanja in odgovore, avtor pa s humornim slogom na kratko analizira delo, ki ga opravljajo arhitekti: Želim postati programski arhitekt. To je odlična možnost za mlade razvijalce programske opreme. Želim voditi ekipo in sprejemati pomembne odločitve glede baz podatkov in ogrodij, spletnih strežnikov itd. Oh, potem sploh nočeš biti programski arhitekt. Seveda sem želel sprejemati pomembne odločitve. To je v redu, vendar na seznam ne vključite pomembnih odločitev, ki so nepomembne. Kako to misliš? Ali pravite, da baze podatkov niso pomembne odločitve, ali veste, koliko zanje porabimo? Morda je predraga. Vendar podatkovne baze niso ena izmed pomembnih odločitev. Kako lahko to rečeš? Baza podatkov je jedro sistema, kjer so vsi podatki sistematizirani, razvrščeni, indeksirani in dostopani. Brez baze podatkov ne bi bilo sistema. Baza podatkov je zgolj vhodna naprava, ki ponuja nekaj uporabnih orodij za klasifikacijo, poizvedovanje in poročanje o informacijah, vendar so to le pomožne funkcije sistemske arhitekture. Pomoč? To je nesprejemljivo. Tako je, je pomožna. Poslovna pravila sistema morda lahko izkoristijo nekatera od teh orodij, vendar ta orodja niso lastna ustreznim poslovnim pravilom. Če je potrebno, lahko obstoječe zamenjate z drugimi orodji; In poslovna pravila se ne bodo spremenila. No, ja, vendar je bilo treba to ponovno kodirati, ker so bila ta orodja uporabljena v izvirni bazi podatkov. To je tvoj problem. Kako to misliš? Vaš problem je, da menite, da poslovna pravila temeljijo na orodjih za baze podatkov, pa niso. Ali pa vsaj ne bi smelo biti tako, dokler ni zagotovljena dobra arhitektura. To je preprosto noro. Kako ustvarite poslovna pravila, ki teh orodij ne uporabljajo? Ne pravim, da ne uporabljajo orodij za podatkovne baze, vendar od njih niso odvisni. Poslovna pravila ne potrebujejo vedeti, katero bazo podatkov uporabljate. Kako torej priti do poslovnih pravil, ne da bi vedeli, katera orodja uporabiti? Obrnite odvisnosti tako, da baza podatkov temelji na poslovnih pravilih. Poskrbite, da poslovna pravila niso odvisna od baze podatkov. Govoriš neumnosti. Nasprotno, uporabljam jezik programske arhitekture. To je načelo inverzije odvisnosti: nizkonivojski standardi naj temeljijo na visokih standardih. Neumnost! Merila na visoki ravni (ob predpostavki, da se nanašajo na poslovna pravila) Klicanje nizkonivojskih kriterijev (predpostavimo, da se nanašajo na podatkovne baze). Zato se bo merilo visoke ravni opiralo na nizkonivojski kriterij po načelu, da klicatelj temelji na prejemniku. Vsi to vedo! To velja med izvajanjem. Pri prevajanju pa želimo inverzijo odvisnosti. Izvorna koda visokonivojskih smernic ne sme omenjati izvorne kode nizkonivojskih smernic. Ah, daj, daj! Kako lahko pokličeš, ne da bi to omenil? Seveda ni problema. To je bistvo objektno usmerjenega pristopa. Objektna usmerjenost pomeni ustvarjanje modelov v realnem svetu, ki združuje podatke, funkcionalnost in povezane objekte. Gre za organizacijo kode v intuitivno strukturo. Tako pravijo? Kot vsi vemo, je to očitna resnica. Da, vendar je pri uporabi objektno usmerjenih smernic res mogoče uporabiti brez omembe. No, kako to narediti? Pri objektno usmerjenem oblikovanju si objekti med seboj pošiljajo sporočila. Tako je, seveda. Ko pošiljatelj pošlje sporočilo, ne pozna vrste prejemnika. Odvisno je od uporabljenega jezika. V Javi pošiljatelj pozna vsaj osnovni tip prejemnika. V Rubyju pošiljatelj vsaj ve, da je prejemnik sposoben obravnavati prejeta sporočila. Tako je. V vsakem primeru pa pošiljatelj ne pozna natančne vrste prejemnika. Tako je, no, res je. Zato lahko pošiljatelj oblikuje sprejemnika tako, da opravlja funkcijo, ne da bi omenil specifično vrsto prejemnika. Tako je, tako je. Razumem. Vendar je pošiljatelj še vedno odvisen od prejemnika. To velja med izvajanjem. Vendar pa je drugače, ko je preveden. Izvorna koda pošiljatelja ne omenja in ni odvisna od izvorne kode prejemnika. Pravzaprav je izvorna koda prejemnika odvisna od izvorne kode pošiljatelja. Nikakor! Pošiljatelj je še vedno odvisen od razreda, ki ga pošlje. Morda bo iz izvorne kode bolj jasno. Naslednji odstavek je napisan v Javi. Najprej pošiljatelj: pošiljatelj paketov; javni razred Pošiljatelj { zasebni prejemnik; javni Pošiljatelj (Prejemnik r) { prejemnik = r; } public void doSomething () { receiver.receiveThis (); } javni vmesnik Receiver { void receiveThis (); } }Tukaj je sprejemnik: paketni sprejemnik; Uvoz pošiljatelja. Pošiljatelj; javni razred SpecificReceiver implementira Sender.Receiver { public void receiveThis () { //naredi nekaj zanimivega. } }Opomba: Prejemnik je odvisen od pošiljatelja, SpecificReceiver od pošiljatelja, v pošiljatelju pa ni nobenih informacij, povezanih s prejemnikom. Ja, ampak lažeš, vključiš vmesnik prejemnika v razred pošiljatelja. Začenjaš razumeti. Kaj veš? Seveda je to načelo arhitekture. Pošiljatelj ima vmesnik, ki ga mora sprejemnik implementirati. Če to pomeni, da moram uporabljati gnezdene razrede, potem ...... Gnezdeni razredi so le ena od sredstev za dosego cilja, obstajajo tudi drugi načini. No, počakaj malo. Kaj ima to opraviti z bazami podatkov? Začeli smo govoriti o podatkovnih bazah. Poglejmo si kodo še malo podrobneje. Prvo je preprosto poslovno pravilo: paketno poslovanjePravila; uvoz entitet. Nekaj; javni razred BusinessRule { zasebni BusinessRuleGateway prehod; javni BusinessRule (prehod BusinessRuleGateway) { this.gateway = prehod; } public void execute (String id) { gateway.startTransaction (); Something thing = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (stvar); gateway.endTransaction (); } }Poslovna pravila nimajo velike teže. To je le en primer. Lahko bi bilo več takšnih razredov, ki izvajajo različna poslovna pravila. V redu, kaj pravzaprav je Gateway? Omogoča vse metode dostopa do podatkov preko poslovnih pravil. Implementirajte ga takole: paketno poslovanjePravila; uvoz entitet. Nekaj; javni vmesnik BusinessRuleGateway { Something getSomething (String ID); void startTransaction (); void saveSomething (Nekaj stvar); void endTransaction (); }Opomba: To je v businessRules. V redu, kaj je razred Nekaj? Predstavlja preprost poslovni predmet. Razdelil sem ga v entitete. paketne entitete; public class Something { public void makeChanges () { //... } }Končna implementacija BusinessRuleGateway, ta razred pozna pravo bazo podatkov: podatkovna baza paketov; uvoz businessRules.BusinessRuleGateway; uvoz entitet. Nekaj; public class MySqlBusinessRuleGateway implementira BusinessRuleGateway { public Something getSomething (String id) { // uporabi MySQL za pridobitev stvari. } public void startTransaction () { // start MySQL transakcije } public void saveSomething (Something thing) { // save thing in MySQL } public void endTransaction () { // end MySql transakcija } }Poleg tega upoštevajte, da poslovna pravila kličejo bazo podatkov med izvajanjem; Vendar pa ob prevajanju baza vključuje in je odvisna od poslovnih pravil. No, mislim, da razumem. Polimorfizem uporabljate le zato, da prikrijete dejstvo, da je podatkovna baza implementirana, iz poslovnih pravil. Kljub temu je še vedno potreben vmesnik, ki zagotavlja vsa orodja za podatkovne baze za poslovna pravila. Ne, sploh ne. Nismo poskušali zagotoviti orodij za podatkovne baze za poslovna pravila. Namesto tega uporabljajo poslovna pravila za ustvarjanje vmesnikov za svoje potrebe. Implementacija teh vmesnikov vam omogoča, da pokličete prava orodja. Da, ampak če moraš uporabljati vsa orodja za vsa poslovna pravila, potem preprosto postavi orodje v vmesnik prehoda. Ah, mislim, da še vedno ne razumeš. Razumeti kaj? To je že jasno. Vsako poslovno pravilo določa le en vmesnik za orodja za dostop do podatkov, ki jih potrebuje. Počakaj malo, kaj praviš? To je načelo ločevanja vmesnikov. Vsak razred poslovnih pravil uporablja le določene zmogljivosti baze podatkov. Zato lahko vmesniki, ki jih zagotavlja vsako poslovno pravilo, dostopajo le do ustreznih objektov. To pa pomeni, da obstaja veliko vmesnikov in veliko majhnih implementacijskih razredov, ki kličejo druge razrede baz podatkov. Super, začenjaš razumeti. Ampak je preveč neurejeno in izguba časa. Zakaj to storiti? To je organizirano in prihrani čas. Daj no, zberi veliko kode samo zaradi same kode. Nasprotno, nepomembne odločitve se lahko zamaknejo zaradi pomembnih arhitekturnih odločitev. Kaj to pomeni? Spomnim se, da si na začetku rekel, da želiš biti programski arhitekt, kajne? Želiš sprejemati vse odločitve, ki res štejejo. Ja, tako sem mislil. Želite sprejemati odločitve o podatkovnih bazah, spletnih strežnikih in ogrodjih, kajne? Da, praviš, da nič od tega ni pomembno. Samo nerelevantna vsebina. Tako je. To je to. Pomembne odločitve, ki jih sprejemajo programski arhitekti, so tiste, ki vam omogočajo odločanje o podatkovnih bazah, spletnih strežnikih in ogrodjih. Ampak najprej se moraš odločiti, katere boste! Ne, ne deluje. Pravzaprav se o teh odločitvah odloča kasneje v razvojnem ciklu, ko je informacij več. Katastrofa je, če arhitekti vnaprej identificirajo okvire, nato pa ugotovijo, da ne zagotavljajo zahtevane zmogljivosti ali pa uvedejo nevzdržne omejitve. Šele ko se arhitekt odloči odložiti odločitev, bo sprejel odločitev, ko bodo informacije zadostne; Ekipe, ki ne uporabljajo počasnih in virovsko zahtevnih naprav in ogrodij, lahko po presoji arhitektov ustvarjajo hitre in lahke testne okolja. Le njegovi arhitekti skrbijo za tisto, kar je res pomembno, in odlašajo s tistimi, ki niso, in takšna ekipa je tista srečna. Neumnost, sploh ne razumem, kaj misliš. No, dobro si oglejte ta članek, sicer boste morali počakati še 10 let, da to ugotovite.
| 
Objavljeno na 27. 09. 2017 15:29:46
|
|
|
Objavljeno na 28. 09. 2017 15:00:37
|
Najemodajalec|
Objavljeno na 29. 09. 2017 08:34:23
|
Objavljeno na 27. 11. 2018 11:12:17
|
