Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Регистрация Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > Good

Оценить эту запись

Loose coupling

Запись от artcraft размещена 10.01.2012 в 23:21
Обновил(-а) artcraft 11.01.2012 в 21:55

Если код программы не разделять на отдельные модули то он становится похожим на тарелку спагетти - извилистым и запутанным, такая программа может очень хорошо работать, но вот чинить её или добавлять новые функции в такую кашу занятие неблагодарное.

Тут на помощь приходит принцип "разделяй и властвуй". (Separation of Concerns SoC)

Гораздо удобнее иметь дело с кодом который выглядит как лего - набор отдельных модулей которые соединены друг с другом штекерами, это даёт ряд преимуществ:
  • Ремонтопригодность (Maintainability)
    изменение одного модуля не потребуют изменения других модулей

  • Заменимость модулей (Swappability)
    модуль легко заменить на другой, важно только чтобы пазы на деталях совпали

  • Масштабируемость (Scalability)
    добавляя новый модуль не нужно вникать во внутреннее устройство других модулей

  • Возможность тестирования (Unit Testing)
    модуль можно отсоединить от всех остальных и протестировать / починить

Ценой за эти удобства является необходимость писать больше кода (тратить больше времени) описывающего взаимосвязи модулей.

Поэтому, при проектировании крупных приложений, на вопрос "Спагетти или Модульность?" ответ очевиден.

Звучит всё замечательно, но есть подвох, очень часто оказывается, что модулю для выполнения своих функций нужно уметь общаться с большим количеством других модулей 5-10-20, причём расположенных не только по соседству, для общения с каждым отдельным модулем мы добавляем новый разъём и начинаем использовать шнуры для связи с дальними модулями. Спустя некоторые время оказывается, что мы опять имеем дело с тарелкой спагетти, только на этот раз это узел из шнуров, связывающих независимые модули.

Как же не запутаться в проводах?
Об этом я и хочу написать.

Для начал термины:
Зависимость (dependency) – знание одного модуля о другом

Связанность (coupling) — характеристика взаимосвязи модуля с другими модулями. Это степень, в которой каждый программный модуль зависит от других модулей.

Decoupling противоположность связанности — степень независимости модулей друг от друга.

Чем слабее связанность, тем лучше, тем легче понимать/расширять/чинить программу.

Итак, что может ослабить связанность модулей:

1 Создание зависимостей

Крайне важно то, как создаётся зависимость, то откуда зависящий модуль раздобывает ссылку на модуль, от которого он зависит. (Перечислять способы создания зависимостей и сравнивать их, тянет на тему для отдельной статьи, поэтому я не буду сейчас вдаваться в подробности). Самый гибкий подход это избавить модуль от необходимости заботится об этом вообще. Такой подход называется инверсия контроля (inversion of control, IoC). Один из способов внедрить принцип инверсии контроля, это использовать паттерн Dependency Injection. Инвертируется процесс создания зависимости, вместо самого модуля его (процесс) контролирует кто-то извне – зависимость «впрыскивют» модулю.
Используя метафору с проводами - модуль не должен думать о проводах, сборкой конструктора занимается кто-то другой, а не сами детали.

2 Количество зависимостей

Вполне очевидно, что чем меньше зависимостей, тем ниже степень связанности. Уменьшить их количество можно сужая обязанности каждого модуля, разделяя крупные модули на несколько мелких ( руководствуясь принципом High Cohesion ). С другой стороны, следует учитывать, что это палка о двух концах: чем больше стыков, тем больше кода описывающего связи, поэтому совсем не обязательно рубить приложение в винегрет.

Кроме того можно уменьшить область знаний каждого модуля (Закон Деметры, LoD), например разделив приложение на этажи или зоны и разрешив общение модулей только в пределах соседних зон.

3 Сила зависимостей

Интерфейс ограничивает знание одного модуля о другом.
Например: объекту класса А, умеющему обращаться с интерфейсом IB, можно подсунуть любую из имплементаций этого интерфейса, и он сможет ей управлять, не вникая в то, как именно называется или устроено то, что ему дали.

