Прынцып адзінай адказнасці

З Вікіпедыі, свабоднай энцыклапедыі

Прынцып адзінай адказнасці (SRP) — гэта прынцып камп’ютарнага праграмавання, які абвяшчае, што «модуль павінен несці адказнасць перад адным і толькі адным актарам»[1]. Тэрмін актар абазначае групу якая патрабуе змены ў модулі. Гэта група можа складаецца з аднаго або некалькіх зацікаўленых бакоў або карыстальнікаў.

Роберт С. Марцін, стваральнік тэрміна, сфармуляваў прынцып так: «У класа павінна быць толькі адна прычына для змены»[2]. Слова «прычына» часта вызывае блытаніну, таму ён удакладняе, што «прынцып тычыцца людзей»[3]. Заўважым, што маюцца на ўвазе не асобныя людзі, а ролі або актары. Напрыклад, роля бухгалтара адрозніваецца ад ролі адміністратара базы даных, хоць гэта і можа быць адзін і той жа чалавек. Такім чынам, адзін модуль павінен адказваць за адну ролю.

Гісторыя[правіць | правіць зыходнік]

Тэрмін быў уведзены Робертам С. Марцінам у яго артыкуле «Прынцыпы ААП» як адзін з «Прынцыпаў аб’ектна-арыентаванага праектавання»[4]. Гэтыя прынцыпы сталі папулярнымі дзякуючы яго кнізе «Гнуткая распрацоўка праграмнага забеспячэння, прынцыпы, шаблоны і практыкі» 2003 года[5]. Ідэя адзінай адказнасці (SRP) заснавана на прынцыпе згуртаванасці. Прынцып згуртаванасці быў апісаны Томам ДэМарка ў яго кнізе «Структурны аналіз і спецыфікацыя сістэмы» і Мэйлірам Пэйджам-Джонсам у «Практычным кіраўніцтве па распрацоўцы структураваных сістэм». У 2014 годзе Марцін апублікаваў паведамленне ў блогу пад назвай «Прынцып адзінай адказнасці» з мэтай растлумачыць, што маецца на ўвазе пад фразай «прычына змены».[6]

Прыклад[правіць | правіць зыходнік]

Марцін вызначае адказнасць як прычыну для змены і робіць выснову, што клас або модуль павінен мець адну і толькі адну прычыну для змены.

У якасці прыкладу разгледзім модуль, які складае і друкуе справаздачу. Такі модуль можа быць зменены па дзвюх прычынах:

  1. можа змяніцца змест справаздачы
  2. можа змяніцца фармат справаздачы

Гэтыя дзве змены адбываюцца па розных прычынах. Прынцып адзінай адказнасці сцвярджае, што гэтыя два аспекты праблемы з’яўляюцца дзвюма асобнымі адказнасцямі. І, у адпаведнасці з прынцыпам SRP, павінны знаходзіцца ў асобных класах або модулях. Было б дрэнна спалучаць дзве рэчы, якія змяняюцца па розных прычынах у розны час.

Прычына, па якой важна трымаць клас сканцэнтраваным на адной праблеме, заключаецца ў тым, што гэта робіць клас больш трывалым. Працягваючы папярэдні прыклад, уявім, што працэс складання і друку справаздачы з’яўляюцца часткай аднаго класа. У гэтым выпадку, калі ёсць змены ў працэсе складання справаздачы, існуе большая небяспека таго, што код друку можа зламацца.

Крыніцы[правіць | правіць зыходнік]

  1. Martin, Robert C. (2018). Clean architecture : a craftsman's guide to software structure and design. Boston. ISBN 978-0-13-449432-6. OCLC 1003645626.
  2. Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445.
  3. Martin, Robert C. (2014). "The Single Responsibility Principle". The Clean Code Blog.
  4. Robert C. Martin (2018). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. ISBN 978-0-13-449416-6.
  5. Martin, Robert C. (2005). "The Principles of OOD". butunclebob.com.
  6. https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Спасылкі[правіць | правіць зыходнік]