?

пара часов работы, тупой ролик, бесплатная реклама

Ну там ролик датирован началом 2015

Так что похоже просто сняли, потом кто то заметил и понеслось

ну значит.... печалька)

???

а то у авторов интервью берут на тему "как снимать вирусы"

Просто ПРОВИНЦИАЛЬНАЯ СТУДИЯ

сука у него даже блеать у сына грива )

?

омг вы о чем?

ну и ещё там слишком много стереотипов конечно. Просто эталонная вебстудия из глубинки

омг вы о чем?

https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle

глянь)

ок гляну) очередной наброс?

не то что бы

просто ищу инфу по SRP

какие-то интересные мысли

вопросы

это показалось наиболее удачным

SRP это то что превращает код в модули и процедурки)

эм.... нет.

SRP это принцип, который кажется самым простым, но на самом деле является самым сложным

точно так же как LSP является самым простым принципом, хотя формулировка кажется сложной

In other words: classes can only have reasons to change when there are new requirements. But by then, all the bad stuff that's supposed to happen if we violate SRP already happened! What's the advantage of a principle that only applies retroactively? I find this idea is not justified by any real world case.

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

ну.... это не совсем SRP

это просто снижение связанности

и разделив все на самые мелкие классы ты убъешь зацепление в твоих модулях

мне больше нравится пример с примерением разных ролей при разработке класса

мол мы пишем класс по обработке инвойсов и хернули приватным метод по подсчету налогов туда

и потом подумали "а что если бухгалтер захочет что бы мы налоги просто могли посчитать, без необходимости формировать ажно целый инвойс"

ок у тебя есть класс с методом, который берет из точки А данные(апи), из точки Б(база), мержит их и отдает обратно SRP не нарушено?

ну и ещё там слишком много стереотипов конечно. Просто эталонная вебстудия из глубинки

Я когда в первый раз увидел - прослезился. Ведь в такой же точно работал. Даже чел с такой же гривой директором был)

ок у тебя есть класс с методом, который берет из точки А данные(апи), из точки Б(база), мержит их и отдает обратно SRP не нарушено?

если работа с API и работа с базой "спрятаны" за отдельными интерфейсами - то норм

нет, в том то и дело не спрятаны

в идеале, этот класс нихера не делает, кроме как связывает до кучи 3 компоненты

получатель из А, получатель из Б, мержер. верно ведь?

почему 3 компоненты?

ну как... можно и так

но в целом у тебя есть 2 поставщика данных и мерджер

который является по сути тоже потавщиком данных

я не вижу смысла делать отдельный класс, который руководит процессом

а если этот метод нужен в 3х местах?

эм...

мерджер?

или кто?

или ты предлагаешь мержера не выделять в компоненту отдельную?

ну да, не предлагаю

не, сам класс который руководит балетом

некий фасад

я предлагаю сделать 3 класса. 2 для работы с внешним миром, и объеденяющий результаты

система будет работать только с этим классом

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

и потом внезапно, требуется 3й источник

и я не вижу сходу причин выделять "мердж" в отдельный класс оставляя сверху класс-пустышку

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

не понял

почему?

логика мержа может быть сложной и ее проще тестировать отдельной компонентой

ээээээм

и что тебе мешает? мокаешь провайдеры данных и готово

почему?

давай более конкретно. есть 2 контроллера и команда есть провайдер А, провайдер Б, мержер мне нужно в 2х контроллерах и команде вызвать А, Б и потом мержер. ты в 3х местах продублируешь вызовы и везде будешь тащить их за собой?

ээээм

мой мерджер сам сходит в A и B, смерджит и вернет

если кому-то надо отдельно A и отдельно B - он их получит

если надо вместе - он попросит мерджер

ладно, в этом кейсе в принцпе не обязательно выделять

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

но в итоге будет это

если для мерджа нужны еще зависимости - тут уже можно думать

но в итоге будет это

нуууу.... как бы не совсем)

это у тебя будет при сегрегации интерфейсов)

а какого размера класс определяется необходимостью вносить в него изменения

какой бы пример привести

ну я люблю приводить пример - класс Base64

у него есть два метода - encode и decode

EncoderInterface, DecoderInterface

причина для изменения этого класса одна - изменения в реализации кодирования/декодирования

EncoderInterface, DecoderInterface

опять ты эти богомерзские суффиксы юзаешь... ну да ладно. Тип так

?

причем если ты поменял кодирование - тебе придется поменять и декодирование

потому что это зависимые операции

точно так же у тебя может быть один жирный класс по работе с внешим сервисом, тупо потому что "тебе так удобнее и если что-то менять то надо и там и там подправить"

но ты можешь налепить 3-4 интерфейса с один-двумя методами и таким образом убрать связанность

так... потиху прихожу к тому что про SRP надо последним рассказывать... или перед open/close

причем если ты поменял кодирование - тебе придется поменять и декодирование

ну... не всегда, да и не везде симмитричные операции

не везде)

я просто тебе говорю что цель SRP не разделить классы так, что бы остался один метод

а наоборот сгруппировать классы так, что бы они были более coheasive

разделять ты будешь при помощи сегрегации интерфейсов

ок. другой пример у тебя сервис по работе с внешим API тебе надо составить запрос, сделать сам запрос, распарсить ответ у API скажем 3 метода как бы ты это реализовал?

хм...

3 метода у API?

и надо парсить результат...

хм....

честно - руководствуясь здравым смыслом я бы сделал сначала один класс, и возможно парочку интерфейсов если мне не нужны все три метода API вместе

(а мне скорее всего не нужны иначе публичный метод был бы только один)

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