События или сигналы, это тоже менее жёсткая зависимость.
Отправитель ничего не знает о получателе, рассылка происходит по подписке.


Надеюсь, ничего важного не упустил.
Но если упустил, то буду рад комментариям.
Всего комментариев 20

Комментарии

Старый 10.01.2012 23:29 dimarik вне форума
dimarik
 
Аватар для dimarik
Почему объектно-ориентированное программирование провалилось?

Цитата:
Самый гибкий подход это избавить модуль от необходимости заботится об этом вообще. Такой подход называется инверсия контроля (inversion of control, IoC) или Dependency Injection.
Это вы сами придумали или подсказал кто-то (ссылочку на пруф пожалели)?

В общем, еще один астронавт архитектуры [x]
Обновил(-а) artcraft 11.01.2012 в 00:02
Старый 10.01.2012 23:43 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Почему объектно-ориентированное программирование провалилось?
AS3 объектно-ориентированный язык, поэтому, мне кажется, имея 3000 комментов на этом форуме холливарить по этому поводу поздно
Цитата:
Это вы сами придумали или подсказал кто-то (ссылочку на пруф пожалели)?
Да вот собственно, первое предложение http://ru.wikipedia.org/wiki/%D0%98%...BD%D0%B8%D1%8F

Может со словосочетанием "самый гибкий" я и загнул немного, но буду рад обсудить.

Цитата:
В общем, еще один астронавт архитектуры [x]
не вижу ничего плохого
еще один всё понял [x]
Обновил(-а) artcraft 10.01.2012 в 23:59
Старый 10.01.2012 23:55 GBee вне форума
GBee
 
Аватар для GBee
Статьи об ООП должны сами придерживаться этих принципов. Быть небольшими, описывать конкретные вещи и с примерами.
Старый 11.01.2012 00:01 dimarik вне форума
dimarik
 
Аватар для dimarik
Вы пытаетесь замусорить мозги пересказами. Ну так делайте это технично!
Старый 11.01.2012 00:10 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
Статьи об ООП должны сами придерживаться этих принципов. Быть небольшими, описывать конкретные вещи и с примерами.
а разве собрать в один список, из трёх пунктов, всё что может снизить силу зависимостей, это не конкретная вещь?
Старый 11.01.2012 00:28 dimarik вне форума
dimarik
 
Аватар для dimarik
Я оч уважаю чужие мнения. По вашему мнению
Цитата:
Да вот собственно, первое предложение http://ru.wikipedia.org/wiki/Инверсия_управления
эта ссылка раскрывает суть термина "инверсия контроля"?

Цитата:
Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах.
Эта странная строчка и есть объяснение сущего?

Вы не смогли воспользоваться другим источником? На некоторых уютных бложиках истово минусуют за вики.
Старый 11.01.2012 00:33 GBee вне форума
GBee
 
Аватар для GBee
Цитата:
а разве собрать в один список, из трёх пунктов, всё что может снизить силу зависимостей, это не конкретная вещь?
Цитата:
Если код программы не разделять на отдельные модули то он становится похожим на тарелку спагетти
Цитата:
Перечислять способы создания зависимостей и сравнивать их, тянет на тему для отдельной статьи, поэтому я не буду сейчас вдаваться в подробности
В результате имеем список из трех непонятных пунктов. А так бы 4 статьи подробных с примерами. Без примеров вообще плохо.
Старый 11.01.2012 01:24 СлаваRa вне форума
СлаваRa
 
Аватар для СлаваRa
Цитата:
Вы пытаетесь замусорить мозги пересказами. Ну так делайте это технично!
Как мой тимлид. Он сказал - "Я не буду спорить! Я просто прав,... иначе твои действия, мы признаем как саботаж проекта..."
Старый 11.01.2012 02:53 artcraft вне форума
artcraft
 
Аватар для artcraft
Код:
эта ссылка раскрывает суть термина "инверсия контроля"? Эта странная строчка и есть объяснение сущего?
если там посмотреть англоязычную статью то написано гораздо больше, а еще внизу есть ссылки на as3 библоиотеки с инверсией контроля

