streamalism.org

1. Oversigt

I denne hurtige vejledning skal vi se på Null Object Pattern, et specielt tilfælde af strategimønsteret. Vi beskriver dens formål, og hvornår vi rent faktisk skal overveje at bruge det.

Som sædvanligt giver vi også et simpelt kodeeksempel.

2. Nul objektmønster

På de fleste objektorienterede programmeringssprog har vi ikke lov til at bruge en nul reference. Derfor er vi ofte tvunget til at skrive nul kontrol:

Kommando cmd = getCommand (); hvis (cmd! = null) {cmd.execute (); }

Nogle gange, hvis antallet af sådanne hvis udsagn bliver høje, koden kan blive grim, svær at læse og fejlbehæftet. Dette er når Null Object Pattern kan være praktisk.

Hensigten med Null Object Pattern er at minimere den slags nul kontrollere. I stedet kan vi identificere nuladfærden og indkapsle den i den type, der forventes af klientkoden. Oftere end ikke, sådan neutral logik er meget enkel - gør ingenting. På denne måde behøver vi ikke længere håndtere særlig håndtering af nul referencer.

Vi kan simpelthen behandle nul objekter på samme måde, som vi behandler enhver anden forekomst af en given type, der rent faktisk indeholder nogle mere sofistikerede forretningslogik. Derfor forbliver klientkoden renere.

Da null-objekter ikke skal have nogen tilstand, er der ikke behov for at oprette identiske forekomster flere gange. Således vil vi ofte implementere null objekter som singletoner.

3. Nul objektmønsters UML-diagram

Lad os se på mønsteret visuelt:

Som vi kan se, kan vi identificere følgende deltagere:

• Klient kræver en forekomst af Abstrakt Objekt
• Abstrakt Objekt definerer kontrakten Klient forventer - det kan også indeholde delt logik for implementeringsklasser
• RealObject redskaber Abstrakt Objekt og giver reel opførsel
• NullObject redskaber Abstrakt Objekt og giver neutral opførsel

4. Implementering

Nu hvor vi har en klar idé om teorien, lad os se på et eksempel.

Forestil dig, at vi har en meddelelsesrouter-applikation. Hver meddelelse skal have en gyldig prioritet. Vores system formodes at dirigere beskeder med høj prioritet til en SMS-gateway, mens meddelelser med medium prioritet skal dirigeres til en JMS-kø.

Fra tid til anden, meddelelser med "udefineret" eller tom prioritet kan dog komme til vores ansøgning. Sådanne meddelelser skal kasseres fra yderligere behandling.

Først opretter vi Router grænseflade:

offentlig grænseflade Router {ugyldig rute (Message msg); }

Lad os derefter oprette to implementeringer af ovenstående grænseflade - den, der er ansvarlig for dirigering til en SMS-gateway, og den, der dirigerer meddelelserne til JMS-køen:

offentlig klasse SmsRouter implementerer Router {@Override public void route (Message msg) {// implementeringsoplysninger}}

offentlig klasse JmsRouter implementerer router {@ Override offentlig ugyldig rute (meddelelsesmeddelelse) {// implementeringsoplysninger}}

Langt om længe, lad os implementere vores null-objekt:

offentlig klasse NullRouter implementerer Router {@Override public void route (Message msg) {// gør ingenting}}

Vi er nu klar til at sætte alle brikkerne sammen. Lad os se, hvordan eksempelklientkoden kan se ud:

public class RoutingHandler {public void handle (Iterable messages) {for (Message msg: messages) {Router router = RouterFactory.getRouterForMessage (msg); router.route (msg); }}}

Som vi kan se, vi behandler alle Router objekt på samme måde, uanset hvilken implementering der returneres af RouterFabrik. Dette giver os mulighed for at holde vores kode ren og læsbar.

5. Hvornår skal du bruge det nul-objektmønster?

Vi skal bruge Null Object Pattern, når a Klient ellers ville se efter nul bare for at springe over udførelse eller udføre en standardhandling. I sådanne tilfælde kan vi indkapsle den neutrale logik i et null-objekt og returnere det til klienten i stedet for nul værdi. På denne måde behøver klientens kode ikke længere være opmærksom, hvis en given forekomst er nul eller ikke.

En sådan tilgang følger generelle objektorienterede principper, som Tell-Don't-Ask.

For bedre at forstå, hvornår vi skal bruge Null Object Pattern, lad os forestille os, at vi er nødt til at implementere CustomerDao interface defineret som følger:

offentlig grænseflade CustomerDao {Collection findByNameAndLastname (String name, String lastname); Kundens getById (lang id); }

De fleste af udviklerne ville Vend tilbage Collections.emptyList () fra findByNameAndLastname () hvis ingen af ​​kunderne stemmer overens de angivne søgekriterier. Dette er et meget godt eksempel på at følge Null Object Pattern.

I modsætning hertil er fåById () skal returnere kunden med det givne id. En person, der kalder denne metode, forventer at få den specifikke kundeenhed. Hvis der ikke findes en sådan kunde, skal vi udtrykkeligt returnere nul for at signalere, at der er noget galt med det angivne id.

Som med alle andre mønstre, Vi er nødt til at overveje vores specifikke brugssag, inden vi blindt implementerer Null Object Pattern. Ellers kan vi utilsigtet introducere nogle fejl i vores kode, som det vil være svært at finde.

6. Konklusion

I denne artikel lærte vi, hvad Null Object Pattern er, og hvornår vi kan bruge det. Vi implementerede også et simpelt eksempel på designmønsteret.

Som normalt er alle kodeeksempler tilgængelige på GitHub.