Tento príspevok naposledy upravila Summer 27.9.2017 o 15:32
Tento článok je krátky príbeh, ktorý napodobňuje otázky a odpovede, a autor používa humorný štýl na stručnú analýzu práce architektov: Chcem byť softvérovým architektom. Toto je skvelá možnosť pre mladých softvérových vývojárov. Chcem viesť tím a robiť dôležité rozhodnutia o databázach a frameworkoch, webových serveroch a podobne. Aha, takže vôbec nechceš byť softvérovým architektom. Samozrejme, chcel som byť tým, kto robí dôležité rozhodnutia. To je v poriadku, ale do zoznamu neuvádzate dôležité rozhodnutia, ktoré sú irelevantné. Čo tým myslíš? Hovoríte, že databázy nie sú dôležité rozhodnutia, viete, koľko na ne míňame? Možno to stojí príliš veľa. Databázy však nie sú jedným z dôležitých rozhodnutí. Ako to môžeš povedať? Databáza je jadrom systému, kde sú všetky údaje systematizované, klasifikované, indexované a prístupné. Bez databázy by systém neexistoval. Databáza je len IO zariadenie, ktoré poskytuje užitočné nástroje na klasifikáciu, dotazovanie a reportovanie informácií, ale to sú len pomocné funkcie systémovej architektúry. Pomoc? To je poburujúce. Presne tak, je to pomocné. Obchodné pravidlá systému môžu niektoré z týchto nástrojov využívať, ale tieto nástroje nie sú inherentnou súčasťou príslušných obchodných pravidiel. Ak je to potrebné, môžete existujúce nahradiť inými nástrojmi; A obchodné pravidlá sa nezmenia. Áno, ale muselo to byť preprogramované, pretože tieto nástroje sa používali v pôvodnej databáze. To je tvoj problém. Čo tým myslíš? Váš problém je, že si myslíte, že obchodné pravidlá závisia od databázových nástrojov, ale nie sú. Alebo aspoň by to tak nemalo byť, kým nie je zabezpečená dobrá architektúra. Je to proste šialené. Ako vytvárate obchodné pravidlá, ktoré tieto nástroje nevyužívajú? Nehovorím, že nepoužívajú databázové nástroje, ale nezávisia od nich. Obchodné pravidlá nemusia vedieť, ktorú databázu používate. Ako teda získať obchodné pravidlá bez toho, aby ste vedeli, aké nástroje použiť? Invertujte závislosti tak, aby databáza závisela od obchodných pravidiel. Uistite sa, že obchodné pravidlá nezávisia od databázy. Hovoríš nezmysly. Naopak, používam jazyk softvérovej architektúry. Toto je princíp inverzie závislosti: nízkoúrovňové štandardy by sa mali spoliehať na vysoké štandardy. Nesmysel! Vysokoúrovňové kritériá (za predpokladu obchodných pravidiel) Volanie nízkoúrovňových kritérií (predpokladajúc, že odkazujú na databázy). Preto sa kritérium vysokej úrovne opiera o kritérium nízkej úrovne podľa princípu, že volajúci závisí od volaného. Všetci to vedia! To platí počas behu. Ale pri kompilácii chceme inverziu závislosti. Zdrojový kód vysokoúrovňových usmernení by nemal spomínať zdrojový kód nízkoúrovňových usmernení. Poďme! Ako môžeš zavolať bez toho, aby si to spomenul? Samozrejme, žiadny problém. To je to, čo objektovo orientované znamená. Objektová orientácia sa týka tvorby reálnych modelov, kombinovania dát, funkčnosti a súdržných objektov. Ide o organizovanie kódu do intuitívnej štruktúry. To sa hovorí? Ako všetci vieme, toto je zrejmá pravda. Áno, je to tak, avšak pri použití objektovo orientovaných usmernení je skutočne možné vyvolať bez toho, aby ste to spomenuli. No, ako to urobiť? V objektovo orientovanom dizajne si objekty navzájom posielajú správy. Presne tak, samozrejme. Keď odosielateľ pošle správu, nepozná typ príjemcu. Závisí to od použitého jazyka. V Jave odosielateľ pozná aspoň základný typ prijímača. V Ruby odosielateľ aspoň vie, že prijímateľ je schopný spracovať prijaté správy. Presne tak. V každom prípade však odosielateľ nepozná konkrétny typ príjemcu. Presne tak, je to tak. Preto môže odosielateľ navrhnúť prijímača tak, aby vykonával určitú funkciu bez toho, aby spomenul konkrétny typ prijímača. Presne tak, presne tak. Rozumiem. Odosielateľ však stále závisí od prijímateľa. To platí počas behu. Avšak pri kompilácii je to iné. Zdrojový kód odosielateľa nespomína ani nezávisí od zdrojového kódu prijímateľa. V skutočnosti zdrojový kód prijímateľa závisí od zdrojového kódu odosielateľa. V žiadnom prípade! Odosielateľ stále závisí od triedy, ktorú pošle. Možno z nejakého zdrojového kódu to bude jasnejšie. Nasledujúci odsek je napísaný v Jave. Najprv je tu odosielateľ: odosielateľ balíkov; public class Sender { private Receiver receiver; verejný Odosielateľ (Príjemca r) { prijímač = r; } public void doNiečo () { receiver.receiveThis (); } verejné rozhranie Receiver { void receiveThis (); } }Tu je prijímač: prijímač balíkov; Importovať odosielateľa. Odosielateľ; public class SpecificReceiver implementuje Sender.Receiver { public void receiveThis () { //do something interesting. } }Poznámka: Príjemca závisí od odosielateľa, SpecificReceiver závisí od odosielateľa a v odosielateľovi nie sú žiadne informácie súvisiace s prijímateľom. Áno, ale klamete, dávate rozhranie prijímateľa do triedy odosielateľa. Začínaš chápať. Čo vieš? Samozrejme, je to princíp architektúry. Odosielateľ má rozhranie, ktoré musí prijímateľ implementovať. Ak to znamená, že musím používať vnorené triedy, tak ...... Vnorené triedy sú len jedným z prostriedkov k cieľu, existujú aj iné spôsoby. Počkaj chvíľu. Čo to má spoločné s databázami? Začali sme hovoriť o databázach. Pozrime sa na kód trochu podrobnejšie. Prvým je jednoduché obchodné pravidlo: balíkové pravidlá; importovať entity. Niečo; verejná trieda BusinessRule { súkromná brána BusinessRuleGateway; public BusinessRule (brána BusinessRuleGateway) { this.gateway = brána; } public void execute (String ID) { gateway.startTransaction (); Something thing = gateway.getSomething (id); thing.makeChanges (); gateway.saveNiečo (vec); gateway.endTransaction (); } }Obchodné pravidlá nemajú veľkú váhu. Toto je len jeden príklad. Mohlo by existovať viac takýchto tried, ktoré implementujú rôzne obchodné pravidlá. Dobre, čo vlastne je Gateway? Poskytuje všetky metódy prístupu k dátam prostredníctvom obchodných pravidiel. Implementujte ho nasledovne: balíkové pravidlá; importovať entity. Niečo; verejné rozhranie BusinessRuleGateway { Something getSomething (String ID); void startTransaction (); void saveSomething (Niečo vec); void endTransaction (); }Poznámka: Toto je v businessRules. Dobre, čo je to trieda Niečo? Predstavuje jednoduchý obchodný objekt. Dávam to do entít. balové entity; public class Something { public void makeChanges () { //... } }V konečnom dôsledku implementácia BusinessRuleGateway, táto trieda pozná skutočnú databázu: databázu balíkov; importovať businessRules.BusinessRuleGateway; importovať entity. Niečo; public class MySqlBusinessRuleGateway implementuje BusinessRuleGateway { public Something getSomething (String ID) { // use MySQL na get a thing. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySQL } public void endTransaction () { // end MySql transakcia } }Okrem toho si všimnite, že obchodné pravidlá volajú databázu počas behu; Avšak pri kompilácii databáza zahŕňa a závisí od businessRules. No, myslím, že to chápem. Používate polymorfizmus len na to, aby ste skryli fakt, že databáza je implementovaná, z obchodných pravidiel. Napriek tomu je stále potrebné rozhranie, ktoré poskytne všetky databázové nástroje pre obchodné pravidlá. Nie, vôbec nie. Nepokúsili sme sa poskytovať databázové nástroje pre obchodné pravidlá. Namiesto toho používajú obchodné pravidlá na vytváranie rozhraní podľa svojich potrieb. Implementácia týchto rozhraní vám umožní volať správne nástroje. Áno, ale ak potrebujete použiť všetky nástroje pre všetky obchodné pravidlá, jednoducho dajte nástroj do rozhrania brány. Ah, myslím, že ešte nechápeš. Pochopiť čo? To je už jasné. Každé obchodné pravidlo definuje len jedno rozhranie pre nástroje na prístup k dátam, ktoré potrebuje. Počkaj chvíľu, čo povieš? Toto je princíp segregácie rozhraní. Každá trieda obchodných pravidiel používa len určité funkcie databázy. Preto rozhrania poskytované každým obchodným pravidlom môžu pristupovať len k príslušným zariadeniam. To však znamená, že existuje mnoho rozhraní a mnoho malých implementačných tried, ktoré volajú iné databázové triedy. Skvelé, začínaš chápať. Ale je to príliš chaotická a strata času. Prečo to robiť? Je to organizované a šetrí čas. No tak, zoberte si veľa kódu len pre samotný kód. Naopak, irelevantné rozhodnutia môžu byť odkladané dôležitými architektonickými rozhodnutiami. Čo to znamená? Pamätám si, že na začiatku si povedal, že chceš byť softvérovým architektom, však? Chcete robiť všetky rozhodnutia, na ktorých naozaj záleží. Áno, presne to som si myslel. Chcete robiť rozhodnutia o databázach, webových serveroch a frameworkoch, však? Áno, hovoríš, že na tom nezáleží. Len irelevantný obsah. Presne tak. To je všetko. Dôležité rozhodnutia, ktoré robia softvéroví architekti, sú tie, ktoré vám umožňujú rozhodovať o databázach, webových serveroch a frameworkoch. Ale najprv sa musíš rozhodnúť, ktoré to bude! Nie, nefunguje to. V skutočnosti sa o nich dá rozhodnúť neskôr vo vývojovom cykle, keď je informácií viac. Je to katastrofa, ak architekti vopred identifikujú rámce, len aby zistili, že neposkytujú požadovaný výkon alebo zavádzajú neúnosné obmedzenia. Iba keď sa architekt rozhodne rozhodnutie odložiť, urobí rozhodnutie, keď budú informácie dostatočné; Tímy, ktoré nepoužívajú pomalé a zdrojovo náročné IO zariadenia a frameworky, môžu vytvárať rýchle a ľahké testovacie prostredia podľa uváženia architektov. Len jeho architekti sa starajú o to, na čom naozaj záleží, a zdržiavajú tých, ktorí nie, a takýto tím je ten šťastný. Nesmysel, vôbec nerozumiem, čo tým myslíš. No, dobre si prečítajte tento článok, inak budete musieť čakať ďalších 10 rokov, kým na to prídete.
| 
Zverejnené 27. 9. 2017 15:29:46
|
|
|
Zverejnené 28. 9. 2017 15:00:37
|
Prenajímateľ|
Zverejnené 29. 9. 2017 8:34:23
|
Zverejnené 27. 11. 2018 11:12:17
|