Код:
В результате имеем список из трех непонятных пунктов. А так бы 4 статьи подробных с примерами. Без примеров вообще плохо.
я старался написать как можно понятнее, но не ставил целью раскрыть суть каждого из понятий, воспринимайте этот пост как оглавление будущих постов в этом блоге
Старый 11.01.2012 03:00 TanaTiX вне форума
TanaTiX
 
Аватар для TanaTiX
Цитата:
воспринимайте этот пост как оглавление будущих постов в этом блоге
Жду с нетерпением.
Старый 11.01.2012 11:22 Волгоградец вне форума
Волгоградец
 
Аватар для Волгоградец
Все здорово, но без примеров и рисунков вылетает из головы через минуту.
Старый 11.01.2012 13:52 artcraft вне форума
artcraft
 
Аватар для artcraft
Цитата:
эта ссылка раскрывает суть термина "инверсия контроля"?

Цитата:
Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах.
Эта странная строчка и есть объяснение сущего?
Мне кажется, вот это моё предложение довольно ёмко объясняет что именно выпрыскивается и инвертируется
Цитата:
Инвертируется процесс создания зависимости, вместо самого модуля его контролирует кто-то извне – зависимость «впрыскивют» модулю.
я никак не могу понять с чем именно вы не согласны...
- вы не согласны с тем что инверсия контроля уменьшает связанность?
- вы хотите поспорить о том, в чём разница между IoC и DI?
- вы против ООП вцелом?
Старый 11.01.2012 19:25 Котяра вне форума
Котяра
 
Аватар для Котяра
Цитата:
в чём разница между IoC и DI?
Да! Это ведь разные вещи!
Старый 11.01.2012 20:03 artcraft вне форума
artcraft
 
Аватар для artcraft
хорошая ссылка, и там как раз написано что DI это IoC, но IoC это принцип, а DI это паттерн, точнее один из паттернов реализующих принцип, так что называть их разными вещами не совсем правильно
Обновил(-а) artcraft 11.01.2012 в 20:09
Старый 11.01.2012 21:13 Котяра вне форума
Котяра
 
Аватар для Котяра
Техника внедрения принципа и принцип построения системы - это одно и то же?
Старый 11.01.2012 21:41 artcraft вне форума
artcraft
 
Аватар для artcraft
нет конечно, где я это утверждал?
DI это IoC, как, например cова это птица, но обратное утверждение не верно,
IoC более широкое понятие

я оспорил только утверждение что "сова и птица это разные вещи", они разные только с одной стороны
Обновил(-а) artcraft 11.01.2012 в 21:44
Старый 11.01.2012 21:45 Котяра вне форума
Котяра
 
Аватар для Котяра
Цитата:
DI это IoC
Ну опять же не совсем верно. DI это реализация принципа IoC.
Скорее - это метод вколачивания гвоздя как реализация принципа - соединить 2 доски вместе.
Но это детали. Да.
Обновил(-а) Котяра 11.01.2012 в 21:47
Старый 11.01.2012 21:56 artcraft вне форума
artcraft
 
Аватар для artcraft
Поменял формулировку в статье на однозначную
Старый 13.01.2012 14:20 FlashRus вне форума
FlashRus
 
Аватар для FlashRus
Цитата:
Почему объектно-ориентированное программирование провалилось?
Впервые прочтал статью "от корки до корки" включая комментарии.
Старый 14.01.2012 20:34 expl вне форума
expl
Цитата:
Как мой тимлид. Он сказал - "Я не буду спорить! Я просто прав,... иначе твои действия, мы признаем как саботаж проекта..."
Жалко что я не тимлид , приходится пользоваться фразами:
- "Просто поверь"
- "Мое подсознание, подсказывает, что с таким подходом мы огребём"
Или дешёвыми психологическими трюками:
- "Это же удобно, почему ты не хочешь так сделать?" - "Копипастить тоже удобно, только почему-то приводит к проблемам"
- "Давай сделаем X" - "Aга, давай еще запихаем X в Y"
Обновил(-а) expl 14.01.2012 в 20:37
 

 


Часовой пояс GMT +4, время: 05:11.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2019, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.