и это не вещь в себе

это тупо набор правил, которые помогают поддерживать enterprise проекты

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

Ну то есть что - SOLID не нужен, да?

ваш SOLID нарушает мой YAGNI

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

ваш SOLID нарушает мой YAGNI

Почему?

не нужно доводить до абсурда эти понятия

Не нужно врать. SOLID по "Clean architecture" описан совершенно не так как его описывают левые люди цитируя википедию. В википедии эти пять букв оторваны от реальности и перевраны сообществом, в книге четко изложено что такое SOLID и почему неследование SOLIDу ведет к болям в поддержке. Иньекции через autowired - не SOLID. В итоге мы и лабаем не солид - редко когда контракт сервиса имеет более одной имплементации. Редко когда сервис действительно сингл-респонсибл. Со временем это почти всегда вырождается в говнище по 100500 строк, когда заказчики начинают менять требования и внезапно абстракции теряют стабильность. И я бы рад увидеть исключение из правил, но не вижу нигде.

Почему?

Ну это была полушутка, но с долей правды.

Вот если бы чел щас привел пример, где сприговское нарушение солида усадиживает людей на бутылку, было бы другое дело

Не нужно врать. SOLID по "Clean architecture" описан совершенно не так как его описывают левые люди цитируя википедию. В википедии эти пять букв оторваны от реальности и перевраны сообществом, в книге четко изложено что такое SOLID и почему неследование SOLIDу ведет к болям в поддержке. Иньекции через autowired - не SOLID. В итоге мы и лабаем не солид - редко когда контракт сервиса имеет более одной имплементации. Редко когда сервис действительно сингл-респонсибл. Со временем это почти всегда вырождается в говнище по 100500 строк, когда заказчики начинают менять требования и внезапно абстракции теряют стабильность. И я бы рад увидеть исключение из правил, но не вижу нигде.

Какой именно пункт SOLID нарушает иъекции autowired через конструктор?

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

Какой именно пункт SOLID нарушает иъекции autowired через конструктор?

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

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

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

s o l i d

Вот если бы чел щас привел пример, где сприговское нарушение солида усадиживает людей на бутылку, было бы другое дело

Примеры спрятаны в куча корпоративного приватного кода) вообще тяжело приводить их, так как каждая ситуация по своему уникальна. Где-то одно, где-то другое. Вырвешь из контекста и пример уже не будет иметь смысл.

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

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

По моему опыту класс с именем Service в том или ином виде обычно превращается в солянку из процедур.

С ифами и запутанной логикой

Примеры спрятаны в куча корпоративного приватного кода) вообще тяжело приводить их, так как каждая ситуация по своему уникальна. Где-то одно, где-то другое. Вырвешь из контекста и пример уже не будет иметь смысл.

Тяжело приводить их, потому что достоинства SOLID проявляются в поддержке, а не в написании с нуля.

С ифами и запутанной логикой

И тут самое время позвать на помощь капитана рефакторинг!

вообще, этот СОЛИД и понимание его вызывают много споров, что уже само по себе вызывает сомнения

If-метрика тут отлично работает кстати

пока СОЛИДность нельзя оценить программно, споры не прекратятся

И тут самое время позвать на помощь капитана рефакторинг!

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

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

ты написал 79 символов, а мог бы написать 1.

ты написал 79 символов, а мог бы написать 1.

там выше по треду O, L и D кажется упоминались

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

Ну хотя бы подробный комментарий надо оставить))) вообще конечно без покрытия хорошего тестами что то очень сложно

ты написал 79 символов, а мог бы написать 1.

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

Слава богу у нас покрытие позволяет и никто не рвет глотку в погоне за скоростью.

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

Хайлатни сообщение, про нарушение LSP. Я ваш срач пропустил, но мне правда интересно прочитать.

ребят

срач ни о чем

@skapral тебе бан в следующий раз за разжигание на пустом месте

Больше 1к сообщений за сутки не прочитанных)) =

Вчера эклипс фотон выпустили

а обсудили уже, с какого конца яйца разбивать?

а обсудили уже, с какого конца яйца разбивать?

разве не ножом по середине? (я серьезно)

Хайлатни сообщение, про нарушение LSP. Я ваш срач пропустил, но мне правда интересно прочитать.

Оно нарушается тем, что по дефолту спрингом предполагается только один класс, имплементирующий интерфейс. Получается, что интерфейс используется просто чтобы он был. Отсюда растут ноги у названий классов типа SomeServiceImpl.

Хайлатни сообщение, про нарушение LSP. Я ваш срач пропустил, но мне правда интересно прочитать.

