Hoppa till innehållet

Single responsibility principle

Från Wikipedia

Single-responsibility principle ( SRP ) är en datorprogrammeringsprincip som säger att "En modul bör vara ansvarig inför en, och endast en, aktör." [1] Termen aktör syftar här på en grupp (som kan bestå av en eller flera intressenter eller användare) som kräver en förändring av modulen.

Robert C. Martin, upphovsmannen till termen, uttrycker principen som: "En klass bör bara ha en anledning att förändras". [2] Då det uppstod förvirring kring uttrycket "anledning" klargjorde han senare sin tolkning i ett blogginlägg med titeln "The Single Responsibility Principle", där han nämnde Separation of Concerns och uttryckte att "Ett annat sätt att formulera Single Responsibility Principle är: Samla ihop saker som förändras av samma anledningar. Separera de saker som förändras av olika anledningar."[3] I några av sina föredrag hävdar han också att principen i synnerhet handlar om roller eller aktörer. Till exempel skiljer sig rollen som revisor från rollen som databasadministratör, även om de kan vara samma person. Därför bör varje modul ansvara för varje roll. [4]

Termen introducerades av Robert C. Martin i hans artikel "The Principles of OOD" som en del av hans Principles of Object Oriented Design,[5] kända från hans bok Agile Software Development, Principles, Patterns, and Practices som kom ut 2003. [6] Martin beskrev principen som baserad på principen om sammanhållning(cohesion), som beskrivs i Tom DeMarcos bok Structured Analysis and System Specification, [7] samt i Meilir Page-Jones bok The Practical Guide to Structured Systems Design . [8] Martin publicerade 2014 ett blogginlägg med titeln "The Single Responsibility Principle" med syfte att förtydliga vad som menades med frasen "anledning till förändring." [1]

Martin definierar ett ansvar som en anledning till förändring, och drar slutsatsen att en klass eller modul bör ha en, och endast en, anledning att ändras (t.ex. skrivas om).

Tänk dig till exempel en modul som sammanställer och skriver ut en rapport. Föreställ dig att en sådan modul kan ändras av två skäl: Antingen kan innehållet i rapporten ändras, eller så kan formatet på rapporten ändras. Dessa två förändringar sker av olika orsaker. Single Responsibility Principle säger att dessa två aspekter av problemet egentligen är två separata ansvarsområden och bör därför vara i separata klasser eller moduler. Det skulle vara en dålig design att koppla två saker som förändras av olika anledningar vid olika tidpunkter.

Grunden till att det är viktigt att hålla en klass fokuserad på ett enda problem är att det gör klassen mer robust. I det föregående exemplet, om det sker en förändring i processen för rapportsammanställning, finns det en större risk att koden för utskrift går sönder om den är en del av samma klass.

Externa länkar

[redigera | redigera wikitext]