Detta inlägg redigerades senast av Summer den 27-9-9 2017 kl. 15:32
Den här artikeln är en novell som imiterar frågor och svar, och författaren använder en humoristisk stil för att kort analysera det arbete som arkitekter gör: Jag vill bli mjukvaruarkitekt. Detta är ett utmärkt alternativ för unga mjukvaruutvecklare. Jag vill leda teamet och fatta viktiga beslut om databaser och ramverk, webbservrar med mera. Åh, då vill du inte alls vara mjukvaruarkitekt. Självklart ville jag vara den som fattade viktiga beslut. Det är okej, men du inkluderar inte viktiga beslut i din lista, vilket är irrelevanta beslut. Vad menar du? Säger du att databaser inte är viktiga beslut, vet du hur mycket vi lägger på dem? Kanske kostar det för mycket. Databaser är dock inte ett av de viktiga besluten. Hur kan du säga så? Databasen är systemets kärna, där all data systematiseras, klassificeras, indexeras och åtkoms. Utan en databas skulle det inte finnas något system. Databasen är bara en IO-enhet som råkar erbjuda användbara verktyg för klassificering, förfrågningar och informationsrapportering, men dessa är endast hjälpfunktioner i systemarkitekturen. Hjälp? Det här är upprörande. Just det, det är hjälp. Systemets affärsregler kan kanske dra nytta av några av dessa verktyg, men dessa verktyg är inte inneboende i motsvarande affärsregler. Om det behövs kan du byta ut de befintliga mot andra verktyg; Och affärsreglerna kommer inte att ändras. Jo, men det var tvunget att kodas om, eftersom dessa verktyg användes i den ursprungliga databasen. Det är ditt problem. Vad menar du? Ditt problem är att du tror att affärsregler är beroende av databasverktyg, men det är de inte. Eller åtminstone borde det inte vara så här förrän en bra arkitektur är framförd. Det är bara galet. Hur skapar man affärsregler som inte använder dessa verktyg? Jag säger inte att de inte använder databasverktyg, men de är inte beroende av det. Affärsregler behöver inte veta vilken databas du använder. Så hur får man affärsregler utan att veta vilka verktyg man ska använda? Invertera beroendena så att databasen bygger på affärsregler. Se till att affärsregler inte är beroende av databasen. Du pratar strunt. Tvärtom använder jag mjukvaruarkitekturens språk. Detta är principen om beroendeinversion: lågnivåstandarder bör förlita sig på högnivåstandarder. Struntprat! Högnivåkriterier (förutsatt att det hänvisar till affärsregler) Anropar lågnivåkriterier (förutsatt att man syftar på databaser). Därför kommer det högnivåkriteriet att förlita sig på det lågnivåkriteriet enligt principen att den som anropar är beroende av den som kallas. Alla vet detta! Detta gäller vid körning. Men när vi kompilerar vill vi ha beroendeinversion. Källkoden till de övergripande riktlinjerna bör inte nämna källkoden till de låga nivåriktlinjerna. Kom igen! Hur kan du ringa utan att nämna det? Självklart, inga problem. Det är vad objektorienterat handlar om. Objektorientering handlar om att skapa verkliga modeller och kombinera data, funktionalitet och sammanhängande objekt. Det handlar om att organisera kod i en intuitiv struktur. Det är vad de säger? Som vi alla vet är detta den uppenbara sanningen. Ja, det är det, men när man använder objektorienterade riktlinjer är det faktiskt möjligt att anropa utan att nämna det. Hur gör man det? I objektorienterad design skickar objekt meddelanden till varandra. Det stämmer, förstås. När en avsändare skickar ett meddelande vet den inte vilken typ av mottagare det är. Det beror på vilket språk som används. I Java känner avsändaren åtminstone till mottagarens bastyp. I Ruby vet avsändaren åtminstone att mottagaren kan hantera de mottagna meddelandena. Det stämmer. I vilket fall som helst vet dock inte sändaren vilken specifik typ av mottagare det är. Det stämmer, ja, det är det. Därför kan en sändare designa en mottagare för att utföra en funktion utan att nämna den specifika typen av mottagare. Det stämmer, det stämmer. Jag förstår. Dock är avsändaren fortfarande beroende av mottagaren. Detta gäller vid körning. Men det är annorlunda när det är kompilerat. Avsändarens källkod nämner inte eller beror på mottagarens källkod. Faktum är att mottagarens källkod beror på avsändarens källkod. Aldrig! Avsändaren beror fortfarande på vilken klass den skickar. Kanske blir det tydligare från någon källkod. Följande stycke är skrivet på Java. Först ut är avsändaren: paketavsändare; public class Sender { privat mottagarmottagare; public Sender (Receiver r) { receiver = r; } public void doSomething () { receiver.receiveThis (); } publikt gränssnitt Receiver { void receiveThis (); } }Här är mottagaren: paketmottagare; Importera avsändare. Avsändare; offentlig klass SpecificReceiver implementerar Sender.Receiver { public void receiveThis () { //do something interesting. } }Observera: Mottagaren beror på avsändaren, SpecificReceiver på avsändaren, och det finns ingen mottagarrelaterad information i avsändaren. Ja, men du ljuger, du satte mottagarens gränssnitt i avsenderklassen. Du börjar förstå. Vad vet du? Självklart är det arkitekturens princip. Sändaren har det gränssnitt som mottagaren måste implementera. Om det betyder att jag måste använda nästlade klasser, så ...... Nästlade klasser är bara ett av medlen för ett mål, det finns andra sätt. Vänta lite. Vad har detta med databaser att göra? Vi började prata om databaser. Låt oss titta lite närmare på koden. Den första är en enkel affärsregel: package businessRules; importenheter. Något; 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 (thing); gateway.endTransaction (); } }Affärsregler väger inte så tungt. Detta är bara ett exempel. Det skulle kunna finnas fler sådana klasser som implementerar många olika affärsregler. Okej, så vad är egentligen Gateway? Den tillhandahåller alla dataåtkomstmetoder genom affärsregler. Implementera det enligt följande: package businessRules; importenheter. Något; publika gränssnittet BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (Something thing); void endTransaktion (); }Obs: Detta finns i businessRules. Okej, vad är Något-klassen? Det representerar ett enkelt affärsobjekt. Jag lägger det i entiteter. paketenheter; offentlig klass Något { public void makeChanges () { //... } }I slutändan är BusinessRuleGateway-implementeringen, denna klass känner till den verkliga databasen: paketdatabas; importera businessRules.BusinessRuleGateway; importenheter. Något; public class MySqlBusinessRuleGateway implementerar BusinessRuleGateway { public Something getSomething (String id) { // använd MySQL för att hämta en sak. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySQL-transaktion } }Observera dessutom att affärsreglerna anropar databasen vid körning; Vid kompileringstillfället involverar databasen dock och är beroende av businessRules. Nåväl, jag tror jag förstår. Du använder bara polymorfism för att dölja att databasen är implementerad från affärsregler. Dock behövs fortfarande ett gränssnitt för att tillhandahålla alla databasverktyg till affärsreglerna. Nej, inte alls. Vi har inte försökt tillhandahålla databasverktyg till affärsregler. Istället använder de affärsregler för att skapa gränssnitt för det de behöver. Att implementera dessa gränssnitt gör att du kan anropa rätt verktyg. Ja, men om du behöver använda alla verktyg för alla affärsregler, så lägg bara verktyget i gateway-gränssnittet. Ah, jag tror inte du fortfarande förstår. Förstå vad? Det är redan tydligt. Varje affärsregel definierar endast ett gränssnitt för de dataåtkomstverktyg den behöver. Vänta lite, vad säger du? Detta är principen om gränssnittssegregation. Varje affärsregelklass använder endast vissa funktioner i databasen. Därför kan gränssnitten som tillhandahålls av varje affärsregel endast komma åt motsvarande funktioner. Detta innebär dock att det finns många gränssnitt och många små implementationsklasser som anropar andra databasklasser. Bra, du börjar förstå. Men det är för rörigt och slöseri med tid. Varför göra detta? Detta är organiserat och sparar tid. Kom igen, skaffa mycket kod för kodens skull. Tvärtom kan irrelevanta beslut fördröjas genom viktiga arkitektoniska beslut. Vad betyder det? Jag minns att du i början sa att du ville bli mjukvaruarkitekt, eller hur? Du vill fatta alla beslut som verkligen betyder något. Ja, det var vad jag trodde. Du vill fatta beslut om databaser, webbservrar och ramverk, eller hur? Ja, du säger att inget av det spelar någon roll. Bara irrelevant innehåll. Det stämmer. Det är allt. De viktiga beslut som mjukvaruarkitekter fattar är de som låter dig fatta beslut om databaser, webbservrar och ramverk. Men du måste bestämma vilka först! Nej, det fungerar inte. Faktum är att dessa kan beslutas senare i utvecklingscykeln, när informationen är mer riklig. Det är en katastrof om arkitekter identifierar ramverk i förväg bara för att upptäcka att de inte levererar den nödvändiga prestandan eller inför outhärdliga begränsningar. Först när arkitekten beslutar att skjuta upp beslutet kommer han att fatta ett beslut när informationen är tillräcklig; Team som inte använder långsamma och resurskrävande IO-enheter och ramverk kan skapa snabba, lättviktiga testmiljöer efter arkitekternas bedömning. Endast dess arkitekter bryr sig om vad som verkligen betyder något och fördröjer dem som inte gör det, och ett sådant team är det lyckliga. Struntprat, jag förstår inte alls vad du menar. Ta en noggrann titt på den här artikeln, annars får du vänta ytterligare 10 år för att lista ut det.
| 
Publicerad på 2017-09-27 15:29:46
|
|
|
Publicerad på 2017-09-28 15:00:37
|
Hyresvärd|
Publicerad på 2017-09-29 08:34:23
|
Publicerad på 2018-11-27 11:12:17
|