Ладно, хрен с ним. LSP утверждает что если компонент использует базовый тип S, то он должен работать as-designed со всеми подтипами T от S. Но так как autowiredу у спринга надо знать что конкрентно нужно инжектить в конструктор, просто оставить аргумент базового типа в конструкторе не получится. Это агитирует к двум вещам - либо завязать конструктор на имплементацию и/или дав ему конкретное имя и тип - что херит LSP (мы не можем больше реюзать сервис с произвольными подтипами), либо держать в контексте всегда одну имплементацию, чтоб уж спринг точно ничего не попутал. Доходит до того что некоторые блоггеры утверждают что интерфейсы не нужны. Один хер - больше одной имплементации никогда не будет

разве не ножом по середине? (я серьезно)

это сложный вопрос согласно докрине CLEAN, это может привести к неподдерживемому состоянию яйца, и, как следствие, повышает риск провала проекта

разве не ножом по середине? (я серьезно)

и вареное тоже?

и вареное тоже?

Смотря насколько солидно варёное

Смотря насколько солидно варёное

примерно на SOL из SOLID

и вареное тоже?

нет, у меня не меняется состояние объекта Яйцо со скорлупой

нет, у меня не меняется состояние объекта Яйцо со скорлупой

так это другой объект, Вареное Яйцо со скорлупой

нет, у меня не меняется состояние объекта Яйцо со скорлупой

инкапсуляция яйца нарушена

нет, у меня не меняется состояние объекта Яйцо со скорлупой

Разбить интерфейс

так это другой объект, Вареное Яйцо со скорлупой

Ребята, это разные объекты. new Boiled( new Shell( new Egg( ) ) )

Ребята, это разные объекты. new Boiled( new Shell( new Egg( ) ) )

Зачем ты варишь скорлупу?

вам за это наверное еще по 5+к бачей в месяц платят

)))

)))

Лиспер в чате, расходимся.

Зачем ты варишь скорлупу?

а по солиду какая хрен разница что варить

вам за это наверное еще по 5+к бачей в месяц платят

у меня отмазка — скала компилится

Интерфейс же Boilable

у меня отмазка — скала компилится

сбт резолвит зависимости

сбт резолвит зависимости

это следующий прием

Ладно, хрен с ним. LSP утверждает что если компонент использует базовый тип S, то он должен работать as-designed со всеми подтипами T от S. Но так как autowiredу у спринга надо знать что конкрентно нужно инжектить в конструктор, просто оставить аргумент базового типа в конструкторе не получится. Это агитирует к двум вещам - либо завязать конструктор на имплементацию и/или дав ему конкретное имя и тип - что херит LSP (мы не можем больше реюзать сервис с произвольными подтипами), либо держать в контексте всегда одну имплементацию, чтоб уж спринг точно ничего не попутал. Доходит до того что некоторые блоггеры утверждают что интерфейсы не нужны. Один хер - больше одной имплементации никогда не будет

Вам привели конструктивный аргумент. Что нужно делать? Конечно же скатиться в идиотский троллинг и заигнорить аргумент.

Ладно, хрен с ним. LSP утверждает что если компонент использует базовый тип S, то он должен работать as-designed со всеми подтипами T от S. Но так как autowiredу у спринга надо знать что конкрентно нужно инжектить в конструктор, просто оставить аргумент базового типа в конструкторе не получится. Это агитирует к двум вещам - либо завязать конструктор на имплементацию и/или дав ему конкретное имя и тип - что херит LSP (мы не можем больше реюзать сервис с произвольными подтипами), либо держать в контексте всегда одну имплементацию, чтоб уж спринг точно ничего не попутал. Доходит до того что некоторые блоггеры утверждают что интерфейсы не нужны. Один хер - больше одной имплементации никогда не будет

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

Не увидел нарушения принципа, в общем, соре.

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

вот именно, мало ли что там в аннотации написано, если по факту туда можно подсунуть любую имплементацию интерфейса и код будет работать. значит ничего не нарушено

а аннотации это просто метаинформация

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

Проводя вашу аналогию дальше, спринг в autowired конструктор будет инжектить только если 1) Сын один 2) Вместо бати в объявлении конструктора будет сын 3) Аттрибут типа батя будет аннотирован какими нибудь квалифаерами, которые скажут спрингу - кто конкретно сын. И говорить, что это вовсе не каплинг одной конкретики (сервиса куда инжектят) на другую (сыновей) - врать самому себе.

вот именно, мало ли что там в аннотации написано, если по факту туда можно подсунуть любую имплементацию интерфейса и код будет работать. значит ничего не нарушено

Он нарушается косвенно. В спринге интерфейс для галочки из-за того, что ему нужно знать, какую именно имплементацию вставлять. И зачастую имплементация только одна. Получается жесткая связность компонентов. Ты прав, можно иметь несколько имплементаций, но большой шанс того, что компонент завязан на одну конкретную имплементацию.

Проводя вашу аналогию дальше, спринг в autowired конструктор будет инжектить только если 1) Сын один 2) Вместо бати в объявлении конструктора будет сын 3) Аттрибут типа батя будет аннотирован какими нибудь квалифаерами, которые скажут спрингу - кто конкретно сын. И говорить, что это вовсе не каплинг одной конкретики (сервиса куда инжектят) на другую (сыновей) - врать самому себе.

