Ezt a bejegyzést utoljára Summer szerkesztette: 2017-09-27, 15:32
Ez a cikk egy rövid történet, amely utánozza a kérdezz-felelek részét, és a szerző humoros stílusban elemezi az építészek munkáját: Szoftverépítész akarok lenni. Ez nagyszerű lehetőség fiatal szoftverfejlesztők számára. Vezetni szeretném a csapatot, és fontos döntéseket hozni az adatbázisokról, keretrendszerekről, webszerverekről stb. Ó, akkor egyáltalán nem akarsz szoftverarchitektor lenni. Természetesen én akartam a fontos döntések hozója lenni. Ez rendben van, de nem veszel bele fontos döntéseket a listádba, amelyek irrelevánsak. Hogy érted? Azt akarod mondani, hogy az adatbázisok nem fontos döntések, tudod, mennyit költünk rájuk? Talán túl sokba kerül. Az adatbázisok azonban nem tartoznak a legfontosabb döntések közé. Hogy mondhatod ezt? Az adatbázis a rendszer magja, ahol minden adatot rendszereznek, titkosítanak, indexelnek és elérnek. Adatbázis nélkül nem lenne rendszer. Az adatbázis csupán egy IO eszköz, amely hasznos eszközöket kínál osztályozáshoz, lekérdezéshez és információjelentéshez, de ezek csak a rendszer architektúrájának segédfunkciói. Segítség? Ez felháborító. Így van, ez segéd. A rendszer üzleti szabályai talán kihasználhatják ezeket az eszközöket, de ezek az eszközök nem veleszületettek a megfelelő üzleti szabályokhoz. Ha szükséges, a meglévőket más eszközökre cserélheted; És az üzleti szabályok sem változnak. Nos, igen, de újra kellett kódolni, mert ezeket az eszközöket az eredeti adatbázisban használták. Ez a te problémád. Hogy érted? A problémád az, hogy azt hiszed, az üzleti szabályok adatbázis-eszközökre épülnek, de nem azok. Vagy legalábbis nem kellene így lennie, amíg nem lesz egy jó architektúra. Ez egyszerűen őrület. Hogyan lehet olyan üzleti szabályokat létrehozni, amelyek nem használják ezeket az eszközöket? Nem azt mondom, hogy nem használnak adatbázis eszközöket, de nem is függnek tőlük. Az üzleti szabályoknak nem kell tudniuk, melyik adatbázist használod. Hogyan lehet üzleti szabályokat szerezni anélkül, hogy tudnád, milyen eszközöket kell használni? Fordítsd meg a függőségeket úgy, hogy az adatbázis az üzleti szabályoktól függjön. Győződj meg róla, hogy az üzleti szabályok ne függjenek az adatbázistól. Hülyeségeket beszélsz. Épp ellenkezőleg, a szoftverarchitektúra nyelvét használom. Ez a függőségi inverzió elve: az alacsony szintű szabványoknak magas szintű szabványokra kell támaszkodniuk. Hülyeség! Magas szintű kritériumok (üzleti szabályokra hivatkozva) Alacsony szintű kritériumok meghívása (feltételezve, hogy az adatbázisokra hivatkoznak). Ezért a magas szintű kritérium az alacsony szintű kritériumra épül, amely szerint a hívó a hívótól függ. Ezt mindenki tudja! Ez igaz a futásidőben. De fordításkor a függőség inverzióját szeretnénk. A magas szintű irányelvek forráskódja nem említheti az alacsony szintű irányelvek forráskódját. Gyerünk! Hogyan lehet telefonálni anélkül, hogy említenéd? Természetesen semmi gond. Ez az, amiről van szó az objektumorientáltságról. Az objektumorientáció a valós világú modellalkotásról szól, az adatok, funkcionalitás és az összefüggő objektumok ötvözéséről. Arról szól, hogy a kódot intuitív struktúrába szervezzük. Ezt mondják? Ahogy mindannyian tudjuk, ez a nyilvánvaló igazság. Igen, az, de objektumorientált irányelvek használata esetén valóban lehetséges megidézni anélkül, hogy említenénk azt. És hogyan lehet ezt csinálni? Az objektumorientált tervezésben az objektumok üzeneteket küldenek egymásnak. Persze, így van. Amikor egy küldő üzenetet küld, nem tudja, milyen típusú vevő. Ez attól függ, milyen nyelvezetet használ. A Java-ban a feladó legalább ismeri a vevő alaptípusát. A Ruby esetében a feladó legalább tudja, hogy a vevő képes kezelni a kapott üzeneteket. Így van. Mindenesetre azonban a feladó nem tudja, milyen típusú vevő. Így van, hát, az. Ezért a küldő tervezhet egy vevőt úgy, hogy egy funkciót ellátjon, anélkül, hogy megemlítené a vevőtípust. Így van, így van. Értem. Azonban a feladó továbbra is a címere épül. Ez igaz a futásidőben. Azonban fordításkor más. A küldő forráskódja nem említi vagy függ a vevő forráskódjától. Valójában a vevő forráskódja a feladó forráskódjától függ. Szó sem lehet róla! A feladó továbbra is attól függ, melyik osztályt küldi. Talán valamilyen forráskódból ez világosabb lesz. A következő bekezdés Java nyelven íródott. Először a feladó: csomagküldő; public class Sender { privát vevő vevő; nyilvános feladó (Vevő r) { vevő = r; } public void doSomething () { receiver.receiveThis (); } nyilvános interfész Vevő { void receiveThis (); } }Íme a vevő: csomagvevő; Importáló feladó. Feladó; public class SpecificReceiver implementálja Sender.Receiver { public void receiveThis () { //csinálj valami érdekeset. } }Megjegyzés: A vevő a feladótól függ, a SpecificReceiver a küldőtől, és nincs vevővel kapcsolatos információ a feladóban. Igen, de hazudsz, a vevő interfészét a küldő osztályba helyezed. Kezded megérteni. Mit tudsz te? Természetesen ez az építészet elve. A feladónak megvan az a felülete, amit a vevőnek meg kell valósítania. Ha ez azt jelenti, hogy be kell használnom a beágyazott osztályokat, akkor ...... Az ágyazott osztályok csak az egyik eszköz a célhoz, vannak más módok is. Várj csak. Mi köze ennek az adatbázisokhoz? Elkezdtünk az adatbázisokról beszélni. Nézzük meg még a kódot. Az első egy egyszerű üzleti szabály: csomag üzletSzabályok; importszervezetek. Valami; public class BusinessRule { private BusinessRuleGateway gateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Valami dolog = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (dolog); gateway.endTransaction (); } }Az üzleti szabályoknak nincs nagy súlyuk. Ez csak egy példa. Lehetne több ilyen osztály, amelyek sokféle üzleti szabályt alkalmaznak. Rendben, akkor pontosan mi is az a Gateway? Minden adathozzáférési módszert üzleti szabályokon keresztül biztosít. Valósítsd meg ezt a következőként: csomag üzletSzabályok; importszervezetek. Valami; public interface BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (Something thing); void endTransaction (); }Megjegyzés: Ez a businessRules adatbázisban található. Rendben, mi az a Something osztály? Ez egy egyszerű üzleti tárgyat képvisel. Én entitásokba tettem. csomagentitások; public class Valami { public void makeChanges () { //... } }Végső soron a BusinessRuleGateway megvalósítás, ez az osztály ismeri a valódi adatbázist: csomagadatbázis; importál businessRules.BusinessRuleGateway; importszervezetek. Valami; public class MySqlBusinessRuleGateway implementálja a BusinessRuleGateway { public Something getSomething (String id) { // használd MySql-t a thing megszerzéséhez. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySQL tranzakció } }Ezen felül fontos megjegyezni, hogy az üzleti szabályok futásidőben hívják az adatbázist; Azonban fordításkor az adatbázis a businessRules-t tartalmazza és függ tőlük. Azt hiszem, értem. Csak polimorfizmussal próbálod elrejteni, hogy az adatbázis üzleti szabályok elől van megvalósítva. Ugyanakkor egy interfészre van szükség, hogy az összes adatbázis-eszközt az üzleti szabályokhoz igazítsák. Nem, egyáltalán nem. Nem próbáltunk adatbázis-eszközöket biztosítani az üzleti szabályokhoz. Ehelyett üzleti szabályokat használnak, hogy felületeket hozzanak létre a szükségük érdekében. Ezeknek az interfészeknek a megvalósításával a megfelelő eszközöket kell meghívni. Igen, de ha minden eszközt használnod kell az üzleti szabályokhoz, akkor tedd be az eszközt a gateway felületére. Ah, szerintem még mindig nem érted. Mit értsek meg? Ez már világos. Minden üzleti szabály csak egy felületet határoz meg az adathozzáférési eszközökhöz, amelyekre szüksége van. Várj csak, mit szólsz? Ez az Interface Szegregációs Elv. Minden üzleti szabályosztály csak az adatbázis bizonyos funkcióit használja. Ezért az egyes üzleti szabályok által biztosított interfészek csak a megfelelő létesítményekhez férnek hozzá. Ez azonban azt jelenti, hogy sok interfész és sok kis implementációs osztály létezik, amelyek más adatbázis osztályokat hívnak. Remek, kezded megérteni. De túl rendetlen és időpocsékolás. Miért csinálod ezt? Ez szervezett és időt spórol. Gyerünk, szerezz sok kódot a kód kedvéért. Ezzel szemben a lényegtelen döntések fontos építészeti döntések miatt késleltethetők. Az mit jelent? Emlékszem, az elején azt mondtad, szoftverépítész akarsz lenni, ugye? Minden igazán fontos döntést meg akarsz hozni. Igen, ezt gondoltam. Döntéseket akarsz hozni az adatbázisokról, webszerverekről és keretrendszerekről, ugye? Igen, azt mondod, hogy mindez nem számít. Csak irreleváns tartalom. Így van. Ennyi. A szoftverarchitektorok által hozott fontos döntések azok, amelyek lehetővé teszik, hogy döntéseket hozz adatbázisokról, webszerverekről és keretrendszerekről. De először el kell döntened, melyik! Nem, nem működik. Valójában ezek a fejlesztési ciklus későbbi szakaszában dönthetők el, amikor az információ bőségesebb. Katasztrófa, ha az építészek előre azonosítják a keretrendszereket, csak hogy rájöjjenek, hogy azok nem nyújtják a szükséges teljesítményt vagy elviselhetetlen korlátokat vezetnek be. Csak akkor hozhat döntést, amikor az építész elhalasztja a döntést, amikor az információ elegendő; Azok a csapatok, amelyek nem lassú és erőforrásigényes IO eszközöket és keretrendszereket használnak, az építészek belátása szerint gyors, könnyű tesztkörnyezeteket hozhatnak létre. Csak az építészeket érdekli, ami igazán fontos, és késleltetik azokat, akik nem, és egy ilyen csapat a szerencsés. Hülyeség, egyáltalán nem értem, mire gondolsz. Nos, nézd meg alaposan ezt a cikket, különben még 10 évet kell várnod, hogy rájöjj.
| 
Közzétéve 2017. 09. 27. 15:29:46
|
|
|
Közzétéve 2017. 09. 28. 15:00:37
|
Háziúr|
Közzétéve 2017. 09. 29. 8:34:23
|
Közzétéve 2018. 11. 27. 11:12:17
|
