Erstatter direkte avhengigheter med meldinger
Noen ganger trenger en modul bare å varsle andre om at noen hendelser/endringer har skjedd i den, og det spiller ingen rolle hva som skjer med denne informasjonen senere.
I dette tilfellet trenger ikke modulene å "kjenne til hverandre" i det hele tatt, det vil si inneholde direkte lenker og samhandle direkte, men det er nok bare å utveksle meldinger (meldinger) eller hendelser (hendelser).
Noen ganger ser det ut til at modulkommunikasjon via meldinger er mye svakere enn direkte avhengighet. Faktisk, fordi metodene ikke kalles, er det ingen informasjon om klassene. Men dette er ikke noe mer enn en illusjon.
I stedet for metodenavn, begynner logikken å bli knyttet til meldingstyper, deres parametere og overførte data. Tilkoblingen til slike moduler er utsmurt.
Det pleide å være slik: vi kaller metoder - det er tilkobling, vi kaller ikke metoder - det er ingen tilkobling. Tenk deg nå at modul A begynte å sende litt forskjellige data i meldingene sine. Og samtidig vil ikke alle moduler som er avhengige av disse meldingene fungere riktig.
Anta at autorisasjonsmodulen tidligere, når du la til en ny bruker, sendte meldingen USER_ADDED, og etter oppdateringen begynte den å sende denne meldingen når den forsøkte å registrere seg og i tillegg indikere vellykket registrering eller ikke i parametrene.
Derfor er det veldig viktig å implementere meldingsmekanismen veldig kompetent. Det finnes ulike maler for dette.
Observatør. Den brukes i tilfelle av en-til-mange-avhengighet, når mange moduler avhenger av tilstanden til en - den viktigste. Den bruker e-postmekanismen, som betyr at hovedmodulen ganske enkelt sender de samme meldingene til alle sine abonnenter, og modulene som er interessert i denne informasjonen implementerer "abonnent"-grensesnittet og abonnerer på e-postlisten.
Denne tilnærmingen er mye brukt i systemer med brukergrensesnitt, slik at kjernen i applikasjonen (modellen) kan forbli uavhengig samtidig som den informerer de tilknyttede grensesnittene om at noe har endret seg og må oppdateres.
Her er meldingsformatet standardisert på operativsystemnivå, hvis utviklere skal sørge for bakoverkompatibilitet og god dokumentasjon.
Organiseringen av interaksjon gjennom distribusjon av meldinger har en ekstra "bonus" - den valgfrie eksistensen av "abonnenter" til "publiserte" (det vil si utsendte) meldinger. Et godt designet system som dette gjør at moduler kan legges til/fjernes når som helst.
Meldingsbuss
Du kan organisere utvekslingen av meldinger og bruke Mediator- mønsteret til dette på en annen måte .
Den brukes når det er en mange-til-mange-avhengighet mellom moduler. Formidleren fungerer som et mellomledd i kommunikasjon mellom moduler, fungerer som et kommunikasjonssenter og eliminerer behovet for at moduler eksplisitt refererer til hverandre.
Som et resultat blir interaksjonen mellom moduler med hverandre ("alle med alle") erstattet av interaksjonen mellom moduler kun med en mellommann ("én med alle"). Mediatoren sies å innkapsle interaksjonen mellom flere moduler.
Dette er det såkalte smarte mellomleddet . Det er der utviklere oftest begynner å legge til krykkene sine, som påvirker oppførselen til individuelle moduler ved å slå på/av mottak av visse meldinger.
Et typisk eksempel fra virkeligheten er flyplasstrafikkkontroll. Alle meldinger fra fly går til kontrollørens kontrolltårn i stedet for å sendes direkte mellom flyene. Og kontrolløren tar allerede beslutninger om hvilke fly som kan ta av eller lande, og sender på sin side meldinger til flyene.
Viktig! Moduler kan sende hverandre ikke bare enkle meldinger, men også kommandoobjekter. Slik interaksjon er beskrevet av kommandomalen . Poenget er å innkapsle en forespørsel om å utføre en spesifikk handling som et separat objekt.
Faktisk inneholder dette objektet en enkelt execute()- metode , som deretter lar deg overføre denne handlingen til andre moduler for kjøring som en parameter og generelt utføre alle operasjoner med kommandoobjektet som kan utføres på vanlige objekter.
Demeters lov
Demeterloven forbyr bruk av implisitte avhengigheter: "Objekt A må ikke ha direkte tilgang til objekt C hvis objekt A har tilgang til objekt B og objekt B har tilgang til objekt C."
Dette betyr at alle avhengigheter i koden må være "eksplisitte" - klasser / moduler kan bare bruke "sine avhengigheter" i arbeidet og skal ikke klatre gjennom dem til andre. Et godt eksempel er en tre-lags arkitektur. Grensesnittlaget skal fungere med logikklaget, men skal ikke samhandle direkte med databaselaget.
Kort fortalt er dette prinsippet også formulert på denne måten: «Samhandle bare med umiddelbare venner, og ikke med venners venner». Dette oppnår mindre koherens i koden, samt større synlighet og transparens i designet.
Demeterloven implementerer det allerede nevnte «prinsippet om minimumskunnskap», som er grunnlaget for løs kobling og består i at et objekt/modul skal vite så få detaljer som mulig om strukturen og egenskapene til andre objekter/moduler og alt generelt, inkludert dets egne komponenter .
En analogi fra livet: hvis du vil at hunden skal løpe, er det dumt å kommandere potene sine, det er bedre å gi kommandoen til hunden, og hun vil håndtere labbene sine selv.
Sammensetning i stedet for arv
Dette er et veldig stort og interessant tema og det fortjener i det minste et eget foredrag. Mange kopier ble brutt om dette emnet på Internett til en konsensus ble oppnådd - vi bruker arv til et minimum, sammensetning - til det maksimale.
Poenget er at arv faktisk gir den sterkeste sammenhengen mellom klasser, så det bør unngås. Dette emnet er godt dekket i Herb Sutters artikkel " Foretrekk sammensetning fremfor arv ".
Når du begynner å lære designmønstre, vil du komme over en hel haug med mønstre som styrer opprettelsen av et objekt eller dets interne struktur. Jeg kan forresten råde i denne sammenhengen til å ta hensyn til Delegat/Delegate- mønsteret og Component -mønsteret, som kom fra spill .
Vi snakker mer om mønstre litt senere.