Привет!

Я тут кажись придумал простое и понятное (по крайней мере мне 😂) определение функциональной связанности метода:)

Метод обладает функциональной связанностью, если он не обладает побочными эффектами.

Очевидно, чистые (в терминах ФП) методы обладают функциональной связанностью - в них весь код предназначен для вычисления результата функции. В них можно конечно запихать "левый" код, но если он ничего не вкладывает в результат, любая современная иде(я) подсветит его как мёртвый.

Но в моей терминологии есть ещё методы с эффектами - это методы которые не являются чистыми (выполняют ввод-вывод), но при этом этот ввод-вывод должен быть атомарен - отдельные операции не имеют смысла друг без друга.

Например, есть метод "одобрения" создания некоторой сущности. Он считывает сущность, меняет в ней флажёк и записывает назад - и то и то является эффектом.

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

Но как тогда реализовать эту функциональность?
Через шину событий. Метод одобрения сохраняет сущность и публикует событие "сущность одобрена".
А дальше в отдельном методе это событие обрабатывается и посылается пуш.

В чем разница между публикацией события и отпрвкой пуша?
Она, на самом деле довольно тонкая.
Но публикация события, на самом деле не разрывно связана с сохранением сущности. Мы можем не реализовывать это в коде, но при всяком сохранении сущности этим методом происходит событие "сущность одобрена".
И если нам важно, чтобы система об этом событии узнавала, то сбой в его публикации является достаточной причиной для сбоя всего метода одобрения в целом.

С другой стороны, отправка пуша разрывно связана с одобрением. Пуш можно не отправлять вообще. Его можно заменить на Email, в случае сбоя отправки пуша сейчас - его можно отправить попозже.

Таким образом помещение отправки пуша в метод одобрения сделает его методом с побочным эффектом (отправки пуша). И снизит связанность модуля до процедурной.

#terminology@ergonomic_code #cohesion@ergonomic_code #ergo_approach@ergonomic_code #design

Привет!

Когда ещё весной-летом делал первый подход к посту о декомпозиции на базе диаграммы эффектов захомячил крутой пост про связанность и сцепленность.

Сейчас делаю второй подход к посту декомпозиции, откопал его, перечитал, снова впечатлился и на это раз решил поделиться с вами:)

#posts@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

Привет!

В продолжение вчерашнего топика очень крутой доклад от Кента Бека про coupling и cohesion.

В докалде Бек утверждает, что в оригинальной книге сцепленность оценивается относительно некоторого изменения (хотя я сам такого не помню и в книге найти не смог).

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

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

—

Ещё одна мысль из доклада - "расстояние" между сцепленными элементами имеет значение. И это одна из основных причин, почему я перешёл от Эргономичной структуры в1 к в2. И в чём разочаровался по мотивам Проекта Э.

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

—

Ну и наконец книга - Tidy First?: A Personal Exercise in Empirical Software Design - добавлю в свой список на прочтение

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code

И вот ещё хороший доклад про Coupling.

Там же, внезапно, мужик говорит про тот самый Connascence и объёдиняет его с классическим Coupling в ещё более современный Integration Strength. Ток эту штуку тексту нагуглить не получается.

И так же говорит про "расстояние" в коде.

#talks@ergonomic_code #design@ergonomic_code #coupling@ergonomic_code #cohesion@ergonomic_code