Dette indlæg blev sidst redigeret af Summer den 27-9-2017 kl. 15:32
Denne artikel er en kort historie, der efterligner spørgsmål og svar, og forfatteren bruger en humoristisk stil til kort at analysere det arbejde, arkitekter udfører: Jeg vil være softwarearkitekt. Dette er en god mulighed for unge softwareudviklere. Jeg vil lede teamet og træffe vigtige beslutninger om databaser og frameworks, webservere osv. Åh, så vil du slet ikke være softwarearkitekt. Selvfølgelig ville jeg være den, der træffer vigtige beslutninger. Det er fint, men du inkluderer ikke vigtige beslutninger på din liste, som er irrelevante beslutninger. Hvad mener du? Siger du, at databaser ikke er vigtige beslutninger, ved du hvor meget vi bruger på dem? Måske koster det for meget. Databaser er dog ikke en af de vigtige beslutninger. Hvordan kan du sige det? Databasen er kernen i systemet, hvor alle data systematiseres, klassificeres, indekseres og tilgås. Uden en database ville der ikke være noget system. Databasen er blot en IO-enhed, der tilfældigvis giver nogle nyttige værktøjer til klassificering, forespørgsler og informationsrapportering, men disse er kun hjælpefunktioner i systemarkitekturen. Hjælp? Det er skandaløst. Det er rigtigt, det er hjælpeudstyr. Systemets forretningsregler kan muligvis udnytte nogle af disse værktøjer, men disse værktøjer er ikke iboende i de tilsvarende forretningsregler. Hvis nødvendigt, kan du udskifte de eksisterende med andre værktøjer; Og forretningsreglerne vil ikke ændre sig. Jo, men det måtte kodes om, fordi disse værktøjer blev brugt i den oprindelige database. Det er dit problem. Hvad mener du? Dit problem er, at du tror, forretningsregler afhænger af databaseværktøjer, men det er de ikke. Eller i det mindste burde det ikke være sådan, før der er en god arkitektur på plads. Det er bare vanvittigt. Hvordan skaber man forretningsregler, der ikke bruger de værktøjer? Jeg siger ikke, at de ikke bruger databaseværktøjer, men de er ikke afhængige af det. Forretningsregler behøver ikke at vide, hvilken database du bruger. Så hvordan får man forretningsregler uden at vide, hvilke værktøjer man skal bruge? Inverter afhængighederne, så databasen afhænger af forretningsreglerne. Sørg for, at forretningsregler ikke er afhængige af databasen. Du snakker vrøvl. Tværtimod bruger jeg softwarearkitekturens sprog. Dette er princippet om afhængighedsinversion: lavniveaustandarder bør basere sig på højniveaustandarder. Vrøvl! Højniveaukriterier (forudsat at det refererer til forretningsregler) Kalder lavniveaukriterier (forudsat at man henviser til databaser). Derfor vil højniveaukriteriet basere sig på lavniveaukriteriet ifølge princippet om, at kalderen afhænger af modtageren. Alle ved det! Det gælder under kørsel. Men når vi kompilerer, ønsker vi afhængighedsinversion. Kildekoden til de overordnede retningslinjer bør ikke nævne kildekoden til de lavniveau-retningslinjer. Kom nu! Hvordan kan du ringe uden at nævne det? Selvfølgelig intet problem. Det er det, objektorienteret handler om. Objektorientering handler om at skabe virkelige modeller og kombinere data, funktionalitet og sammenhængende objekter. Det handler om at organisere kode i en intuitiv struktur. Er det, hvad de siger? Som vi alle ved, er dette den åbenlyse sandhed. Ja, det er det, men når man bruger objektorienterede retningslinjer, er det faktisk muligt at påkalde uden at nævne det. Hvordan gør man det? I objektorienteret design sender objekter beskeder til hinanden. Det er selvfølgelig rigtigt. Når en afsender sender en besked, ved den ikke, hvilken type modtager det er. Det afhænger af det sprog, der bruges. I Java kender afsenderen mindst modtagerens basistype. I Ruby ved afsenderen i det mindste, at modtageren er i stand til at håndtere de modtagne beskeder. Det er rigtigt. Under alle omstændigheder kender afsenderen dog ikke den specifikke type modtager. Det er rigtigt, det er det. Derfor kan en afsender designe en modtager til at udføre en funktion uden at nævne den specifikke type modtager. Det er rigtigt, det er rigtigt. Det forstår jeg. Dog afhænger afsenderen stadig af modtageren. Det gælder under kørsel. Dog er det anderledes, når det er kompileret. Afsenderens kildekode nævner ikke modtagerens kildekode eller afhænger af den. Faktisk afhænger modtagerens kildekode af afsenderens kildekode. På ingen måde! Afsenderen afhænger stadig af den klasse, den sender. Måske vil det være tydeligere ud fra noget kildekode. Følgende afsnit er skrevet på Java. Først er afsenderen: pakkeafsender; offentlig klasse Sender { privat modtager modtager; public Sender (Receiver r) { receiver = r; } public void doSomething () { receiver.receiveThis (); } offentlig grænseflade Modtager { void receiveThis (); } }Her er modtageren: pakkemodtager; Importafsender. Afsender; offentlig klasse SpecificReceiver implementerer Sender.Receiver { public void receiveThis () { //do something interesting. } }Bemærk: Modtageren afhænger af afsenderen, SpecificReceiver afhænger af afsenderen, og der er ingen modtagerrelateret information i afsenderen. Ja, men du lyver, du har lagt modtagerens interface i sender-klassen. Du begynder at forstå. Hvad ved du? Selvfølgelig er det princippet om arkitektur. Afsenderen har det interface, som modtageren skal implementere. Hvis det betyder, at jeg skal bruge indlejrede klasser, så ...... Indlejrede klasser er bare et af midlene til et mål, der findes andre måder. Vent lige et øjeblik. Hvad har det med databaser at gøre? Vi begyndte at tale om databaser. Lad os se lidt nærmere på koden. Den første er en simpel forretningsregel: package businessRules; importenheder. Noget; public class BusinessRule { private BusinessRuleGateway gateway; public 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 meget vægt. Dette er blot ét eksempel. Der kunne være flere sådanne klasser, der implementerer mange forskellige forretningsregler. Okay, så hvad er Gateway egentlig? Den leverer alle dataadgangsmetoder gennem forretningsregler. Implementér det som følger: package businessRules; importenheder. Noget; offentlig grænseflade BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (Something-ting); void endTransaktion (); }Bemærk: Dette er i businessRules. Okay, hvad er Noget-klassen? Det repræsenterer et simpelt forretningsobjekt. Jeg satte det i entiteter. pakkeenheder; offentlig klasse Noget { public void makeChanges () { //... } }I sidste ende er BusinessRuleGateway-implementeringen, denne klasse kender den rigtige database: pakkedatabase; importere businessRules.BusinessRuleGateway; importenheder. Noget; offentlig klasse MySqlBusinessRuleGateway implementerer BusinessRuleGateway { public Something getSomething (String id) { // brug MySQL for at hente noget. } public void startTransaktion () { // start MySql-transaktion } public void saveSomething (Something-ting) { // gem ting i MySql } public void endTransaction () { // slut MySql-transaktion } }Bemærk derudover, at forretningsreglerne kalder databasen under kørsel; Men ved kompileringstidspunktet involverer databasen og afhænger af businessRules. Nå, jeg tror, jeg forstår det. Du bruger bare polymorfi til at skjule, at databasen er implementeret ud fra forretningsregler. Dog er der stadig behov for et interface for at levere alle databaseværktøjer til forretningsreglerne. Nej, slet ikke. Vi har ikke forsøgt at levere databaseværktøjer til forretningsregler. I stedet bruger de forretningsregler til at skabe grænseflader til det, de har brug for. Implementeringen af disse grænseflader gør det muligt at kalde de rigtige værktøjer. Ja, men hvis du skal bruge alle værktøjer til alle forretningsregler, så sæt bare værktøjet i gateway-interfacet. Ah, jeg tror ikke, du stadig forstår. Forstå hvad? Det er allerede klart. Hver forretningsregel definerer kun ét interface til de dataadgangsværktøjer, den har brug for. Vent lige, hvad siger du? Dette er Interface Segregation Principle. Hver forretningsregelklasse bruger kun visse faciliteter i databasen. Derfor kan grænsefladerne, som hver forretningsregel tilbyder, kun tilgå de tilsvarende faciliteter. Det betyder dog, at der findes mange grænseflader og mange små implementeringsklasser, der kalder andre databaseklasser. Fint, du begynder at forstå det. Men det er for rodet og spild af tid. Hvorfor gøre det? Det er organiseret og sparer tid. Kom nu, få en masse kode for kodens skyld. Tværtimod kan irrelevante beslutninger forsinkes gennem vigtige arkitektoniske beslutninger. Hvad betyder det? Jeg kan huske, at du i starten sagde, at du ville være softwarearkitekt, ikke? Du vil træffe alle de beslutninger, der virkelig betyder noget. Ja, det var også det, jeg tænkte. Du vil gerne træffe beslutninger om databaser, webservere og frameworks, ikke? Ja, du siger, at intet af det betyder noget. Bare irrelevant indhold. Det er rigtigt. Det er det. De vigtige beslutninger, som softwarearkitekter træffer, er dem, der giver dig mulighed for at træffe beslutninger om databaser, webservere og frameworks. Men du skal først beslutte dig for, hvilke der er! Nej, det virker ikke. Faktisk kan disse besluttes senere i udviklingscyklussen, når informationen er mere rigelig. Det er en katastrofe, hvis arkitekter identificerer frameworks på forhånd, blot for at opdage, at de ikke leverer den nødvendige ydeevne eller indfører utålelige begrænsninger. Først når arkitekten beslutter at udsætte beslutningen, træffer han en beslutning, når informationen er tilstrækkelig; Teams, der ikke bruger langsomme og ressourcekrævende IO-enheder og -frameworks, kan skabe hurtige, lette testmiljøer efter arkitekternes skøn. Kun dets arkitekter bekymrer sig om, hvad der virkelig betyder noget, og forsinker dem, der ikke gør, og sådan et hold er det heldige. Vrøvl, jeg forstår slet ikke, hvad du mener. Nå, tag et godt kig på denne artikel, ellers må du vente yderligere 10 år for at finde ud af det.
| 
Opslået på 27/09/2017 15.29.46
|
|
|
Opslået på 28/09/2017 15.00.37
|
Udlejer|
Opslået på 29/09/2017 08.34.23
|
Opslået på 27/11/2018 11.12.17
|