Вы забыли про @Primary

ERROR: S client not available

Отец - сын - это не очень метафора, потмоу что class Batja extends Son, а интуитивно кажется по-другому

То есть тот факт, что вы объявили интерфейс и зависите от него не значит, что вы уменьшили связность.

Отец - сын - это не очень метафора, потмоу что class Batja extends Son, а интуитивно кажется по-другому

ваще наоборот

Вы забыли про @Primary

Та же проблема что и с квалифаерами

ваще наоборот

почему? сын шире и умеет больше чем отец?

почему? сын шире и умеет больше чем отец?

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

Он нарушается косвенно. В спринге интерфейс для галочки из-за того, что ему нужно знать, какую именно имплементацию вставлять. И зачастую имплементация только одна. Получается жесткая связность компонентов. Ты прав, можно иметь несколько имплементаций, но большой шанс того, что компонент завязан на одну конкретную имплементацию.

Ну уж не знаю насколько косвенно. Ну если LSP не убедил, то DIP во весь рост херится. Волатильная конкретика, завязанная на волатильную конкретику = зона боли.

почему? сын шире и умеет больше чем отец?

Чисто из предметной логики

Почему молчат спрингосиляторы ?

Проводя вашу аналогию дальше, спринг в autowired конструктор будет инжектить только если 1) Сын один 2) Вместо бати в объявлении конструктора будет сын 3) Аттрибут типа батя будет аннотирован какими нибудь квалифаерами, которые скажут спрингу - кто конкретно сын. И говорить, что это вовсе не каплинг одной конкретики (сервиса куда инжектят) на другую (сыновей) - врать самому себе.

Вообще, нет. У спринга в кунтейнере много подвидов бати. И любой из подвидов он может подставить туда, где ожидают батю. Это соблюдение лсп. А то шо спринг для определения, которого из батиных отпрысков куда отпавить, использует метаинформацию, это уже не связано с ЛСП.

Почему молчат спрингосиляторы ?

Они спорят что первично - сын или отец

О чем молчат спрингоосиляторы?

О чем молчат спрингоосиляторы?

нет времени на болтовню, аннотировать нужно

Вообще, нет. У спринга в кунтейнере много подвидов бати. И любой из подвидов он может подставить туда, где ожидают батю. Это соблюдение лсп. А то шо спринг для определения, которого из батиных отпрысков куда отпавить, использует метаинформацию, это уже не связано с ЛСП.

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

пропустишь аннотацию, бин не провалидируется – лишат дневного пайка

Просто по вашей же логике, Сергей, явная передача любого настоящего аргумента в любой конструктор это нарушение ЛСП, так как туда в конечном итоге передается какая-то конкретная сущность. >И говорить, что это вовсе не каплинг одной конкретики (сервиса куда инжектят) на другую (сыновей) - врать самому себе.

Собственно, чтобы не нарушать ЛСП, лучше не использовать.. конструкторы?

Просто по вашей же логике, Сергей, явная передача любого настоящего аргумента в любой конструктор это нарушение ЛСП, так как туда в конечном итоге передается какая-то конкретная сущность. >И говорить, что это вовсе не каплинг одной конкретики (сервиса куда инжектят) на другую (сыновей) - врать самому себе.

эм, нет, вот указывать это на параметре конструктора — нарушение

Или джява? Или ди?

Просто по вашей же логике, Сергей, явная передача любого настоящего аргумента в любой конструктор это нарушение ЛСП, так как туда в конечном итоге передается какая-то конкретная сущность. >И говорить, что это вовсе не каплинг одной конкретики (сервиса куда инжектят) на другую (сыновей) - врать самому себе.

Не передача. А указание деталей "что конкретно инжектить" в декларации.

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

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

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

зачем такие сложности? есть же оператор new

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

Супер. Но зачем мне для этого спринг если я могу просто юзать new?

Не передача. А указание деталей "что конкретно инжектить" в декларации.

Относитесь к декларации как к коду, не относящему с реализации, коим он и не является.

Супер. Но зачем мне для этого спринг если я могу просто юзать new?

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

Вы в любом случае хоть спрингом, хоть еще как будете эти сущности создавать.

зачем такие сложности? есть же оператор new

Ну ваще предполагается, шо это наоборот упрощение

Относитесь к декларации как к коду, не относящему с реализации, коим он и не является.

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

я думал этот спор вчера угас...

Вы в любом случае хоть спрингом, хоть еще как будете эти сущности создавать.

Буду. Но без спринга я буду делать это в клиенте, а не в оунере. Оунер останется чист.

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

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

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

Это если не пользоваться component-scan и если явно знать, в каком месте создаётся контекст. И также если этот контекст только один.