Mönster för servicelokalisering

Tjänstelokaliseringsmönstret är ett designmönster som används i mjukvaruutveckling för att kapsla in de processer som är involverade i att erhålla en tjänst med ett starkt abstraktionsskikt . Detta mönster använder ett centralt register känt som "tjänstlokalisatorn", som på begäran returnerar den information som krävs för att utföra en viss uppgift. Förespråkare av mönstret säger att tillvägagångssättet förenklar komponentbaserade applikationer där alla beroenden listas rent i början av hela applikationsdesignen, vilket gör traditionell beroendeinjektion till ett mer komplext sätt att koppla ihop objekt. Kritiker av mönstret hävdar att det är ett antimönster som döljer beroenden och gör programvara svårare att testa.

Fördelar

• "Service locator" kan fungera som en enkel körtidslänkare . Detta gör att kod kan läggas till vid körning utan att kompilera om programmet, och i vissa fall utan att ens behöva starta om den.
• Applikationer kan optimera sig själva under körning genom att selektivt lägga till och ta bort objekt från tjänstelokaliseringen. Till exempel kan en applikation upptäcka att den har ett bättre bibliotek för att läsa JPG-bilder än standard, och ändra registret därefter.
• Stora delar av ett bibliotek eller en applikation kan separeras helt . Den enda länken mellan dem blir registret.
• En applikation kan använda flera strukturerade tjänstelokatorer avsedda för speciell funktionalitet/testning. Service locator kräver inte en enda statisk klass per process.
• Lösningen kan vara enklare med service locator (vs. beroendeinjektion) i applikationer med välstrukturerad komponent/tjänstdesign. I dessa fall kan nackdelarna faktiskt betraktas som en fördel (t.ex. inget behov av att tillhandahålla olika beroenden till varje klass och underhålla beroendekonfigurationer).

Nackdelar

• Registret döljer klassens beroenden, vilket orsakar körtidsfel istället för kompileringsfel när beroenden saknas (liknande att använda beroendeinjektion ). Men varje bibliotek är kompilerat, bara upptäckten av den konkreta klassen kanske inte hittas och orsakar ett fel, det är mer ett distributionsproblem än ett Service Locator-problem.
• Registret gör koden svårare att testa eftersom alla tester måste interagera med samma globala tjänstlokaliseringsklass för att ställa in falska beroenden för en klass som testas. Detta kan dock enkelt övervinnas genom att injicera applikationsklasser med ett enda tjänstelokaliseringsgränssnitt. Simulator kan implementeras för att simulera varje gränssnitt som tillhandahålls av tjänstelokaliseringen, så det är enkelt att byta ut den verkliga implementeringen med en simulator.

Se även

• Beroendeinjektion
• Beroendeinversionsprincip
• Java-namngivning och kataloggränssnitt

externa länkar

• Exempelkod
• In Defense of Service Locator
• Spelprogrammeringsmönster: Service Locator
• Dependens In Disguise
• Software Engineering Myter och sanningar