> В предыдущих публикациях я использовал для связей имена Efferent (центробежный) и Afferent (центростремительный), Ce и Ca, вместо Fan-out и Fan-in соответственно. Это был всего лишь каприз с моей стороны: мне нравилось сравнение с центральной нервной системой. Дядь-Боб, 132 страница, Чистая архитектура. Искусство разработки программного обеспечения. - СПб.: Питер, 2018. Кстати, принципы REP, CCP, CRP, Диаграмма противоречий принципов связности тож мне кажется было бы не плохо осветить на канале. А то в ютубе ощущение, что главное выучить расшифровку абривиатуры SOLID - и все ты понял клиен архитктуру.
Просто наслаждение получил! С удовольствием бы купил контента с патреона - если бы хоть какое-то описание было и структура в каком видео о чем говорите.
Всегда стараюсь определять минимально необходимые интерфейсы под конкретные юз-кейсы и использовать архитектуру с однонаправленной зависимостью слоев, например, чистую архитектуру. Теперь могу логически обосновать зачем, спасибо)
"Пожалуй в любой литературе по объектно-ориентированному проектированию встречаются эти два понятия. Считается, что любая спроектированная система, должна удовлетворять принципам низкой связности и высокого зацепления модулей. Соответствие данным шаблонам позволяет легко модифицировать и сопровождать программный код а также повышает степень его повторного использования." - абзац текста, взятый из перво-попавшейся ссылки на хабр с гугла
По мне так наоборот было бы как раз более понятно. То есть, зацепление - то, как модули "цепляются" друг за друга, а связность - то, насколько компоненты модуля связаны между собой в вопросе решения конкретной задачи, составляют ли они единую логическую единицу.
Я отталкиваюсь обычно на класс Ce - от 3 до 7, на компонент умножаем пропорционально классам, Ca - играет от назначения класса, скажем для доменных задач, более 10 уже плохо, для утилитарных задач (типа библиотекчный код) я вообще Ca не ограничиваю, так как бессмысленно.
Есть одна правка для лучшего понимания темы. Нестабильность нужно считать от 0 до -1, и график вести налево. А ещё лучше считать Стабильность (без не) от 0 до 1, тогда график направо. А иначе мозги после математики долго кипят (лишние минуты) и не могут сварить в чём проблема правой/левой стороны.
Здесь имеется ввиду не изменение состояния объекта во время работы приложения, а изменение логики во время разработки. Ну то есть если кто-то решил переписать класс A, то это никак не сломает класс В, потому что он не зависит от класса A, а вот наоборот такая ситуация вполне возможна
@@gaijin_nnsu мне академические знания бы получить хотелось бы. На работе я уже учусь. Да и я не говорил, что только российский вуз/специальность в ответ жду
@@illiamaksymenko804 не соглашусь. С красным дипломом вмк вы все равно будете джуном. И сильно охотиться за вами будут только на что то низкоуровневое на плюсах или вообще си. При этом платить как за джуна на каком нибудь руби вам не будут)
@@gaijin_nnsu так я и не говорил что будут охотиться. Одной зубрежки теории недостаточно в этом случае. Нужно на реальных проектах смотреть как это работает и набивать шишки
Странно каким образом увеличение связей в сторону нашего компонента вдруг увеличивают его стабильность. Отсюда похоже и костыль про любые 2 из 3х параметров
Но вы приподносите нестабильность как что то плохое. Возможно для тех кто услышит эту тему в первый раз тут это так и запомнится. Но согласно тому же мартину, не стабильность это не что то плохое. Нестабильный компонент - компонент который принимает хорошо изменения и от которого почти ничто не зависит. В него легко вносить изменения. Стабильный компонент от того и стабильный, что внести в него изменения сложно. При этом нестабильные компоненты при низком уровне абстракции не являются проблемой, поэтому нижний правый угол и не является зоной боли в оригинальном графике. Как и стабильные компоненты, в которые сложно вносить изменения при высоком уровне абстракций
Чет я не понял, если код будет находится в рекомендуемом овале, то он может быть абстрактен на 100% судя по графику. Он же не будет нести никакой пользы? Я правильно понимаю, что по мере абстрактности нужно больше стремится к 0.5?
Оценка применяется к рабочему коду. Код не пишется чтобы "технически" куда-то попасть в графике. Написали код, видите где он на графике. если ушел куда-то не туда смотрите почему, если можете поправить - поправляете, если нет, то работаете дальше.
Универспльность кода (абстрагированое от реализации) увпличивает время разработки. Руководитель не деволен. Конкретный код привязанный к к конкретной реализации затягивает время на модификацию, даже для не больших изменений, так же вводит в ступор руководителя. Как проектировать в стиле золотого сечения???
9:18 "Если 2 из 3-ёх параметров находятся в красной зоне, не важно в каком порядке" - есть три комбинации, с одной из них я согласен - Ce и I. Т.к чем меньше Ca по отношению к Ce, тем и больше I. Но вот с остальными комбинациями получается ерунда: Если у нас Ca по отношению к Ce будет велико, то уже никак не получится, что I будет у красный зоны, т.е одна комбинация у нас уже вообще выкинулась. ХОтя даже больше, т.к у нас две комбинации, в которой задействовано Ca, которая в красной зоне - Ca и I, Ca и Ce. Хотя единственная спорная комбинация - Ca и Ce, может ли тут вообще произойти такое, что они обе будут в красной зоне? Предположим что может, и они равны друг другу, но тогда выходит ,что I = 0.5, что судя по твоему утверждению тоже плохо
X - красная зона, О - ок Ce Ca I X X O - проблема O X X - маловероятно, так как Ca уменьшает I, но на границах может вылезти что-то подобное X O X - проблема 0.5 может быть и хорошо если O O O - возможно если слабое Ca и Ce, и примерно равны, тогда I может быть 0.5 и это норм.
@@S0ERDEVS Ca и Ce каким образом могут быть большими одновременно? Нужен конкретный пример, т.к если ты утверждаешь что когда они равны - это норм, то тогда выходит что может быть две оставшиеся ситуации Ca > Ce и Ca < Ce. Но оба этих варианта не подходят под утверждение «Ca и Ce находятся в красной зоне одновременно», т.к если Ca = Ce не подходит, то Ca > Ce не подходит тем более, остаётся вариант Ca < Ce. Но тогда возникает вопрос «на сколько он может быть меньше(а вернее во сколько) чтобы он ещё оставался также в красной зоне, как и Ce”. Предвосхищая ответ «точной границы быть не может» - тогда из этого следует, что не обязательно Ca = Ce является тем, что они «оба не в красной зоне», мб начиная уже с данного соотношения идёт «красная зона», так же мб быть что она начинается и с соотношение 4:7(Ca:Ce)
@@danjilov3965 элементарно 16 компонент используют компонент A - Ca = 16 при этом компонент А зависим на 15 компонентов, которые использует в своей работе Ce = 15. Индекс будет в районе 0.5.
Все проще, здесь сложная цепочка переводов и правильного произношения, приходится постоянно думать как перевести и как правильно произнести слова, да еще и линию повествования не упустить. ) Забавно как люди, которые никогда не делали подобных видео, выстраивают теорию заговоров и ищут скрытый смысл, а ответ лежит на поверхности.
Заказчик: Вскопайте 1 кв метр грядки и посадите цветы Кодер теоретик: проектирует тракторы и комбайны, месяцы на реализацию и года на сервисное обслуживание техники. Кодер практик: уже вскопал лопатой и пилит другой проект.
А теперь на момент представь, что тебе нужно вскопать пару тысяч гектар. Лопату в руки возьмёшь? Именно для подобных задач, люди и придумали все эти глупые тракторы и комбайнеры, вместе с их сложной инфраструктурой.
> В предыдущих публикациях я использовал для связей имена Efferent (центробежный) и Afferent (центростремительный), Ce и Ca, вместо Fan-out и Fan-in соответственно. Это был всего лишь каприз с моей стороны: мне нравилось сравнение с центральной нервной системой.
Дядь-Боб, 132 страница, Чистая архитектура. Искусство разработки программного обеспечения. - СПб.: Питер, 2018.
Кстати, принципы REP, CCP, CRP, Диаграмма противоречий принципов связности тож мне кажется было бы не плохо осветить на канале. А то в ютубе ощущение, что главное выучить расшифровку абривиатуры SOLID - и все ты понял клиен архитктуру.
Уникальный контент, вот что нам нужно!
Жаль просмотров не будет
не правда. я вот смотрю :)
чем меньше просмотров, тем больше зарплата у посмотревших)
(шутка, пишите все хорошо, пожалуйста)
Хорошо, что у меня нет таких больших проектов, чтобы это пригодилось. но на заметку взял. спасибо :)
Спасибо!
Спасибо, просто и интересно.
Просто наслаждение получил! С удовольствием бы купил контента с патреона - если бы хоть какое-то описание было и структура в каком видео о чем говорите.
Очень полезное видео, большое спасибо!
Как и всегда интересный ролик)
Спасибо большое за труд)
Полезно смотреть ваши видосики)
Большое спасибо)
Спасибо за полезный контент)!
Спасибо
Шикарное объяснение
Под конец ролика понял, что читал про это у самого Мартина в чистой архитектуре. Но Соер конечно намного понятнее объясняет, спасибо!
Самое удобное здесь - что получаешь порциями информацию и не зацикливаешься на всех моментах (пытаясь это всё внедрить)
У меня обратное мнение. В книге гораздо понятнее это описано.
Всегда стараюсь определять минимально необходимые интерфейсы под конкретные юз-кейсы и использовать архитектуру с однонаправленной зависимостью слоев, например, чистую архитектуру. Теперь могу логически обосновать зачем, спасибо)
проблема в том, что в реальных бизнес рулах, почти нет однонаправленных зависимостей...
@@albrehtdurer557 бизнес логика это отдельный слой, который ссылается на слой i/o.
@@rishatsharafiev если не затруднит, можно конкретный маленький пример?
дякую, дуже круто
Благодарю за видео! Существуют средства для автоматического расчета нестабильности и абстрактности?
Очень интересно, спасибо
Спасибо, оч круто!
Попиваю чаёк и учу программирование вот это коасс
спасибо!
Что есть красная зона для коэффициента связанности? Неважно афферентный, или эфферентный. 5 - это много?
Каждый раз смотрю и понимаю, на сколько ты поход на Линуса XD
Спасибо за видео. Можете посоветовать литературу по архитектуре приложений? За ранее благодарен.
Мартин фаулер Фореве
что-то твердо был уверен, что coupling - это связность, зацепление - cohesion
я тоже подметил это, словил диссонанс
"Пожалуй в любой литературе по объектно-ориентированному проектированию встречаются эти два понятия. Считается, что любая спроектированная система, должна удовлетворять принципам низкой связности и высокого зацепления модулей. Соответствие данным шаблонам позволяет легко модифицировать и сопровождать программный код а также повышает степень его повторного использования." - абзац текста, взятый из перво-попавшейся ссылки на хабр с гугла
По мне так наоборот было бы как раз более понятно. То есть, зацепление - то, как модули "цепляются" друг за друга, а связность - то, насколько компоненты модуля связаны между собой в вопросе решения конкретной задачи, составляют ли они единую логическую единицу.
У тебя что-то не то с предложением.
@@Tuhtarov так да, ты так и учился наверное по первым попавшимся ссылкам с гугля?))
Хорошо бы какие-то численные оценки. "Слишком большое" значение Се - это сколько? 1? 1000? 0.4?
Я отталкиваюсь обычно на класс Ce - от 3 до 7, на компонент умножаем пропорционально классам, Ca - играет от назначения класса, скажем для доменных задач, более 10 уже плохо, для утилитарных задач (типа библиотекчный код) я вообще Ca не ограничиваю, так как бессмысленно.
@@S0ERDEVS спасибо
Ничего не понял, но очень интересно
Есть одна правка для лучшего понимания темы. Нестабильность нужно считать от 0 до -1, и график вести налево. А ещё лучше считать Стабильность (без не) от 0 до 1, тогда график направо. А иначе мозги после математики долго кипят (лишние минуты) и не могут сварить в чём проблема правой/левой стороны.
Очень крутой контент, жалко что ничего не понятно.
5:20 - но ведь компонент А может менять компонент B через его методы
Здесь имеется ввиду не изменение состояния объекта во время работы приложения, а изменение логики во время разработки. Ну то есть если кто-то решил переписать класс A, то это никак не сломает класс В, потому что он не зависит от класса A, а вот наоборот такая ситуация вполне возможна
Теория хороша, но есть ли какие-то автоматизированные тулзы для анализа классов/модулей?
Для Java куча всего, сходу нагуглил jArchitect
Душный дед опять забыл принять таблетки(шучу)
Спасибо за видео)
Душнильный комментатор забыл принять таблетки(шучу)
Спасибо за коммент)
@@artemv3160 ща приму, забыл совсем
Наверное это будет глупый, но вопрос таков. На каких специальностях подобному учат? Если вообще учат
На работе научишься. В России в целом программа обучения отстаёт от требований в отрасли. Ближе всего ВШЭ.
@@gaijin_nnsu мне академические знания бы получить хотелось бы. На работе я уже учусь. Да и я не говорил, что только российский вуз/специальность в ответ жду
@@gaijin_nnsu так этому учат вообще-то. Этим принципам сто лет в обед
@@illiamaksymenko804 не соглашусь. С красным дипломом вмк вы все равно будете джуном. И сильно охотиться за вами будут только на что то низкоуровневое на плюсах или вообще си. При этом платить как за джуна на каком нибудь руби вам не будут)
@@gaijin_nnsu так я и не говорил что будут охотиться. Одной зубрежки теории недостаточно в этом случае. Нужно на реальных проектах смотреть как это работает и набивать шишки
Странно каким образом увеличение связей в сторону нашего компонента вдруг увеличивают его стабильность. Отсюда похоже и костыль про любые 2 из 3х параметров
Но вы приподносите нестабильность как что то плохое. Возможно для тех кто услышит эту тему в первый раз тут это так и запомнится. Но согласно тому же мартину, не стабильность это не что то плохое. Нестабильный компонент - компонент который принимает хорошо изменения и от которого почти ничто не зависит. В него легко вносить изменения. Стабильный компонент от того и стабильный, что внести в него изменения сложно. При этом нестабильные компоненты при низком уровне абстракции не являются проблемой, поэтому нижний правый угол и не является зоной боли в оригинальном графике. Как и стабильные компоненты, в которые сложно вносить изменения при высоком уровне абстракций
Чет я не понял, если код будет находится в рекомендуемом овале, то он может быть абстрактен на 100% судя по графику. Он же не будет нести никакой пользы?
Я правильно понимаю, что по мере абстрактности нужно больше стремится к 0.5?
Оценка применяется к рабочему коду. Код не пишется чтобы "технически" куда-то попасть в графике. Написали код, видите где он на графике. если ушел куда-то не туда смотрите почему, если можете поправить - поправляете, если нет, то работаете дальше.
Универспльность кода (абстрагированое от реализации) увпличивает время разработки. Руководитель не деволен. Конкретный код привязанный к к конкретной реализации затягивает время на модификацию, даже для не больших изменений, так же вводит в ступор руководителя. Как проектировать в стиле золотого сечения???
Тут явно руководитель лишний.
Очень ценные метрики
Так и будешь считать нестабильность и абстрактность, а фичи когда пилить? ПМ не похвалит)
9:18 "Если 2 из 3-ёх параметров находятся в красной зоне, не важно в каком порядке" - есть три комбинации, с одной из них я согласен - Ce и I. Т.к чем меньше Ca по отношению к Ce, тем и больше I. Но вот с остальными комбинациями получается ерунда: Если у нас Ca по отношению к Ce будет велико, то уже никак не получится, что I будет у красный зоны, т.е одна комбинация у нас уже вообще выкинулась. ХОтя даже больше, т.к у нас две комбинации, в которой задействовано Ca, которая в красной зоне - Ca и I, Ca и Ce. Хотя единственная спорная комбинация - Ca и Ce, может ли тут вообще произойти такое, что они обе будут в красной зоне? Предположим что может, и они равны друг другу, но тогда выходит ,что I = 0.5, что судя по твоему утверждению тоже плохо
X - красная зона, О - ок
Ce Ca I
X X O - проблема
O X X - маловероятно, так как Ca уменьшает I, но на границах может вылезти что-то подобное
X O X - проблема
0.5 может быть и хорошо если
O O O - возможно если слабое Ca и Ce, и примерно равны, тогда I может быть 0.5 и это норм.
@@S0ERDEVS Ca и Ce каким образом могут быть большими одновременно? Нужен конкретный пример, т.к если ты утверждаешь что когда они равны - это норм, то тогда выходит что может быть две оставшиеся ситуации Ca > Ce и Ca < Ce. Но оба этих варианта не подходят под утверждение «Ca и Ce находятся в красной зоне одновременно», т.к если Ca = Ce не подходит, то Ca > Ce не подходит тем более, остаётся вариант Ca < Ce. Но тогда возникает вопрос «на сколько он может быть меньше(а вернее во сколько) чтобы он ещё оставался также в красной зоне, как и Ce”. Предвосхищая ответ «точной границы быть не может» - тогда из этого следует, что не обязательно Ca = Ce является тем, что они «оба не в красной зоне», мб начиная уже с данного соотношения идёт «красная зона», так же мб быть что она начинается и с соотношение 4:7(Ca:Ce)
@@danjilov3965 элементарно
16 компонент используют компонент A - Ca = 16 при этом компонент А зависим на 15 компонентов, которые использует в своей работе Ce = 15. Индекс будет в районе 0.5.
Пример как можно "обнаучить" (скорее "обпсевдонаучить") любую область
Я прям чувствую что автор читает и сам не до конца понимает ) может поэтому и учит нас чтоб самому научиться ))
Все проще, здесь сложная цепочка переводов и правильного произношения, приходится постоянно думать как перевести и как правильно произнести слова, да еще и линию повествования не упустить. )
Забавно как люди, которые никогда не делали подобных видео, выстраивают теорию заговоров и ищут скрытый смысл, а ответ лежит на поверхности.
@@S0ERDEVS В любом случае спасибо за видео, просто я считаю можно куда проще объяснить, но т.к. я видосики не снимал возможно я не прав )
Заказчик: Вскопайте 1 кв метр грядки и посадите цветы
Кодер теоретик: проектирует тракторы и комбайны, месяцы на реализацию и года на сервисное обслуживание техники.
Кодер практик: уже вскопал лопатой и пилит другой проект.
А теперь на момент представь, что тебе нужно вскопать пару тысяч гектар. Лопату в руки возьмёшь?
Именно для подобных задач, люди и придумали все эти глупые тракторы и комбайнеры, вместе с их сложной инфраструктурой.
Видео ниочём. Эта инфа есть на первой странице любой книги по архитектуре