Dette innlegget ble sist redigert av Summer 27.09.2017 kl. 15:32
Denne artikkelen er en novelle som etterligner spørsmål og svar, og forfatteren bruker en humoristisk stil for kort å analysere arbeidet arkitekter gjør: Jeg vil bli programvarearkitekt. Dette er et flott alternativ for unge programvareutviklere. Jeg vil lede teamet og ta viktige beslutninger om databaser og rammeverk, webservere osv. Å, da vil du ikke være programvarearkitekt i det hele tatt. Selvfølgelig ønsket jeg å være den som tok viktige beslutninger. Det er greit, men du inkluderer ikke viktige beslutninger på listen din, som er irrelevante avgjørelser. Hva mener du? Mener du at databaser ikke er viktige beslutninger, vet du hvor mye vi bruker på dem? Kanskje det koster for mye. Databaser er imidlertid ikke en av de viktige beslutningene. Hvordan kan du si det? Databasen er kjernen i systemet, hvor all data systematiseres, klassifiseres, indekseres og får tilgang til. Uten en database ville det ikke vært noe system. Databasen er bare en IO-enhet som tilfeldigvis gir noen nyttige verktøy for klassifisering, spørringer og informasjonsrapportering, men dette er bare hjelpefunksjoner i systemarkitekturen. Hjelp? Dette er opprørende. Det stemmer, det er hjelpe. Forretningsreglene i systemet kan kanskje dra nytte av noen av disse verktøyene, men disse verktøyene er ikke iboende i de tilsvarende forretningsreglene. Om nødvendig kan du erstatte de eksisterende med andre verktøy; Og forretningsreglene vil ikke endres. Vel, ja, men det måtte kodes på nytt, fordi disse verktøyene ble brukt i den opprinnelige databasen. Det er ditt problem. Hva mener du? Problemet ditt er at du tror forretningsregler er avhengige av databaseverktøy, men det er de ikke. Eller i det minste burde det ikke være slik før en god arkitektur er tilgjengelig. Det er bare sprøtt. Hvordan lager man forretningsregler som ikke bruker disse verktøyene? Jeg sier ikke at de ikke bruker databaseverktøy, men de er ikke avhengige av det. Forretningsregler trenger ikke å vite hvilken database du bruker. Så hvordan får du tak i forretningsregler uten å vite hvilke verktøy du skal bruke? Inverter avhengighetene slik at databasen avhenger av forretningsregler. Sørg for at forretningsregler ikke er avhengige av databasen. Du snakker tull. Tvert imot, jeg bruker språket til programvarearkitektur. Dette er prinsippet om avhengighetsinversjon: lavnivåstandarder bør basere seg på høynivåstandarder. Tull! Høynivåkriterier (forutsatt å referere til forretningsregler) Kalle lavnivåkriterier (forutsatt referanse til databaser). Derfor vil høynivåkriteriet basere seg på lavnivåkriteriet i henhold til prinsippet om at kalleren er avhengig av mottakeren. Alle vet dette! Dette gjelder under kjøretid. Men når vi kompilerer, ønsker vi avhengighetsinversjon. Kildekoden til de overordnede retningslinjene skal ikke nevne kildekoden til de lavnivå-retningslinjene. Kom igjen! Hvordan kan du ringe uten å nevne det? Selvfølgelig, ikke noe problem. Det er det objektorientert innebærer. Objektorientering handler om å lage virkelige modeller som kombinerer data, funksjonalitet og sammenhengende objekter. Det handler om å organisere kode i en intuitiv struktur. Er det det de sier? Som vi alle vet, er dette den åpenbare sannheten. Ja, det er det, men når man bruker objektorienterte retningslinjer, er det faktisk mulig å påkalle uten å nevne det. Vel, hvordan gjør man det? I objektorientert design sender objekter meldinger til hverandre. Det stemmer, selvfølgelig. Når en avsender sender en melding, vet den ikke hvilken type mottaker det er. Det avhenger av språket som brukes. I Java kjenner avsenderen i det minste til mottakerens basistype. I Ruby vet avsenderen i det minste at mottakeren er i stand til å håndtere de mottatte meldingene. Det stemmer. Uansett vet ikke avsenderen hvilken type mottaker det er. Det stemmer, vel, det er det. Derfor kan en sender designe en mottaker for å utføre en funksjon uten å nevne den spesifikke typen mottaker. Det stemmer, det stemmer. Jeg skjønner. Avsenderen er imidlertid fortsatt avhengig av mottakeren. Dette gjelder under kjøretid. Men det er annerledes når det kompileres. Kildekoden til avsenderen nevner ikke eller avhenger av mottakerens kildekode. Faktisk avhenger mottakerens kildekode av avsenderens kildekode. Aldri verden! Avsenderen avhenger fortsatt av hvilken klasse den sender. Kanskje fra noe kildekode vil det bli klarere. Følgende avsnitt er skrevet på Java. Først ut er avsenderen: pakkeavsender; offentlig klasse Sender { privat mottaker mottaker; public Sender (Receiver r) { receiver = r; } public void doSomething () { receiver.receiveThis (); } offentlig grensesnitt Mottaker { void receiveThis (); } }Her er mottakeren: pakkemottaker; Importer avsender. Avsender; offentlig klasse SpecificReceiver implementerer Sender.Receiver { public void receiveThis () { //do something interesting. } }Merk: Mottaker avhenger av avsender, SpecificReceiver avhenger av avsender, og det finnes ingen mottakerrelatert informasjon i avsenderen. Ja, men du lyver, du la mottakerens grensesnitt i sender-klassen. Du begynner å forstå. Hva vet du? Selvfølgelig er det prinsippet om arkitektur. Sender har grensesnittet som mottakeren må implementere. Hvis det betyr at jeg må bruke nestede klasser, så ...... Nestede klasser er bare ett av midlene til et mål, det finnes andre måter. Vel, vent litt. Hva har dette med databaser å gjøre? Vi begynte å snakke om databaser. La oss se litt nærmere på koden. Den første er en enkel forretningsregel: package businessRules; Import-enheter. Noe; public class BusinessRule { private BusinessRuleGateway gateway; offentlig BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Something thing = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (ting); gateway.endTransaction (); } }Forretningsregler har ikke mye tyngde. Dette er bare ett eksempel. Det kan finnes flere slike klasser som implementerer mange forskjellige forretningsregler. Ok, så hva er egentlig Gateway? Den tilbyr alle datatilgangsmetoder gjennom forretningsregler. Implementer det som følger: package businessRules; Import-enheter. Noe; offentlig grensesnitt BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (Noe-ting); void endTransaction (); }Merk: Dette er i businessRules. Ok, hva er Noe-klassen? Det representerer et enkelt forretningsobjekt. Jeg setter det i entiteter. pakkeenheter; offentlig klasse Noe { offentlig void makeChanges () { //... } }Til syvende og sist BusinessRuleGateway-implementeringen, denne klassen kjenner den virkelige databasen: pakkedatabase; importere businessRules.BusinessRuleGateway; Import-enheter. Noe; offentlig klasse MySqlBusinessRuleGateway implementerer BusinessRuleGateway { public Something getSomething (String id) { // bruk MySQL for å hente en ting. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySQL-transaksjon } }I tillegg bør du merke deg at forretningsreglene kaller databasen under kjøring; Men ved kompilering involverer databasen og avhenger av businessRules. Vel, jeg tror jeg skjønner det. Du bruker bare polymorfisme for å skjule at databasen er implementert for forretningsregler. Likevel trengs det fortsatt et grensesnitt for å tilby alle databaseverktøyene til forretningsreglene. Nei, ikke i det hele tatt. Vi har ikke forsøkt å tilby databaseverktøy til forretningsregler. I stedet bruker de forretningsregler for å lage grensesnitt for det de trenger. Ved å implementere disse grensesnittene kan du kalle de riktige verktøyene. Ja, men hvis du trenger å bruke alle verktøy for alle forretningsregler, så legg verktøyet bare i gateway-grensesnittet. Ah, jeg tror ikke du fortsatt forstår. Forstår hva? Dette er allerede klart. Hver forretningsregel definerer kun ett grensesnitt for de datatilgangsverktøyene den trenger. Vent litt, hva sier du? Dette er prinsippet om grensesnittsegregering. Hver forretningsregelklasse bruker kun visse funksjoner i databasen. Derfor kan grensesnittene som tilbys av hver forretningsregel kun få tilgang til de tilsvarende fasilitetene. Dette betyr imidlertid at det finnes mange grensesnitt og mange små implementasjonsklasser som kaller andre databaseklasser. Flott, du begynner å forstå. Men det er for rotete og bortkastet tid. Hvorfor gjøre dette? Dette er organisert og sparer tid. Kom igjen, skaff mye kode bare for kodens skyld. Tvert imot kan irrelevante beslutninger forsinkes gjennom viktige arkitektoniske avgjørelser. Hva betyr det? Jeg husker i begynnelsen at du sa at du ville bli programvarearkitekt, ikke sant? Du vil ta alle beslutningene som virkelig betyr noe. Ja, det var det jeg trodde. Du vil ta beslutninger om databaser, webservere og rammeverk, ikke sant? Ja, du sier at ingenting av det betyr noe. Bare irrelevant innhold. Det stemmer. Det er det. De viktige beslutningene som tas av programvarearkitekter er de som lar deg ta beslutninger om databaser, webservere og rammeverk. Men du må bestemme deg for hvilke først! Nei, det fungerer ikke. Faktisk kan disse avgjøres senere i utviklingssyklusen, når informasjonen er mer rikelig. Det er en katastrofe hvis arkitekter identifiserer rammeverk på forhånd, bare for å oppdage at de ikke leverer nødvendig ytelse eller innfører utålelige begrensninger. Først når arkitekten bestemmer seg for å utsette avgjørelsen, vil han ta en beslutning når informasjonen er tilstrekkelig; Team som ikke bruker trege og ressurskrevende IO-enheter og rammeverk kan lage raske, lette testmiljøer etter arkitektenes skjønn. Bare arkitektene bryr seg om hva som virkelig betyr noe og forsinker de som ikke gjør det, og et slikt team er det heldige. Tull, jeg forstår ikke hva du mener i det tatt. Vel, ta en god titt på denne artikkelen, ellers må du vente ti år til for å finne ut av det.
| 
Publisert på 27.09.2017 15:29:46
|
|
|
Publisert på 28.09.2017 15:00:37
|
Vert|
Publisert på 29.09.2017 08:34:23
|
Publisert på 27.11.2018 11:12:17
|
