Servant (Služobník)
Návrhový vzor Služobník použijeme vtedy, ak chceme niekoľkých triedam pridať ďalšie funkčnosť, bez toho aby sme zasahovali do ich rozhrania. Služobník nám tak pridáva novú funkčnosť, bez toho aby musel byť v danej triede. Jedná sa o idiom. Nie je teda zaradený medzi "tie pravé" návrhové vzory z <acronym title="Gang of Four">GoF.</acronym> Jeho použitie je ale niekedy veľmi užitočné.
Motivácia
Niekedy sa môžeme dostať do situácie, kedy máme určitú skupinu tried, ktorým chceme pridať ďalšie funkčnosť. Priamu implementáciou by sme ale túto funkčnosť museli skopírovať do každej z nich, čo je pri programovaní popr. rozširovanie aplikácie diaľnice do pekel (nehľadiac na to, že tým porušujeme princíp <acronym title="Do not Repeat Yourself - Neopakuj sa!">DRY).</acronym> Ďalšou možnosťou je samozrejme definovať spoločného predka, ale to tiež nedá vždy urobiť. Funkčnosť, o ktorú chceme triedy rozšíriť, s nimi totiž nemusí vôbec súvisieť. Triedy by sa potom museli starať o viac vecí naraz (princíp <acronym title="Single Responsibility Principle - jedna entita zodpovedá práve za jeden úlohu">SRP,</acronym> ktorý je tiež veľmi dôležitý pri návrhu). V takom prípade môžeme funkčnosť vyčleniť do samostatnej triedy (tzv. Služobník).
Vzor
Jedná sa vlastne o takú prepravku na metódy, ktoré obsluhujú inštancie určité skupiny tried. Služobník je samostatná trieda, ktorá obsahuje metódy manipulujúci s inštanciami pôvodných tried (ďalej len ako sluha). Ak budeme chcieť po nejakej obsluhované triede splniť určitú úlohu (napríklad plynulý posun - animáciu), požiadame o túto úlohu sluhu, ktorému odovzdáme práve inštanciu obsluhované triedy. Služobník potom bude s obsluhovanými triedami komunikovať cez nejaké rozhranie (napr. IMovable - v tomto prípade poskytne metódy ako SetPoint a getPoint, aby sme mohli objekt postupne posúvať). Toto rozhranie musíme pochopiteľne tiež implementovať všetkým triedam, s ktorými bude služobník pracovať.
V podstate môžeme vzor Služobník implementovať dvoma spôsobmi: obsluhovaná trieda nemusí o sluhovi vedieť vôbec nič (ukážka - UML diagram 1), alebo naopak, o sluhovi nemusí nič vedieť užívateľ (ukážka - UML diagram 2). V prvom prípade sa pýtame na určitú úlohu priamo obsluhované triedy cez sluhu, ktorému musíme odovzdať inštanciu obsluhované triedy. V tom druhom o nejakom služobníkovi nemusíme nič vedieť. Po opýtaní na určitú úlohu obsluhované triedy si zavolá metódu služobníka sama obsluhovaná metóda. Obe tieto implementácie sú správne. Záleží na vás, ako budete chcieť služobníka implementovať.
Operácia požaduje užívateľ od samotného služobníka
Operácia požaduje užívateľ od obsluhované triedy
Ako môžeme vyčítať z diagramu, každá trieda, ktorá chce poskytnúť
služby, implementuje rozhranie IObsluhovatelný. Služobník potom
pracuje iba s týmto rozhraním. Ak by sme chceli služobníka pre animáciu,
budeme zrejme potrebovať už spomínané metódy getPoint() a
setPoint(Point), vďaka ktorým by sme mohli posúvať obsluhovanú
inštancií (resp. Nejaký graficky objekt, ktorý predstavuje). Príklady sa
líšia vo väzbe používateľa na služobníka. Kým v prvom prípade má
užívateľ k služobníkovi priamu väzbu, v druhom je volaný až
obsluhovanými triedami a užívateľ na neho teda nemá priamu väzbu, čo sa
dá využiť napríklad pre zapuzdrenie.
Záver
Vzor Služobník použijeme vtedy, Chem chcete pridať skupine tried nejakú schopnosť a nechceme ju pritom implementovať do pôvodnej triedy. Je realizovaný samostatnou triedou, ktorá manipuluje s obsluhovanú inštancií (resp. S jej rozhraním). Jedná sa o idiom a nie je teda v GoF.
