“S” apzīmē - The Single Responsibility Principle (SRP).
The Single Responsibility Principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
Tātad šis pagalvojums definē to, ka klasei ir ieteicams nodarboties un risināt tikai kādu konkrētu noteiktu problēmu. Jo vairāk atbildības uzņemas klase, jo lielāka varbūtība, ka pie izmaiņām, tiks ieviestas un izstrādātas jaunas kļūdas.
Zemāk ir dots pavisam triviāls piemērs, lai uzskatamāk nodemonstrētu Single Responsibility principu. Piemērs ir no apdrošināšanas biznesa, bet tas nekas :)
Piemēram, ir sistēmā definēts apdrošināšanas pieteikums (InsuranceApplication). Klase pēc savas būtības risina daudzas problēmas, piemēram:
- apdrošināšanas pieteikums ir spējīgs sevi novalidēt jeb pārbaudīt datu pareizīgumu;
- māk izdot polisi;
- un attiecīgi māk arī pabrīdināt klientu par to, ka polise ir sekmīgi izdota.
Pieņemsim, ka klienta pabrīdināšana nepieciešama tikai internetā (sistēmas komponente – Web Sales) izdotajām polisēm. Klašu diagramma attēlota zemāk.
Tradicionālajā veidā mēs definētu izdošanas metodi (Issue), kurā savukārt būtu iestrādāta loģika, kas pārbauda, no kuras sistēmas tiek izdota polise, un attiecīgi iekļautu klienta pabrīdināšanas (NotifyClient) metodes izsaukumu savā ķēdītē vai arī gluži pretēji - nē. Zemāk dotais piemērs ir tikai ar placeholderiem, lai lieki nepiesārņotu ēteru..
public class InsuranceApplication
{
public int SourceSystem { get; set; }
public void Issue()
{
Validate();
// issue logic here
if (SourceSystem == 1) // 1 - web sales
{
NotifyClient();
}
}
public void NotifyClient()
{
}
public void Validate()
{
}
}
Viena no pamat kļūdām, kas pieļauta šajā koda uzbūvē, ir, InsuranceApplication klase zina pārāk daudz jeb klasei ir jāatbild par pārāk daudzām lietām – apdrošināšanas pieteikums zina, no kādas sistēmas šī konkrētā polise ir bijusi pieteikta un attiecīgi arī reaģē uz to izdošanas brīdī – informējot klientu par jauno polisi tikai un vienīgi interneta polises gadījumā.
Jaunā klašu diagramma ievērojot SRP principu būtu apmēram šāda:
Tātad:
- Izveidojam vienu bāzes (abstraktu vai arī virtuālu) klasi, kas reglamentē kopējo jeb generic izskatu apdrošināšanas polises pieteikuma klasei, kas sastāv no validācijas un izdošanas metodēm.
- Būtu jānodefinē divas apdrošināšanas pieteikuma apakšklases, kuras realizētu katrai no sistēmām nepieciešamo funkcionalitāti.
- Tikai polises interneta pieteikuma apakšklasē, būtu realizēta klienta pabrīdināšanas funkcionalitāte, jo tā nav nepieciešama BackOffice sistēmā.
- TODO: nepieciešams būtu arī atdalīt klienta pabrīdināšanas komponenti no tiešas izmantošanas interneta polises pieteikuma klasē (gaidi burtu “I” no S.O.L.I.D. grupas), bet to mēs izdarīsim vēlāk.
NB! Jāpiemin, ka SRP princips ļoti noder gadījumos, kad mainot kādu no funkcionalitātēm jeb atbildībām, ko uzņemas realizēt klase, nav nepieciešams pārkompilēt arī visas tieši saistošās sistēmas. Piemēram, pirmajā variantā, kad netika ievērots vēl SRP princips, mainot klienta pabrīdināšanas mehānismu (piemēram, no elektroniskā pasta uz SMS) nāktos pārkompilēt arī backoffice sistēmas komponentes, kurām loģiski nav nekāda sakara ar klienta pabrīdināšanas jeb notifikācijas sistēmas komponenti, kas tiek izmantota tikai interneta polisēm.
Ko tad patiešām dod šī principa ievērošana:
- Zemākas pakāpes atkarību (angl. coupling) starp sistēmas komponentēm un augstākas pakāpes saistība (angl. cohesion) sistēmas moduļa vai komponentes iekšienē.
- Samazinās if un switch nosacījumu skaitu izejas kodā, jo katra no atbildībām tiek veikta un risināta attiecīgi citā vietā.
- prasību izmaiņas ietekmē pēc iespējas mazāku apgabalu sistēmā, kā rezultātā samazināsies potenciālo problēmu skaits, kas var tikt saražots labojot kādu no problēmām, ko klase risina.
- Vairākas mazas klases ar mazāku jeb specifiskāku atbildību nodrošina elastīgāku sistēmas uzbūvi.
Šis OO dizainēšanas princips ir pavisam vienkāršs un saprotams un nav nekāda raķešu zinātne, tomēr, jāsaka, ka esmu secinājis, ka arī cilvēkiem ar šo dizainu visvairāk problēmas sagādā to atpazīt kodā un pareizajās vietās pielietot.
Cerams, ka noderēs!
Pārējie raksti SOLID sērijā: