Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: Получение spring beans в классе, неуправляемом spring  [new]
bob1970
Member

Откуда: Пермь
Сообщений: 217
unregestered
На фига здесь лишний интерфейс IServiceForFree ?? Это же не, прости госпади, EJB 2.1, где интерфейсы надо было на каждый чих создавать.

Вот это по нашему, по бразильски. Да нафига нужны все эти интерфейсы?
:)
26 апр 20, 20:51    [22123258]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
Куча быдлкодеров перешло с EJB на спринг и начинают копировать ужасные EJB практики там, где это нафиг не нужно.

FizzBuzz Enterprise Edition
27 апр 20, 15:46    [22123641]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46599
А что у разработчиков Node - вообще таких проблем нет?

Складывается впечатление что им открыто - истинное буддийское знание.
А мы (java-исты) - как лохи позорные?...
27 апр 20, 16:38    [22123662]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
bob1970
Member

Откуда: Пермь
Сообщений: 217
unregestered
На фига здесь лишний интерфейс IServiceForFree ?? Это же не, прости госпади, EJB 2.1, где интерфейсы надо было на каждый чих создавать.


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

Сообщение было отредактировано: 10 май 20, 09:18
10 май 20, 09:18    [22130063]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46599
Идея овер-инжинернига описана в статье на хабре https://habr.com/en/post/113128/

К сожалению в Spring заходят новички которых сразу учат длинным реализациям.
Думаю что через лет 5 такого учения они будут уже не в состоянии написать простой
код. Такая проф-деформация специфичная именно для Spring-сегмента.
10 май 20, 14:00    [22130129]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5298
mayton
Идея овер-инжинернига описана в статье на хабре https://habr.com/en/post/113128/

К сожалению в Spring заходят новички которых сразу учат длинным реализациям.
Думаю что через лет 5 такого учения они будут уже не в состоянии написать простой
код. Такая проф-деформация специфичная именно для Spring-сегмента.


Ну типичный карго-культ.
Просто учатся по "делай как я", не задавая вопросы.
Имхо это все же лучше, чем класс на 10 000 строк с методом содержащим "if else if" на 5000 - 7000 строк. :-)
11 май 20, 07:59    [22130459]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
bob1970
Member

Откуда: Пермь
Сообщений: 217
mayton
Идея овер-инжинернига описана в статье на хабре https://habr.com/en/post/113128/

К сожалению в Spring заходят новички которых сразу учат длинным реализациям.
Думаю что через лет 5 такого учения они будут уже не в состоянии написать простой
код. Такая проф-деформация специфичная именно для Spring-сегмента.

По-сути в этом и был мой вопрос. Излишняя привязанность к spring, ктр. накладывает определенные ограничения (одиночка, stateless,.... ). В результате появляется связАнность компонентов, т.к. очень просто воткнуть бин спринга, тем самым опять привязаться к спрингу. Вижу конструкторы с 5-ю и более аргументов. Максимальное размещение логики в в бинах спринга, отсюда процедурщина в полный рост. Всякие там паттерны и прочие SOLID идут лесом.
11 май 20, 10:15    [22130479]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5298
bob1970

По-сути в этом и был мой вопрос. Излишняя привязанность к spring, ктр. накладывает определенные ограничения (одиночка, stateless,.... ). В результате появляется связАнность компонентов, т.к. очень просто воткнуть бин спринга, тем самым опять привязаться к спрингу. Вижу конструкторы с 5-ю и более аргументов. Максимальное размещение логики в в бинах спринга, отсюда процедурщина в полный рост. Всякие там паттерны и прочие SOLID идут лесом.


Тут вчера был [url=]стримчик[/url] где в принципе объяснялось "как и нафига". :-)
12 май 20, 05:57    [22130883]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
bob1970
Максимальное размещение логики в в бинах спринга, отсюда процедурщина в полный рост. Всякие там паттерны и прочие SOLID идут лесом.


На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр.

Для многих бизнес-приложений больше характерна модель с множеством взаимодействующих объектов, где сложно выделить главный.
В этом случае более подходящей моделью является Multiple Dispatch, которая, правда, очень плохо реализована в языках программирования. Обычно диспетчеризация идёт по одному типу, что и является ООП (правда, ООП ещё подразумевает инкапсуляцию).

Так что "процедурщина" в бизнес-приложениях это не маргинальщина, а вполне естественное отображение предметной области.
12 май 20, 06:24    [22130885]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
bob1970
Member

Откуда: Пермь
Сообщений: 217
unregestered


На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр.
Для многих бизнес-приложений больше характерна модель с множеством взаимодействующих объектов, где сложно выделить главный.

Спорное место. Но главное ниже.
unregestered

В этом случае более подходящей моделью является Multiple Dispatch, которая, правда, очень плохо реализована в языках программирования. Обычно диспетчеризация идёт по одному типу, что и является ООП (правда, ООП ещё подразумевает инкапсуляцию).

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

Как-то революционно выглядит. Можешь подробнее раскрыть мысль.
12 май 20, 08:46    [22130938]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5298
unregestered

На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр.


С чего вы взяли, что ООП подходит для описание объектов GUI? ;-)
Вы писали свой GUI?

unregestered

Для многих бизнес-приложений больше характерна модель с множеством взаимодействующих объектов, где сложно выделить главный.
В этом случае более подходящей моделью является Multiple Dispatch, которая, правда, очень плохо реализована в языках программирования. Обычно диспетчеризация идёт по одному типу, что и является ООП (правда, ООП ещё подразумевает инкапсуляцию).


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

unregestered

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


Именно, что маргинальщина, по принципу сделать быстро сейчас. Потом долго и мучительно переделывать потом.
Ну и обычно для бакендеров формулируют задачу по реалиазции бизнес-процессов в процедурном стиле, ещё в виде веселых картинок.
Вот они как настоящие акыны делают "что вижу, то пою".
:-)
12 май 20, 10:52    [22131012]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Ржавый гвоздь
Member

Откуда:
Сообщений: 80
chpasha

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

Бгг, когда коту делать нечего он яйца лижет. А современный программист переписывает проект с одного фреймворка на другой точно такой же но модный в этом сезоне. А когда придет новый сезон и новый фреймворк - примется переписывать то же самое, но уже на него. Ну ничего, главное что денежка капает. А то, что занят абсолютно бессмысленной работой - ну так смысл на хлеб не намажешь.
12 май 20, 13:20    [22131136]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
chpasha
Member

Откуда:
Сообщений: 9222
Ржавый гвоздь
Бгг, когда коту делать нечего он яйца лижет

[конспектирует, высунув язык]

Ржавый гвоздь
переписывает проект с одного фреймворка на другой точно такой же но модный в этом сезоне. А когда придет новый сезон и новый фреймворк - примется переписывать то же самое, но уже на него. Ну ничего, главное что денежка капает. А то, что занят абсолютно бессмысленной работой - ну так смысл на хлеб не намажешь.
тебе, конечно, из погреба всяко виднее
12 май 20, 13:49    [22131171]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5298
Ржавый гвоздь

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


Ну бывает надо переписывать на стильномодномолодежный фреймворк.
Вот например щас у меня проект на jBoss seam, который лет пять как "сдох".
Переводить его на JSF - ну такое.
Так что сейчас переписывают на React + SpringBoot.
12 май 20, 13:49    [22131173]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
mad_nazgul

С чего вы взяли, что ООП подходит для описание объектов GUI? ;-)
Вы писали свой GUI?
:-)


Конечно писал лол

mad_nazgul

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


"Сообщение" (например в Object C) это всего лишь навсего вызов метода.

mad_nazgul

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


"Переделывание", как вы выражаетесь, это неотъемлемая часть процесса разработки в принципе, и никак не связана со стилем программирования.

Сообщение было отредактировано: 12 май 20, 14:29
12 май 20, 14:25    [22131227]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
bob1970

Как-то революционно выглядит. Можешь подробнее раскрыть мысль.


Коротко: ООП это частный случай Dynamic dispatch, когда выбор метода идёт только на основе одного типа. Однако в бизнес-приложениях (и многих других) обычно взаимодействуют 2-3 объекта и невозможно выделить главный.
12 май 20, 14:30    [22131231]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
unregestered
bob1970

Как-то революционно выглядит. Можешь подробнее раскрыть мысль.


Коротко: ООП это частный случай Dynamic dispatch, когда выбор метода идёт только на основе одного типа. Однако в бизнес-приложениях (и многих других) обычно взаимодействуют 2-3 объекта и невозможно выделить главный.

Есть мнение что все немного наоборот, что multimethods это разновидность ООП, как и prototype-based languages, а не наоборот. Хотя и то и то мнение мне кажется немного натянутым. Ну и в любом случае мне кажется что ФП уделывает все эти парадигмы на раз-два
12 май 20, 15:00    [22131258]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
забыл ник
Ну и в любом случае мне кажется что ФП уделывает все эти парадигмы на раз-два


Программер должен знать разные парадигмы и архитектурные паттерны и понимать где что применимо.

Я уже давно оцениваю языки с сугубо практической точки зрения: поддержка IDE, билд тулов, стат-анализаторов, библиотек, фреймворков, дебагеров, мониторинговых тулов, удобство рефакторинга, быстрота компиляции и работы итд итп
Всё остальное это свистелки и перделки, как выражался товарищ Дейкстра.

Сообщение было отредактировано: 13 май 20, 04:00
13 май 20, 04:01    [22131735]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5298
unregestered

Конечно писал лол


Вот прям API для рисования окошек, менюшечек и прочего?


unregestered

"Сообщение" (например в Object C) это всего лишь навсего вызов метода.


Не только, там еще определенная иерархия классов.

unregestered

"Переделывание", как вы выражаетесь, это неотъемлемая часть процесса разработки в принципе, и никак не связана со стилем программирования.


Ещё как связана.
Переделать можно всё, вопрос в цене.
Стоимость каждого последующего изменения процедурно написанной программы стремиться к бесконечности. ;-)
13 май 20, 06:55    [22131757]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
mad_nazgul

Вот прям API для рисования окошек, менюшечек и прочего?


API - это не GUI.

mad_nazgul

Не только, там еще определенная иерархия классов.


Я не понимаю, про что вы. При чём тут иерархия. Речь шла про то что [receiver message] в Objective-C эквивалентно receiver.message() в других языках программирования

mad_nazgul

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


Сколько вы программ переделали? Я - миллион, включая свои собственные (хотя казалось бы уж тут-то качество должно быть на высоте).
И я вас уверяю, что это: 1) неизбежно, 2) не является чем-то запредельным для нормального разработчика в большинстве случаев.
13 май 20, 12:03    [22131916]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46599
unregestered
bob1970

Как-то революционно выглядит. Можешь подробнее раскрыть мысль.


Коротко: ООП это частный случай Dynamic dispatch, когда выбор метода идёт только на основе одного типа. Однако в бизнес-приложениях (и многих других) обычно взаимодействуют 2-3 объекта и невозможно выделить главный.

В одном из семинаров по Haskell (кажется Виталия Брагилевского)
докладчик сказал интересную вещь. Вобщем по его мнению ООП и ФП
подход похожи примерно как разворот на 90 градусов всех абстракций.
В одном случае ты вкладываешся в базовые классы. Реализуешь их.
А в другом - в функции и типы. Стоимость поддержки и внесения изменений
- примерно одинакова.
13 май 20, 12:27    [22131936]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5298
unregestered

API - это не GUI.


Ок. Значит не делали.

unregestered

Я не понимаю, про что вы. При чём тут иерархия. Речь шла про то что [receiver message] в Objective-C эквивалентно receiver.message() в других языках программирования


Не совсем. Т.к. обычно

@Override
public void execute(Event event) {
    super.execute(event)
    ...
}


unregestered

Сколько вы программ переделали? Я - миллион, включая свои собственные (хотя казалось бы уж тут-то качество должно быть на высоте).
И я вас уверяю, что это: 1) неизбежно, 2) не является чем-то запредельным для нормального разработчика в большинстве случаев.


Судя по вашим тезисам вы не работали с "кровавым Ынытрпрайзом" и дремучим легаси кодом.
Который переписывать очень дорого, а нужно "тут немножко поправить".
И как бы мне приходилось "немного править" в dBase-подобных ЯП.
Где кроме процедурного программирования ничего в принципе нет.
Скажем так, это было познавательно.
13 май 20, 12:53    [22131974]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3292
mayton

докладчик сказал интересную вещь. Вобщем по его мнению ООП и ФП
подход похожи примерно как разворот на 90 градусов всех абстракций.

В целом мысль правильная,но в том то и дело что не всех, он немного лукавит.

mayton

В одном случае ты вкладываешся в базовые классы. Реализуешь их.
А в другом - в функции и типы.

Суть ты уловил, но неправильно формулируешь. Имеется ввиду решение так называемой expression problem(она заключается в том, что надо найти способ добавить новые функции и новые типы максимально используя уже дотупные и так, чтобы не сломать уже реализованный функционал)
И тут действительно, ФП и ООП перпендикулярны. Так как в ФП данные и поведение разделены, то в нем легко добавить новую функцию, но невозможно добавить новый тип, не сломав уже реализованные функции.
В ООп наоборот - легко добавить еще одну реализацию, но невозможно добавить метод в интерфейс не сломав все предыдущие реализации.
В принципе это все решаемо,в ФП через typeclass, в ООП - object algebras.

Разница же между ФП и ООП всего лишь в том что под ФП подведена математическая основа, а ООП - это скорее сбор эмпирических практик, которые все вольны трактовать по своему. По факту immutability, отсутсвие side-effects. pure функции, lambdas, streams etc - это все совершенно легко можно использовать и в ООП(на математической основе, а не следуя всяким высосаным SOLID). И мир к этому и идет. По сути, если убрать из ООП subtype polymorphism и наследование - то мы и придем к ФП. Все беды ООП именно из-за них. Наследование нарушает инкапсуляцию. точка.

mayton

Стоимость поддержки и внесения изменений
- примерно одинакова.

Поэтому это не правда
13 май 20, 15:06    [22132136]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mayton
Member

Откуда: loopback
Сообщений: 46599
забыл ник

mayton

Стоимость поддержки и внесения изменений
- примерно одинакова.

Поэтому это не правда

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

Не сможем зайти в одну и туже воду дважды.
13 май 20, 15:27    [22132183]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
Я бы назвал столпами ФП: иммутабельность, ленивость и хвостовая рекурсия. Всякие операции с коллекциями, а-ля стримы, мапперы, редусеры ни в коем мере не является функциональной спецификой, ни с теоретической, ни с практической точки зрения. Операции с коллекциями есть чуть ли не во всех языках.
13 май 20, 17:39    [22132285]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Java Ответить