Seda postitust toimetas viimati Summer 2017-9-27 kell 15:32
See artikkel on lühijutt, mis jäljendab küsimuste ja vastuste seastet, ning autor kasutab humoorikat stiili, et lühidalt analüüsida arhitektide tööd: Ma tahan saada tarkvaraarhitektiks. See on suurepärane valik noortele tarkvaraarendajatele. Soovin juhtida meeskonda ja teha olulisi otsuseid andmebaaside ja raamistikude, veebiserverite jms osas. Ahjaa, siis sa ei taha üldse olla tarkvaraarhitekt. Loomulikult tahtsin olla tähtsate otsuste tegija. See on okei, aga sa ei lisa oma nimekirja olulisi otsuseid, mis on ebaolulised otsused. Mida sa selle all mõtled? Kas sa ütled, et andmebaasid ei ole olulised otsused, kas sa tead, kui palju me neile kulutame? Võib-olla maksab see liiga palju. Siiski ei ole andmebaasid üks olulisi otsuseid. Kuidas sa nii ütled? Andmebaas on süsteemi tuum, kus kõik andmed on süsteemne, klassifitseeritud, indekseeritud ja kättesaadavad. Ilma andmebaasita poleks süsteemi. Andmebaas on lihtsalt IO-seade, mis pakub kasulikke tööriistu klassifitseerimiseks, päringuteks ja info edastamiseks, kuid need on vaid süsteemi arhitektuuri abifunktsioonid. Abi? See on skandaalne. Jah, see on abivahend. Süsteemi ärireeglid võivad osa neist tööriistadest ära kasutada, kuid need tööriistad ei ole vastavate ärireeglite lahutamatu osa. Vajadusel saad olemasolevad asendada erinevate tööriistadega; Ja ärireeglid ei muutu. Jah, aga see tuli ümber kodeerida, sest neid tööriistu kasutati algses andmebaasis. See ongi sinu probleem. Mida sa selle all mõtled? Sinu probleem on see, et arvad, et ärireeglid sõltuvad andmebaasitööriistadest, aga tegelikult ei sõltu. Või vähemalt ei tohiks see nii olla enne, kui hea arhitektuur on tagatud. See on lihtsalt hullumeelne. Kuidas luua ärireegleid, mis neid tööriistu ei kasuta? Ma ei ütle, et nad ei kasuta andmebaasitööriistu, aga nad ei sõltu sellest. Ärireeglid ei pea teadma, millist andmebaasi sa kasutad. Kuidas siis saada ärireegleid, teadmata, milliseid tööriistu kasutada? Pööra sõltuvused nii, et andmebaas sõltub ärireeglitest. Veendu, et ärireeglid ei sõltuks andmebaasist. Sa räägid. Vastupidi, ma kasutan tarkvaraarhitektuuri keelt. See on sõltuvuse inversiooni põhimõte: madala taseme standardid peaksid tuginema kõrgetasemelistele standarditele. Jutt jutt! Kõrgetasemelised kriteeriumid (eeldades, et viitatakse ärireeglitele) Madala taseme kriteeriumide kutsumine (eeldades, et viidatakse andmebaasidele). Seetõttu tugineb kõrgetasemeline kriteerium madala taseme kriteeriumile, lähtudes põhimõttest, et helistaja sõltub helistajast. Kõik teavad seda! See kehtib jooksuajal. Aga kompileerimisel tahame sõltuvuse inversiooni. Kõrgetasemeliste juhiste lähtekood ei tohiks mainida madala taseme juhiste lähtekoodi. Ole nüüd! Kuidas sa saad teha kõne ilma seda mainimata? Muidugi pole probleemi. See ongi objektorienteeritud töö. Objektorientatsioon seisneb reaalse maailma mudelite loomises, andmete, funktsionaalsuse ja siduvate objektide ühendamises. See tähendab koodi organiseerimist intuitiivsesse struktuuri. Nii nad ütlevad? Nagu me kõik teame, on see ilmne tõde. Jah, see on, kuid objektorienteeritud juhiste kasutamisel on tõepoolest võimalik kutsuda neid ilma seda mainimata. Kuidas seda teha? Objektorienteeritud disainis saadavad objektid üksteisele sõnumeid. Jah, muidugi. Kui saatja saadab sõnumi, ei tea ta vastuvõtja tüüpi. See sõltub kasutatavast keelest. Java-s teab saatja vähemalt vastuvõtja baastüüpi. Ruby puhul teab saatja vähemalt, et vastuvõtja suudab vastu võetud sõnumeid käsitleda. Just nii. Igal juhul ei tea saatja täpset vastuvõtja tüüpi. Jah, on küll. Seetõttu saab saatja kujundada vastuvõtja funktsiooni täitma ilma konkreetset vastuvõtja tüüpi mainimata. Just nii, just nii. Ma mõistan. Siiski sõltub saatja endiselt vastuvõtjast. See kehtib jooksuajal. Kuid kompileerituna on see erinev. Saatja lähtekood ei maini ega sõltu vastuvõtja lähtekoodist. Tegelikult sõltub vastuvõtja lähtekood saatja lähtekoodist. Pole võimalik! Saatja sõltub endiselt klassist, mida ta saadab. Võib-olla mõnest lähtekoodist saab see selgemaks. Järgmine lõik on kirjutatud Java keeles. Esimesena on saatja: paki saatja; avaliku klassi saatja { privaatne vastuvõtja vastuvõtja; avalik saatja (vastuvõtja r) { vastuvõtja = r; } public void doSomething () { receiver.receiveThis (); } avalik liides Vastuvõtja { void receiveThis (); } }Siin on vastuvõtja: paketi vastuvõtja; Importija saatja. Saatja; public class SpecificReceiver implementeerib Sender.Receiver { public void receiveThis () { //tee midagi huvitavat. } }Märkus: Vastuvõtja sõltub saatjast, SpecificReceiver sõltub saatjast ja saatjas pole vastuvõtjaga seotud infot. Jah, aga sa valetad, sa panid vastuvõtja liidese saatja klassi. Sa hakkad aru saama. Mida sa tead? Loomulikult on see arhitektuuri põhimõte. Saatjal on liides, mida vastuvõtja peab rakendama. Kui see tähendab, et pean kasutama pesastatud klasse, siis ...... Pesastatud klassid on vaid üks viisidest eesmärgi saavutamiseks, on ka teisi viise. Oota nüüd. Mis pistmist sel on andmebaasidega? Hakkasime rääkima andmebaasidest. Vaatame koodi veidi lähemalt. Esimene on lihtne ärireegel: package businessRules; importüksused. Midagi; avalik klass BusinessRule { privaatne BusinessRuleGateway gateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Midagi asja = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (asi); gateway.endTransaction (); } }Ärireeglitel pole suurt kaalu. See on vaid üks näide. Võiks olla rohkem selliseid klasse, mis rakendavad palju erinevaid ärireegleid. Okei, mis täpselt on Gateway? See pakub kõiki andmepõhiseid ligipääsu meetodeid ärireeglite kaudu. Rakenda see järgmiselt: package businessRules; importüksused. Midagi; avalik liides BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (Midagi asi); void endTransaction (); }Märkus: See on kirjas businessRules. Okei, mis on Midagi klass? See esindab lihtsat äriobjekti. Panin selle entiteetidesse. paketiüksused; public class Midagi { public void makeChanges () { //... } }Lõppkokkuvõttes tunneb see klass BusinessRuleGateway teostust päris andmebaasi: pakettide andmebaas; importida businessRules.BusinessRuleGateway; importüksused. Midagi; public class MySqlBusinessRuleGateway rakendab BusinessRuleGateway { public Something getSomething (String id) { // kasuta MySql-i, et saada midagi. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySQL tehing } }Lisaks tuleb märkida, et ärireeglid kutsuvad andmebaasi käitusajal; Kuid kompileerimise ajal hõlmab andmebaas ja sõltub ärireeglitest. Noh, ma arvan, et saan aru. Sa kasutad lihtsalt polümorfismi, et varjata fakti, et andmebaas on rakendatud, ärireeglite eest. Siiski on vaja liidest, et pakkuda kõiki andmebaasi tööriistu ärireeglite järgimiseks. Ei, üldse mitte. Me ei ole püüdnud ärireeglitele andmebaasitööriistu pakkuda. Selle asemel kasutavad nad ärireegleid, et luua liideseid, mida nad vajavad. Nende liideste rakendamine võimaldab sul valida õiged tööriistad. Jah, aga kui pead kasutama kõiki tööriistu kõigi ärireeglite jaoks, siis pane tööriist lihtsalt gateway liidesesse. Ah, ma arvan, et sa ei saa ikka aru. Mida aru saada? See on juba selge. Iga ärireegel määratleb ainult ühe liidese vajalike andmejuurdepääsu tööriistade jaoks. Oota natuke, mis sa arvad? See on liidese segregatsiooni põhimõte. Iga ärireegliklass kasutab ainult teatud andmebaasi võimalusi. Seetõttu pääsevad iga ärireegli poolt pakutavad liidesed ligi ainult vastavatele rajatistele. See tähendab siiski, et on palju liideseid ja palju väikeseid rakendusklasse, mis kutsuvad teisi andmebaasiklasse. Suurepärane, sa hakkad aru saama. Aga see on liiga segane ja ajaraisk. Miks seda teha? See on organiseeritud ja säästab aega. Tule nüüd, võta palju koodi lihtsalt koodi pärast. Vastupidi, ebaolulisi otsuseid võivad edasi lükata oluliste arhitektuuriliste otsuste tõttu. Mida see tähendab? Mäletan, et alguses ütlesid, et tahad saada tarkvaraarhitektiks, eks? Sa tahad teha kõik need otsused, mis tõeliselt loevad. Jah, just nii ma arvasin. Sa tahad teha otsuseid andmebaaside, veebiserverite ja raamistikude kohta, eks? Jah, sa ütled, et see kõik ei loe. Lihtsalt ebaoluline sisu. Just nii. See ongi kõik. Olulised otsused, mida tarkvaraarhitektid teevad, on need, mis võimaldavad teil teha otsuseid andmebaaside, veebiserverite ja raamistikude kohta. Aga sa pead kõigepealt otsustama, millised! Ei, see ei tööta. Tegelikult saab neid otsustada hiljem arendustsüklis, kui infot on rohkem. On katastroof, kui arhitektid tuvastavad raamistikud ette, kuid avastavad, et need ei paku vajalikku jõudlust või kehtestavad talumatuid piiranguid. Alles siis, kui arhitekt otsustab otsuse edasi lükata, teeb ta otsuse, kui teavet on piisav; Meeskonnad, kes ei kasuta aeglaseid ja ressursimahukaid IO seadmeid ja raamistikke, saavad arhitektide äranägemisel luua kiireid ja kergeid testkeskkondi. Ainult selle arhitektid hoolivad sellest, mis tõeliselt loeb, ja lükkavad edasi neid, kes ei ole, ning selline meeskond on õnnelik. Jutt on, ma ei saa üldse aru, mida sa mõtled. Vaata seda artiklit hoolikalt, muidu pead ootama veel 10 aastat, et sellest aru saada.
| 
Postitatud 27.09.2017 15:29:46
|
|
|
Postitatud 28.09.2017 15:00:37
|
Üürileandja|
Postitatud 29.09.2017 08:34:23
|
Postitatud 27.11.2018 11:12:17
|
