Зацепление (программирование): различия между версиями
[непроверенная версия] | [отпатрулированная версия] |
Лиманцев (обсуждение | вклад) →Преамбула: внутренние ссылки |
|||
(не показано 29 промежуточных версий 16 участников) | |||
Строка 1: | Строка 1: | ||
{{другое значение|У терминов «[[Зацепление]]» и «[[Сцепление]]» есть также другие значения}} |
|||
''' |
'''Зацепление'''<ref>''Кравченко А. К., Афанасьева И. В.'' [https://cyberleninka.ru/article/n/vliyanie-izmeneniya-zatsepleniya-i-svyaznosti-na-slozhnost-koda-i-ego-bystrodeystvie-v-razrabotke-programmnogo-obespecheniya Влияние изменения зацепления и связности на сложность кода и его быстродействие в разработке программного обеспечения] // Радиоэлектроника и информатика, 2016, № 3, с. 9—12.</ref>, '''сцепление''', '''связанность''', '''сопряжение'''{{sfn|Макконнелл|2010}} ({{lang-en|coupling}}) — способ и степень взаимозависимости между [[Модуль (программирование)|программными модулями]]<ref name="ISO_24765">{{Cite web |url=https://standards.iso.org/ittf/PubliclyAvailableStandards/c071952_ISO_IEC_IEEE_24765_2017.zip |title=ISO/IEC/IEEE 24765-2017 Systems and software engineering — Vocabulary |access-date=2021-11-01 |archive-date=2022-03-31 |archive-url=https://web.archive.org/web/20220331214951/https://standards.iso.org/ittf/PubliclyAvailableStandards/c071952_ISO_IEC_IEEE_24765_2017.zip |deadlink=no }}</ref>; сила взаимосвязей между модулями<ref name="ISO_TR_19759">ISO/IEC TR 19759:2005, Software Engineering — Guide to the Software Engineering Body of Knowledge (SWEBOK)</ref>; мера того, насколько взаимозависимы разные подпрограммы или модули<ref name="ISO_24765"/>. |
||
Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы, и, когда |
Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Например, при изменении требований к одному модулю понадобится модификация также всех зависимых от него. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы, и, когда оно комбинируется с сильной [[Связность (программирование)|связностью]], соответствует общим показателям хорошей читаемости и сопровождаемости. |
||
[[Метрика программного обеспечения|Метрики]] зацепления и связности были придуманы [[:en:Larry Constantine|Ларри Константином]], изначальным разработчиком структурного проектирования<ref>W. Stevens, G. Myers, L. Constantine, «Structured Design», IBM Systems Journal, 13 (2), 115—139, 1974.</ref>, который был также ранним сторонником таких концепций (см. также [[ |
[[Метрика программного обеспечения|Метрики]] зацепления и связности были придуманы [[:en:Larry Constantine|Ларри Константином]], изначальным разработчиком структурного проектирования<ref>W. Stevens, G. Myers, L. Constantine, «Structured Design», IBM Systems Journal, 13 (2), 115—139, 1974.</ref>, который был также ранним сторонником таких концепций (см. также [[Метод структурированного системного анализа и проектирования|SSADM]]). |
||
Слабое зацепление является одним из [[шаблон проектирования|шаблонов]] [[GRASP]] [[Ларман, |
Слабое зацепление является одним из [[шаблон проектирования|шаблонов]] [[GRASP]] [[Ларман, Крэг|Крэйга Лармана]]<ref>{{книга |автор=Philip A. Laplante, Philip A. Laplante |заглавие=What Every Engineer Should Know about Software Engineering |издательство=CRC Press |год=2007 |pages=105–106 |isbn=978-1-4200-0674-2}}</ref>. |
||
| автор = Philip A. Laplante, Philip A. Laplante |
|||
| заглавие = What Every Engineer Should Know about Software Engineering |
|||
| издательство = CRC Press |
|||
| год = 2007 |
|||
| pages = 105–106 |
|||
| isbn = 978-1-4200-0674-2 |
|||
}}</ref>. |
|||
== Типы зацепления == |
== Типы зацепления == |
||
[[Файл:CouplingVsCohesion.svg|thumb|300px|right|Связность и зацепление модулей]] |
[[Файл:CouplingVsCohesion.svg|thumb|300px|right|Связность и зацепление модулей:<br/> a) '''правильно''' (слабое зацепление, сильная связность), b) '''неправильно''' (сильное зацепление, слабая связность)]] |
||
Типы зацепления, согласно стандарту ISO/IEC/IEEE 24765 |
Типы зацепления, согласно стандарту ISO/IEC/IEEE 24765, включают:<ref name="ISO_24765"/> |
||
* зацепление по общей области ({{lang- |
* '''зацепление по общей области''' ({{lang-en2|common-environment coupling, common coupling}}) — два программных модуля совместно используют общую область данных; |
||
* зацепление по содержимому ({{lang- |
* '''зацепление по содержимому''' ({{lang-en2|content coupling}}) — некоторые или все программные модули включены в некоторый модуль как составные части; |
||
* зацепление по управлению ({{lang- |
* '''зацепление по управлению''' ({{lang-en2|control coupling}}) — один программный модуль обменивается данными с другим модулем с явной целью повлиять на его последующее выполнение; |
||
* зацепление по данным ({{lang- |
* '''зацепление по данным''' ({{lang-en2|data coupling, input-output coupling}}) — выходные данные одного программного модуля служат входными данными другого модуля; |
||
* смешанное зацепление ({{lang- |
* '''смешанное зацепление''' ({{lang-en2|hybrid coupling}}) — различные подмножества значений некоторого элемента данных используются в нескольких программных модулях для разных и несвязанных целей; |
||
* патологическое зацепление ({{lang- |
* '''патологическое зацепление''' ({{lang-en2|pathological coupling}}) — один программный модуль зависит от деталей внутренней реализации другого модуля или влияет на них. |
||
<!-- |
|||
{{↕}} |
|||
; Зацепление по общей области: Тип зацепления, при котором два программных модуля совместно используют общую область данных. |
|||
; Зацепление по общей области |
|||
; Зацепление по содержимому: Тип зацепления, при котором некоторые или все программные модули включены в некоторый модуль как составные части. |
|||
: Тип зацепления, |
|||
; Зацепление по управлению: Тип зацепления, при котором один программный модуль обменивается данными с другим модулем с явной целью повлиять на его последующее выполнение. |
|||
; Зацепление по содержимому |
|||
; Зацепление по данным: Тип зацепления, при котором выходные данные одного программного модуля служат входными данными другого модуля. |
|||
: Тип зацепления,. |
|||
; Смешанное зацепление: Тип зацепления, при котором различные подмножества значений некоторого элемента данных используются в нескольких программных модулях для разных и несвязанных целей. |
|||
; Зацепление по управлению |
|||
; Патологическое зацепление: Тип зацепления, при котором один программный модуль зависит от деталей внутренней реализации другого модуля или влияет на них. |
|||
: Тип зацепления,. |
|||
; Зацепление по данным |
|||
: Тип зацепления,. |
|||
; Смешанное зацепление |
|||
: Тип зацепления,. |
|||
; Патологическое зацепление |
|||
: Тип зацепления,. |
|||
--> |
|||
== Методы уменьшения зацепления == |
== Методы уменьшения зацепления == |
||
Существуют различные методы уменьшения зацепления ({{lang-en|decoupling}}). Как правило, они описаны в виде [[Шаблон проектирования|шаблонов проектирования]]. Одним из ключевых методов является [[инверсия управления]], и, в частности, [[внедрение зависимости]]. |
Существуют различные методы уменьшения зацепления ({{lang-en|decoupling}}). Как правило, они описаны в виде [[Шаблон проектирования|шаблонов проектирования]]. Одним из ключевых методов является [[инверсия управления]], и, в частности, [[внедрение зависимости]]. |
||
Снизить зацепление также помогает использование многослойной архитектуры приложений, например [[Model-View-Controller]], [[Model-View-Presenter]], [[Model-View-ViewModel]] и |
Снизить зацепление также помогает использование многослойной архитектуры приложений, например [[Model-View-Controller]], [[Model-View-Presenter]], [[Model-View-ViewModel]] и т. п. |
||
== См. также == |
== См. также == |
||
Строка 45: | Строка 47: | ||
== Литература == |
== Литература == |
||
{{книга |
* {{книга |
||
|автор = [[Макконнелл, Стив]] |
|автор = [[Макконнелл, Стив]] |
||
|заглавие = Совершенный код |
|заглавие = Совершенный код |
||
Строка 60: | Строка 62: | ||
|ref = Макконнелл |
|ref = Макконнелл |
||
}} |
}} |
||
{{Качество программного обеспечения}} |
|||
{{Computer-sci-stub}} |
|||
{{Нет полных библиографических описаний}} |
|||
[[Категория:Исследование программ]] |
[[Категория:Исследование программ]] |
Текущая версия от 07:41, 6 мая 2024
Зацепление[1], сцепление, связанность, сопряжение[2] (англ. coupling) — способ и степень взаимозависимости между программными модулями[3]; сила взаимосвязей между модулями[4]; мера того, насколько взаимозависимы разные подпрограммы или модули[3].
Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Например, при изменении требований к одному модулю понадобится модификация также всех зависимых от него. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы, и, когда оно комбинируется с сильной связностью, соответствует общим показателям хорошей читаемости и сопровождаемости.
Метрики зацепления и связности были придуманы Ларри Константином, изначальным разработчиком структурного проектирования[5], который был также ранним сторонником таких концепций (см. также SSADM).
Слабое зацепление является одним из шаблонов GRASP Крэйга Лармана[6].
Типы зацепления
[править | править код]Типы зацепления, согласно стандарту ISO/IEC/IEEE 24765, включают:[3]
- зацепление по общей области (common-environment coupling, common coupling) — два программных модуля совместно используют общую область данных;
- зацепление по содержимому (content coupling) — некоторые или все программные модули включены в некоторый модуль как составные части;
- зацепление по управлению (control coupling) — один программный модуль обменивается данными с другим модулем с явной целью повлиять на его последующее выполнение;
- зацепление по данным (data coupling, input-output coupling) — выходные данные одного программного модуля служат входными данными другого модуля;
- смешанное зацепление (hybrid coupling) — различные подмножества значений некоторого элемента данных используются в нескольких программных модулях для разных и несвязанных целей;
- патологическое зацепление (pathological coupling) — один программный модуль зависит от деталей внутренней реализации другого модуля или влияет на них.
Методы уменьшения зацепления
[править | править код]Существуют различные методы уменьшения зацепления (англ. decoupling). Как правило, они описаны в виде шаблонов проектирования. Одним из ключевых методов является инверсия управления, и, в частности, внедрение зависимости.
Снизить зацепление также помогает использование многослойной архитектуры приложений, например Model-View-Controller, Model-View-Presenter, Model-View-ViewModel и т. п.
См. также
[править | править код]Примечания
[править | править код]- ↑ Кравченко А. К., Афанасьева И. В. Влияние изменения зацепления и связности на сложность кода и его быстродействие в разработке программного обеспечения // Радиоэлектроника и информатика, 2016, № 3, с. 9—12.
- ↑ Макконнелл, 2010.
- ↑ 1 2 3 ISO/IEC/IEEE 24765-2017 Systems and software engineering — Vocabulary . Дата обращения: 1 ноября 2021. Архивировано 31 марта 2022 года.
- ↑ ISO/IEC TR 19759:2005, Software Engineering — Guide to the Software Engineering Body of Knowledge (SWEBOK)
- ↑ W. Stevens, G. Myers, L. Constantine, «Structured Design», IBM Systems Journal, 13 (2), 115—139, 1974.
- ↑ Philip A. Laplante, Philip A. Laplante. What Every Engineer Should Know about Software Engineering. — CRC Press, 2007. — P. 105–106. — ISBN 978-1-4200-0674-2.
Литература
[править | править код]- Макконнелл, Стив. Совершенный код = Code Complete. — 2-е издание. — М.: Русская редакция, 2010. — С. 139. — 896 с. — (Мастер-класс). — ISBN 978-5-7502-0064-1.