8.1 Nedbrydning er alt
For klarhedens skyld et billede fra en god artikel "Afkobling af objektorienterede systemer", der illustrerer de hovedpunkter, der vil blive diskuteret.
Synes du stadig, at det er nemt at designe en applikationsarkitektur?
8.2 Interfaces, implementeringsskjul
Hovedprincipperne for at reducere koblingen af systemet er principperne for OOP og princippet om indkapsling + abstraktion + polymorfi bag dem.
Det er derfor:
- Moduler skal være "sorte bokse" for hinanden (indkapsling) . Det betyder, at et modul ikke skal "klatre" ind i et andet modul og vide noget om dets interne struktur. Objekter i et undersystem bør ikke få direkte adgang til objekter i et andet undersystem.
- Moduler/undersystemer bør kun interagere med hinanden gennem grænseflader (det vil sige abstraktioner , der ikke afhænger af implementeringsdetaljer). Derfor skal hvert modul have et eller flere veldefinerede grænseflader til at interagere med andre moduler.
Princippet om "black box" (indkapsling) giver os mulighed for at overveje strukturen af hvert delsystem uafhængigt af andre delsystemer. Modulet, som er en "sort boks", kan relativt frit ændres. Problemer kan kun opstå ved krydset mellem forskellige moduler (eller et modul og et miljø).
Og denne interaktion skal beskrives i den mest generelle (abstrakte) form, det vil sige i form af en grænseflade. I dette tilfælde vil koden fungere på samme måde med enhver implementering, der er i overensstemmelse med grænsefladekontrakten. Det er denne evne til at arbejde med forskellige implementeringer (moduler eller objekter) gennem en samlet grænseflade, der kaldes polymorfi.
Derfor er Servlet en grænseflade : webcontaineren ved ikke noget om servlets, for det er nogle objekter, der implementerer Servlet-grænsefladen, og det er det. Servlets ved også lidt om containerens struktur. Servlet-grænsefladen er den kontrakt, den standard, den minimale interaktion, der er nødvendig for at få Java-webapplikationer til at overtage verden.
Polymorfi er slet ikke tilsidesættelsen af metoder, som man nogle gange fejlagtigt tror, men først og fremmest udskifteligheden af moduler/objekter med samme grænseflade eller "én grænseflade, mange implementeringer". For at implementere polymorfi er arvemekanismen slet ikke nødvendig. Dette er vigtigt at forstå, fordi arv generelt bør undgås, når det er muligt .
Takket være grænseflader og polymorfi opnås netop muligheden for at ændre og udvide koden uden at ændre det, der allerede er skrevet (Open-Closed Principle).
Så længe modulernes interaktion udelukkende beskrives i form af interfaces og ikke er bundet til specifikke implementeringer, har du mulighed for helt "smertefrit" for systemet at udskifte et modul med et hvilket som helst andet, der implementerer samme interface, samt tilføje en ny og derved udvide funktionaliteten.
Det er ligesom i LEGO-konstruktøren – grænsefladen standardiserer interaktionen og fungerer som en slags stik, hvor ethvert modul med et passende stik kan tilsluttes.
Designerens fleksibilitet sikres ved, at vi blot kan udskifte et modul eller en del med en anden med de samme stik (med samme interface), samt tilføje så mange nye dele, som vi vil (samtidigt, eksisterende dele er ikke ændret eller ændret på nogen måde).
Grænseflader giver dig mulighed for at bygge et enklere system, idet du betragter hvert delsystem som en helhed og ignorerer dets interne struktur. De tillader moduler at interagere og ved samtidig intet om hinandens interne struktur, og implementerer derved fuldt ud princippet om minimal viden, som er grundlaget for løs kobling.
Jo mere generelle/abstrakte grænsefladerne er defineret, og jo færre begrænsninger de pålægger interaktion, jo mere fleksibelt er systemet. Herfra følger faktisk endnu et af principperne i SOLID - Interface Segregation Principle , som er imod "tykke grænseflader".
Han siger, at store, omfangsrige grænseflader bør opdeles i mindre, mere specifikke, så klienter af små grænseflader (afhængige moduler) kun kender til de metoder, de skal arbejde med.
Dette princip er formuleret som følger: "Kunder bør ikke være afhængige af metoder (være opmærksomme på metoder), som de ikke bruger" eller "Mange specialiserede grænseflader er bedre end en universel".
Det viser sig, at svag forbindelse kun er tilvejebragt, når modulers interaktion og afhængigheder kun beskrives ved hjælp af grænseflader, det vil sige abstraktioner, uden at bruge viden om deres interne struktur og struktur. Og faktisk er indkapsling således implementeret. Plus, vi har mulighed for at udvide/ændre systemets adfærd ved at tilføje og bruge forskellige implementeringer, det vil sige på grund af polymorfi. Ja, vi kom igen til OOP - Encapsulation, Abstraction, Polymorphism.
8.3 Facade: modulgrænseflade
Her vil en erfaren programmør spørge: Hvis designet ikke er på niveau med objekter, der selv implementerer de tilsvarende grænseflader, men på niveau med moduler, hvad er så implementeringen af modulgrænsefladen?
Svar: taler man i designmønstrets sprog, så kan et særligt objekt være ansvarlig for implementeringen af modulets grænseflade - Facade . Hvis du kalder metoder på et objekt, der indeholder Gateway-suffikset (for eksempel MobileApiGateway), så er det højst sandsynligt en facade.
En facade er et grænsefladeobjekt , der akkumulerer et højt niveau af operationer til at arbejde med et bestemt undersystem, skjuler dets interne struktur og sande kompleksitet bag det . Giver beskyttelse mod ændringer i delsystemets implementering. Fungerer som et enkelt indgangspunkt - "du sparker facaden, og han ved, hvem der skal sparkes i dette undersystem for at få det, han har brug for."
Du er netop blevet introduceret til et af de vigtigste designmønstre, der giver dig mulighed for at bruge begrebet interfaces, når du designer moduler og derved afkoble dem - "Facade".
Derudover gør "Facade" det muligt at arbejde med moduler på samme måde som med almindelige objekter og anvende alle de brugbare principper og teknikker, der bruges i design af klasser, når der designes moduler.
Bemærk : Selvom de fleste programmører forstår vigtigheden af grænseflader, når de designer klasser (objekter), ser det ud til, at mange opdager ideen om også at bruge grænseflader på modulniveau.