Hei! Vi fortsetter nå å fordype oss i et omfattende og superviktig nyttig tema: designmønstre. La oss i dag snakke om bromønsteret. Som andre mønstre tjener bromønsteret til å løse typiske problemer som en utvikler møter når han designer programvarearkitektur. La oss i dag studere funksjonene til dette mønsteret og finne ut hvordan du bruker det.
Hva er bromønsteret?
Bromønsteret er et strukturelt designmønster. Med andre ord er hovedoppgaven å skape en fullverdig struktur av klasser og objekter. En bro gjør dette ved å dele en eller flere klasser inn i separate hierarkier: abstraksjon og implementering . En endring i funksjonalitet i det ene hierarkiet medfører ikke en endring i det andre. Det er bra og greit, men denne definisjonen er veldig bred og svarer ikke på det viktigste spørsmålet: "Hva er bromønsteret?" Jeg tror det vil være lettere for deg å forstå den praktiske anvendelsen. Så med en gang, la oss lage et klassisk scenario for bromønsteret. Vi har en abstrakt Shapeklasse, som representerer en generisk geometrisk figur:
Shape.java
public abstract class Shape {
public abstract void draw();
}
Når vi bestemmer oss for å legge til figurer som trekanter og rektangler, vil vi få dem til å arve klassen Shape:
Rectangle.java:
public class Rectangle extends Shape {
@Override
public void draw() {
System.out.println("Drawing rectangle");
}
}
Triangle.java:
public class Triangle extends Shape {
@Override
public void draw() {
System.out.println("Drawing triangle");
}
}
Alt ser enkelt ut til det øyeblikket vi introduserer konseptet farge. Det vil si at hver form vil ha sin egen farge, og funksjonaliteten til metoden draw()vil avhenge av denne fargen. For å ha forskjellige implementeringer av draw()metoden, må vi lage en klasse for hver form-fargekombinasjon. Hvis vi har tre farger, trenger vi seks klasser: TriangleBlack, TriangleGreen, TriangleRed, RectangleBlack, RectangleGreenog RectangleRed. Seks klasser er ikke et så stort problem. Men! Hvis vi trenger å legge til en ny form eller farge, vokser antallet klasser eksponentielt. Hvordan komme seg ut av denne situasjonen? Å lagre farge i et felt og telle opp alle alternativene ved hjelp av betingede utsagn er ikke den beste løsningen. En god løsning er å flytte farge til et eget grensesnitt. Ikke før sagt enn gjort: la oss lage et Colorgrensesnitt med tre implementeringer: BlackColor, GreenColorog RedColor:
Color.java:
public interface Color {
void fillColor();
}
BlackColor.java:
public class BlackColor implements Color {
@Override
public void fillColor() {
System.out.println("Filling in black color");
}
}
GreenColor.java
public class GreenColor implements Color {
@Override
public void fillColor() {
System.out.println("Filling in green color");
}
}
RedColor.java
public class RedColor implements Color {
@Override
public void fillColor() {
System.out.println("Filling in red color");
}
}
Nå legger vi til et Colorfelt i Shapeklassen. Vi får dens verdi i konstruktøren.
Shape.java:
public abstract class Shape {
protected Color color;
public Shape(Color color) {
this.color = color;
}
public abstract void draw();
}
Vi vil bruke colorvariabelen i Shapeimplementeringer. Dette betyr at former nå kan bruke funksjonaliteten til grensesnittet Color.
Rectangle.java
public class Rectangle extends Shape {
public Rectangle(Color color) {
super(color);
}
@Override
public void draw() {
System.out.println("Drawing rectangle");
color.fillColor();
}
}
Ta-da! Nå kan vi lage forskjellige farger og former i det uendelige, og antallet klasser vil øke bare lineært. Feltet Color colorer en bro som forbinder to separate klassehierarkier.
Hvordan bygge en bro: abstraksjon og implementering
La oss se på et klassediagram som viser bromønsteret: Her kan du se to uavhengige strukturer som kan modifiseres uten at det påvirker hverandres funksjonalitet. I vårt tilfelle:
Abstraksjon er Shapeklassen
RefinedAbstraction er Triangleog Rectangleklasser
Implementator er Colorgrensesnittet
ConcreteImplementor er BlackColor, GreenColorog RedColorklassene.
Klassen Shapeer en abstraksjon - en mekanisme for å administrere fyllingen av former med forskjellige farger, som delegerer til grensesnittet Color(Implementor). Klassene Triangleog Rectangleer konkrete klasser som bruker mekanismen som er gjort tilgjengelig av Shapeklassen. BlackColor, GreenColorog RedColorer konkrete implementeringer i implementeringshierarkiet.
Hvor skal man bruke bromønsteret
En stor fordel med å bruke dette mønsteret er at du kan gjøre endringer i funksjonsklassene i ett hierarki uten å bryte logikken til det andre. Denne tilnærmingen bidrar også til å redusere kobling mellom klasser. Hovedkravet når du bruker dette mønsteret er "følg instruksjonene" - ikke ignorer noen av dem! For det formål, la oss finne ut situasjonene når du definitivt bør bruke bromønsteret:
Hvis du trenger å utvide antall enheter basert på kombinasjoner av to konsepter (f.eks. former og farger).
Hvis du ønsker å dele en stor klasse som ikke oppfyller enkeltansvarsprinsippet i mindre klasser som har snever funksjonalitet.
Hvis det er nødvendig å gjøre endringer i logikken til visse enheter mens programmet kjører.
Hvis det er nødvendig å skjule en implementering fra klientene til klassen eller biblioteket.
Når du bruker dette mønsteret, husk alltid at det legger til flere enheter til koden din - det er kanskje ikke fornuftig å bruke det i et prosjekt der det bare er én form og én eller to mulige farger.
Fordeler og ulemper med mønsteret
Som andre mønstre har en bro både fordeler og ulemper. Fordeler med bromønsteret:
Det forbedrer skalerbarheten til kode - du kan legge til funksjonalitet uten frykt for å ødelegge noe i en annen del av programmet.
Det reduserer antall underklasser når antallet enheter ellers ville vært basert på kombinasjoner av to konsepter (for eksempel former og farger).
Det gjør det mulig å arbeide separat på to separate hierarkier — Abstraksjon og Implementering. To forskjellige utviklere kan gjøre endringer uten å fordype seg i detaljene i hverandres kode.
Det reduserer koblingen mellom klasser - det eneste stedet hvor de to klassene er koblet er broen (dvs. feltet Color color).
Ulemper med bromønsteret:
Avhengig av den spesifikke situasjonen og den generelle strukturen til et prosjekt, kan det påvirke ytelsen til et program negativt (for eksempel hvis du trenger å initialisere flere objekter).
Det gjør koden mindre lesbar på grunn av behovet for å bytte mellom de to klassene.
Forskjell fra strategimønsteret
Bromønsteret forveksles ofte med et annet designmønster - strategi. De bruker begge komposisjon (selv om vi brukte aggregering i eksemplet med figurer og farger, kan bromønsteret også bruke komposisjon), og delegerer arbeid til andre objekter. Men det er forskjell på dem, og den er enorm. Strategimønsteret er et atferdsmønster: det løser helt andre problemer. Strategi lar algoritmer utveksles, mens bridge skiller en abstraksjon fra implementeringer for å velge mellom ulike implementeringer. Med andre ord, i motsetning til en strategi, gjelder en bro for hele enheter eller hierarkiske strukturer. Bromønsteret kan være et godt våpen i en utvikleres arsenal. Det viktigste er å identifisere situasjonene der det er verdt å bruke det og gjenkjenne når et annet mønster er passende.
Her kan du se to uavhengige strukturer som kan modifiseres uten at det påvirker hverandres funksjonalitet. I vårt tilfelle:
GO TO FULL VERSION