stringtranslate.com

Принцип единой ответственности

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

Роберт С. Мартин , создатель термина, выразил принцип следующим образом: «У класса должна быть только одна причина для изменения». [2] Из-за путаницы вокруг слова «причина» он позже разъяснил его значение в сообщении в блоге под названием «Принцип единой ответственности», в котором он упомянул разделение интересов и заявил, что «Другая формулировка принципа единой ответственности: Соберите вместе вещи, которые изменяются по одним и тем же причинам. Разделите те вещи, которые изменяются по разным причинам». [3] В некоторых своих выступлениях он также утверждает, что принцип, в частности, касается ролей или действующих лиц. Например, хотя они могут быть одним и тем же человеком, роль бухгалтера отличается от роли администратора базы данных. Следовательно, каждый модуль должен отвечать за каждую роль. [4]

История

Термин был введен Робертом С. Мартином в его статье «Принципы OOD» как часть его Принципов объектно-ориентированного проектирования [5] , ставших популярными благодаря его книге 2003 года «Гибкая разработка программного обеспечения, принципы, шаблоны и практики» . [6] Мартин описал его как основанный на принципе связности , как описано Томом ДеМарко в его книге «Структурный анализ и системная спецификация» [ 7] и Мейлиром Пейдж-Джонсом в «Практическом руководстве по проектированию структурированных систем » . [8] В 2014 году Мартин опубликовал запись в блоге под названием «Принцип единой ответственности» с целью прояснить, что подразумевается под фразой «причина для изменений». [1]

Пример

Мартин определяет ответственность как причину для изменения и приходит к выводу, что класс или модуль должен иметь одну и только одну причину для изменения (например, переписывания).

В качестве примера рассмотрим модуль, который компилирует и печатает отчет. Представьте, что такой модуль может быть изменен по двум причинам. Во-первых, может измениться содержание отчета. Во-вторых, может измениться формат отчета. Эти две вещи меняются по разным причинам. Принцип единой ответственности гласит, что эти два аспекта проблемы на самом деле являются двумя отдельными обязанностями и, следовательно, должны находиться в отдельных классах или модулях. Было бы плохой конструкцией объединять две вещи, которые изменяются по разным причинам в разное время.

Причина, по которой важно сохранять класс сосредоточенным на одной проблеме, заключается в том, что это делает класс более надежным. Продолжая предыдущий пример, если есть изменение в процессе компиляции отчета, есть большая опасность того, что код печати сломается, если он является частью того же класса.

Смотрите также

Ссылки

  1. ^ Мартин, Роберт С. (2018). Чистая архитектура: руководство мастера по структуре и дизайну программного обеспечения. Бостон. ISBN 978-0-13-449432-6. OCLC  1003645626.{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )
  2. ^ Мартин, Роберт С. (2003). Гибкая разработка программного обеспечения, принципы, шаблоны и практики. Prentice Hall. стр. 95. ISBN 978-0135974445.
  3. ^ Мартин, Роберт С. (2014). «Принцип единой ответственности». Блог The Clean Code .
  4. ^ Роберт С. Мартин (2018). Чистая архитектура: руководство мастера по структуре и дизайну программного обеспечения. Prentice Hall. ISBN 978-0-13-449416-6.
  5. ^ Мартин, Роберт С. (2005). «Принципы OOD». butunclebob.com .
  6. ↑ Мартин 2003, стр. 95–98.
  7. ^ ДеМарко, Том. (1979). Структурный анализ и спецификация систем . Prentice Hall . ISBN 0-13-854380-1.
  8. ^ Page-Jones, Meilir (1988). Практическое руководство по проектированию структурированных систем . Yourdon Press Computing Series. стр. 82. ISBN 978-8120314825.

Внешние ссылки