|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2020, 23:15 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 Что думаете? а можно какие-то более осмысленные темы создавать? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2020, 23:17 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, Нужно создать объект в который передать сервисы spring. Возможно, создаваемый класс будет создавать другие классы, которым тоже будут нужны спринговые сервисы, компоненты. Для чего. Ну например в многопоточном приложении. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2020, 23:49 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 00:13 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Покажи реальный пример зачем это. В большинстве мест это выглядит как дичь. +1 решение - это использовать @Configurable - она как раз создана для такого дела. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 00:14 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 Leonid Kudryavtsev, Нужно создать объект в который передать сервисы spring. Возможно, создаваемый класс будет создавать другие классы, которым тоже будут нужны спринговые сервисы, компоненты. Для чего. Ну например в многопоточном приложении. Зачем?! Когда можно создавать многопоточные приложения в рамках Spring. Тут, либо Spring, либо он (Spring) нафиг не нужен. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 06:04 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
SpringMan Покажи реальный пример зачем это. В большинстве мест это выглядит как дичь. +1 решение - это использовать @Configurable - она как раз создана для такого дела. Спасибо! То что надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 07:29 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
SpringMan Покажи реальный пример зачем это навскидку только в каком-то легаси коде по бырику внедрить кусок из спринга ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 09:25 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
chpasha SpringMan Покажи реальный пример зачем это навскидку только в каком-то легаси коде по бырику внедрить кусок из спринга Нафига в легаси Spring?! ИМХО он там не нужен. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 09:47 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Тут КМК - слабая мотивация. Более интересно когда в стеке стоят два фреймворка и нужно обеспечить какой-то порядок инициализации бинов в этих условиях. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 10:16 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Тут КМК - слабая мотивация. Более интересно когда в стеке стоят два фреймворка и нужно обеспечить какой-то порядок инициализации бинов в этих условиях. Если это два фреймворка DI, то это "плохая ситуация", лучше в неё не "вляпываться". Если же говорить за Spring, то у него есть куча обёрток для различных фреймворков, через которые в Spring с ними (фреймворками) надо работать. Положение конечно так себе из разряда "положено - ешьте". Но зато "думать" не надо. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 12:44 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mad_nazgul Нафига в легаси Spring?! ИМХО он там не нужен. :-) ну например ты переписываешь легаси на спринг, но частями, т.е. есть уже новые вещи и есть еще куча старья и вот надо в старье уже заюзать нечто из нового, что уже мигрировали. по-крайней мере я подобной фигней тоже разродился лет 10 назад. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 14:55 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
А через 10 лет Spring станет легаси и тогда все будут рвать волосы на груди и кричать "ах зачем мы ввели столько бинов? Надо было больше pure-vanilla-java, тогда-бы и портировать легче." ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 15:00 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton ах зачем мы ввели столько бинов? Надо было больше pure-vanilla-java, тогда-бы и портировать легче ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 15:48 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
chpasha mad_nazgul Нафига в легаси Spring?! ИМХО он там не нужен. :-) ну например ты переписываешь легаси на спринг, но частями, т.е. есть уже новые вещи и есть еще куча старья и вот надо в старье уже заюзать нечто из нового, что уже мигрировали. по-крайней мере я подобной фигней тоже разродился лет 10 назад. Если переписывать с легаси (JavaEE) на Spring, то тогда имеет смысл переписывать на SpringBoot и микросервисы. Так что опять фреймворки не будут пересекаться . А так из Spring вполне себе можно работать с JavaEE. Наоборот я вроде бы не слыхал. Хотя можно, через контекст Spring. Но там есть "подводные камни", особенно при работе с statefull бинами. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 16:07 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
chpasha mayton ах зачем мы ввели столько бинов? Надо было больше pure-vanilla-java, тогда-бы и портировать легче ИМХО пока единственный смысл написания бинов в стиле pure-vanilla-java это unit-тесты. Не надо поднимать контекст для тестирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 16:09 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mad_nazgul с легаси (JavaEE) может я неправильно термин legacy использовал, для меня это любое говно мамонта собранное на коленке. JavaEE там даже и рядом не лежало ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 16:54 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Zzz79, почитай по ключевым словам AOP, Dynamic Proxy, и еще CGLib опционально. Про CgLib я тоже с тобой буду читать ибо надо. Или скоро понадобиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 19:27 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Zzz79 вот я понимаю проблема- генеришь генератором класс - а у тебя половина класса откуда то подсасывается а другая генерится) дебагер тут бессилен) твоя задача найти откуда идет хардкод в геренерированый класс и очень печально что ctrl+shift+f в идее радотает очень плохо Так то всегда так, когда руки из жопы растут. Ну тебе как новичку еще простительно, но если у вас ни один сеньор не способен разобраться с такой проблемой - то боюсь индипроект у тебя, а не у остальных ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 19:59 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
chpasha mad_nazgul с легаси (JavaEE) может я неправильно термин legacy использовал, для меня это любое говно мамонта собранное на коленке. JavaEE там даже и рядом не лежало Как раз JavaEE и есть это говно мамонта. Хотя Spring то же самое. Но Spring хотя бы рефакторить в SpringBoot попроще. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 07:13 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mad_nazgul Если переписывать с легаси (JavaEE) на Spring, то тогда имеет смысл переписывать на SpringBoot и микросервисы. Так что опять фреймворки не будут пересекаться . Вы чо там курите то вообще, лол. Spring Boot = Spring + некоторый набор автоконфигурационных бинов + bootloader. А микросервисы это вообще не фреймворк и не библиотека, а архитектурный паттерн. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 10:37 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Мне кажется вся история фреймворков последних 20 лет - это история человеческих амбиций. Тоесть сначала ставится некая амбициозная цель. Она как-то достигается. Потом приходят другие люди и говорят - это всё было - гуано и мы насетапим свой фреймворк лучше. А критерий лучше - это как можно более непохоже на то что было. Вот таким вот бесмысленным итеративным процессом рождаются фреймворки чтобы через 3-5 лет их идея снова и снова повторилась еще раз. Причем каждый новый фреймворк навязывает еще и религиозные идеи. И адепты этих идей не похожи на инженеров. А больше похожи на этих мальчиков с узко посаженными глазками которые в подземных переходах раздают книжки типа Свидетелей Иеговы или Кришнаитов . И не дай бох вам начать с ними спорить.... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 10:46 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Ну к спрингу это не относится, спринг появился 16 лет назад и точно переживёт ещё сотню, другую, фреймворков. Все существующие ,так называемые, "альтернативы" просто не могут соревноваться с ним по объёму фич и зрелости. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 10:56 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Ну с back все более менее стабильно и понятно. А вот с фронтом... Ойой. Вот кто из фронтовиков скажет сколько фреймворков хотя-бы 80% рынка покрывают. Наверное за сотню названий зайдет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 11:05 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Zzz79 так как в наших проектах полностью отсуствует джва док) привет коллега ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 12:58 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Если развивать идеи Роберта Мартина то в каментах нужно писать только то что НЕВОЗМОЖНО описать кодом. Я обычно в каментах пишу о намерениях например выкосить этот код в будущем. Кстати у Бугаенко были тоже интересные идеи в части понимания кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 13:14 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
На одном из проектов часто приходилось разбираться с чужим кодом Обычно проблема не с "что делает это код", а самое главное "зачем он это делает и нахрена вообще все это было надо" ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 13:25 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev На одном из проектов часто приходилось разбираться с чужим кодом Обычно проблема не с "что делает это код", а самое главное "зачем он это делает и нахрена вообще все это было надо" Да. Вот еще одно интересное наблюдение. С связи с SingleResponsibility каждый компонент должен делать 1 узкую задачу. Но этих простых компонентов - тыщи. Каждый из них - как кирпичик LEGO сам по себе не несет особого смысла. Но будучи собранными в кучу - они представляют какой-то смысл. И получается что JavaDoc должен описиывать не SingleResp-class, на некий агрегат или композит из множества компонентов. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 14:39 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Да. Вот еще одно интересное наблюдение. С связи с SingleResponsibility каждый компонент должен делать 1 узкую задачу. Но этих простых компонентов - тыщи. Каждый из них - как кирпичик LEGO сам по себе не несет особого смысла. Но будучи собранными в кучу - они представляют какой-то смысл. И получается что JavaDoc должен описиывать не SingleResp-class, на некий агрегат или композит из множества компонентов. И тут мы приходим к ситуации, когда в сервисе spring создается объект, ктр. для решения своих задач создает свои объекты и т.д. И там где-то далеко в этой куче понадобится доступ к какому-нибудь сервису spring. И что делать? Как обратиться к spring? Это я к теме топика. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 15:03 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 mayton Да. Вот еще одно интересное наблюдение. С связи с SingleResponsibility каждый компонент должен делать 1 узкую задачу. Но этих простых компонентов - тыщи. Каждый из них - как кирпичик LEGO сам по себе не несет особого смысла. Но будучи собранными в кучу - они представляют какой-то смысл. И получается что JavaDoc должен описиывать не SingleResp-class, на некий агрегат или композит из множества компонентов. И тут мы приходим к ситуации, когда в сервисе spring создается объект, ктр. для решения своих задач создает свои объекты и т.д. И там где-то далеко в этой куче понадобится доступ к какому-нибудь сервису spring. И что делать? Как обратиться к spring? Это я к теме топика. Я не совсем понял суть проблемы. В Спринг приложении ты в любой момент можешь дернуть глобальный объект контекста и получить в руке то что надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 15:07 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Я не совсем понял суть проблемы. В Спринг приложении ты в любой момент можешь дернуть глобальный объект контекста и получить в руке то что надо. Согласен. Но как-то некрасиво. Решение с ктр начался топик этим и не нравится. Подсказали @Configurable. Похоже на правду. Очень похоже. Надо только посмотреть как в тестах будет выглядеть. Вроде бы нормально на первый взгляд. Детально не смотрел еще. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 16:11 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 И тут мы приходим к ситуации, когда в сервисе spring создается объект, ктр. для решения своих задач создает свои объекты и т.д. И там где-то далеко в этой куче понадобится доступ к какому-нибудь сервису spring. И что делать? Как обратиться к spring? Это я к теме топика. Что это за такие объекты, что из них надо дергать спринг? Если так происходит, то что-то не то со структурой проекта. Можешь на пальцах показать пример? - возможно легче все порефакторить, чем тащить @Configurable ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 17:08 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Ну это как из С++ вызывать Python который снова вызывает С++. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 17:16 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
SpringMan, Можно и на примерах. Только толку ноль, свалимся в холивар "Spring головного мозга"/"Вы не умеете его готовить". И мне не нужно решать какой-то конкретный use-case. Я бы немного шире взял. Что мы пишем в Service? Бизнес логику. Какое-то поведение решаем созданием объектов. Но далеко от сервиса не уходим, т.к. там все зависимости. Держим все время в голове, что сервис это одиночка, без состояния. С учетом этих ограничений часто пишем логику в самом сервисе. Он становится жирным, забиваем на single-responsibility. Да, я в курсе про слои и т.п. Тесты отдельная песня. Зачем то поднимаем SpringRunner, боремся с ним, тесты тормозят. Представь другую схему. Создавай объекты какие хочешь. Его созданием, поведением сам рулишь. Он может быть и не одиночка, и доступен GC. А этому объекту вдруг понадобиться доступ к например репозиторию. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 18:31 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Если на примерах - нельзя пояснить то наверное что-то туго с обоснованием. Объясняющий или стесняется своей архитектуры, или сам ее не понимает но просто верит, ибо много кода написано да и привычка. Сильная вещь. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 19:17 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 19:17 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2020, 23:05 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 SpringMan, Можно и на примерах. Только толку ноль, свалимся в холивар "Spring головного мозга"/"Вы не умеете его готовить". И мне не нужно решать какой-то конкретный use-case. Я бы немного шире взял. Что мы пишем в Service? Бизнес логику. Какое-то поведение решаем созданием объектов. Но далеко от сервиса не уходим, т.к. там все зависимости. Держим все время в голове, что сервис это одиночка, без состояния. С учетом этих ограничений часто пишем логику в самом сервисе. Он становится жирным, забиваем на single-responsibility. Да, я в курсе про слои и т.п. Ну как бы решение предлагают во всяких книжках по TDD. :-) Если придерживаться данной методологии разработки, то по заверениям, такого не будет. Сейчас я себя "тренирую" не использовать аннотации для создание компонентов в Spring, только в классе конфигураций. И все внедрения зависимостей делать через конструктор. bob1970 Тесты отдельная песня. Зачем то поднимаем SpringRunner, боремся с ним, тесты тормозят. Да - поднятие контекста тяжелая вещь. Но она нужна не для всех тестов, а только которые тестируют поведение всего приложения. Для остального должны использоваться юнит-тесты. Как минимум в теории. Но т.к. большинству лень, то обычно поднимают весь контекст, чтобы протестировать что "2+2 == 4". bob1970 Представь другую схему. Создавай объекты какие хочешь. Его созданием, поведением сам рулишь. Он может быть и не одиночка, и доступен GC. А этому объекту вдруг понадобиться доступ к например репозиторию. То что вы предлагаете, это плохо. Приложение становится "хрупким". написать юнит-тест невозможно. Я и с такими приложениями сталкивался.... Там изменишь в одном месте, а у тебя все приложение стает колом. Нужно разделять поведение. И тут либо через if-чики. Или глубокий рефакторинг. Т.к. if-чик это быстро. То потом после 3-5 поколений программистов видишь объект на 10000 строк if-ов в одном методе. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2020, 06:25 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mad_nazgul Да - поднятие контекста тяжелая вещь. Но она нужна не для всех тестов, а только которые тестируют поведение всего приложения. Для остального должны использоваться юнит-тесты. Как минимум в теории. Но т.к. большинству лень, то обычно поднимают весь контекст, чтобы протестировать что "2+2 == 4". Это не правда про "тяжёлое" поднятие контекста. Вы просто не умеете его готовить ) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2020, 10:37 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered mad_nazgul Да - поднятие контекста тяжелая вещь. Но она нужна не для всех тестов, а только которые тестируют поведение всего приложения. Для остального должны использоваться юнит-тесты. Как минимум в теории. Но т.к. большинству лень, то обычно поднимают весь контекст, чтобы протестировать что "2+2 == 4". Это не правда про "тяжёлое" поднятие контекста. Вы просто не умеете его готовить ) Это смотря с чем сранивать. Как минимум Код: java 1. 2. 3. 4. 5. 6.
быстрее исполняется чем Код: java 1. 2. 3. 4. 5. 6. 7. 8.
<:o) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2020, 14:28 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Попробовал оценить производительность Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56.
Результаты Яндекс.Танк 1000 запросов, 10 сек Получается вполне можно пользоваться @Configurable. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 17:44 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Какое отношение имеет яндекс к теме топика? Чьорт вась побери... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 19:01 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton, Яндекс.Танк бесплатный инструмент нагрузочного тестирования. По ссылке просто результаты тестов. Результаты Впрочем уже не важно. Метод работает без потери производительности. Пользоваться можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 19:14 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
На фига здесь лишний интерфейс IServiceForFree ?? Это же не, прости госпади, EJB 2.1, где интерфейсы надо было на каждый чих создавать. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 19:54 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered На фига здесь лишний интерфейс IServiceForFree ?? Это же не, прости госпади, EJB 2.1, где интерфейсы надо было на каждый чих создавать. Вот это по нашему, по бразильски. Да нафига нужны все эти интерфейсы? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2020, 20:51 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Куча быдлкодеров перешло с EJB на спринг и начинают копировать ужасные EJB практики там, где это нафиг не нужно. FizzBuzz Enterprise Edition ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2020, 15:46 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
А что у разработчиков Node - вообще таких проблем нет? Складывается впечатление что им открыто - истинное буддийское знание. А мы (java-исты) - как лохи позорные?... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.04.2020, 16:38 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered На фига здесь лишний интерфейс IServiceForFree ?? Это же не, прости госпади, EJB 2.1, где интерфейсы надо было на каждый чих создавать. Не сразу дошел смысл этого комментария. А смысл прост. Не создавать интерфейс, если предполагается единственная реализация. Полностью согласен. В данном абстрактном примере хотел подчеркнуть, что это какая-то спринговая зависимость. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2020, 09:18 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Идея овер-инжинернига описана в статье на хабре https://habr.com/en/post/113128/ К сожалению в Spring заходят новички которых сразу учат длинным реализациям. Думаю что через лет 5 такого учения они будут уже не в состоянии написать простой код. Такая проф-деформация специфичная именно для Spring-сегмента. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2020, 14:00 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Идея овер-инжинернига описана в статье на хабре https://habr.com/en/post/113128/ К сожалению в Spring заходят новички которых сразу учат длинным реализациям. Думаю что через лет 5 такого учения они будут уже не в состоянии написать простой код. Такая проф-деформация специфичная именно для Spring-сегмента. Ну типичный карго-культ. Просто учатся по "делай как я", не задавая вопросы. Имхо это все же лучше, чем класс на 10 000 строк с методом содержащим "if else if" на 5000 - 7000 строк. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2020, 07:59 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Идея овер-инжинернига описана в статье на хабре https://habr.com/en/post/113128/ К сожалению в Spring заходят новички которых сразу учат длинным реализациям. Думаю что через лет 5 такого учения они будут уже не в состоянии написать простой код. Такая проф-деформация специфичная именно для Spring-сегмента . По-сути в этом и был мой вопрос. Излишняя привязанность к spring, ктр. накладывает определенные ограничения (одиночка, stateless,.... ). В результате появляется связАнность компонентов, т.к. очень просто воткнуть бин спринга, тем самым опять привязаться к спрингу. Вижу конструкторы с 5-ю и более аргументов. Максимальное размещение логики в в бинах спринга, отсюда процедурщина в полный рост. Всякие там паттерны и прочие SOLID идут лесом. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2020, 10:15 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 По-сути в этом и был мой вопрос. Излишняя привязанность к spring, ктр. накладывает определенные ограничения (одиночка, stateless,.... ). В результате появляется связАнность компонентов, т.к. очень просто воткнуть бин спринга, тем самым опять привязаться к спрингу. Вижу конструкторы с 5-ю и более аргументов. Максимальное размещение логики в в бинах спринга, отсюда процедурщина в полный рост. Всякие там паттерны и прочие SOLID идут лесом. Тут вчера был ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 05:57 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 Максимальное размещение логики в в бинах спринга, отсюда процедурщина в полный рост. Всякие там паттерны и прочие SOLID идут лесом. На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр. Для многих бизнес-приложений больше характерна модель с множеством взаимодействующих объектов, где сложно выделить главный. В этом случае более подходящей моделью является Multiple Dispatch , которая, правда, очень плохо реализована в языках программирования. Обычно диспетчеризация идёт по одному типу, что и является ООП (правда, ООП ещё подразумевает инкапсуляцию). Так что "процедурщина" в бизнес-приложениях это не маргинальщина, а вполне естественное отображение предметной области. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 06:24 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр. Для многих бизнес-приложений больше характерна модель с множеством взаимодействующих объектов, где сложно выделить главный. Спорное место. Но главное ниже. unregestered В этом случае более подходящей моделью является Multiple Dispatch , которая, правда, очень плохо реализована в языках программирования. Обычно диспетчеризация идёт по одному типу , что и является ООП (правда, ООП ещё подразумевает инкапсуляцию). Так что "процедурщина" в бизнес-приложениях это не маргинальщина, а вполне естественное отображение предметной области . Как-то революционно выглядит. Можешь подробнее раскрыть мысль. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 08:46 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр. С чего вы взяли, что ООП подходит для описание объектов GUI? ;-) Вы писали свой GUI? unregestered Для многих бизнес-приложений больше характерна модель с множеством взаимодействующих объектов, где сложно выделить главный. В этом случае более подходящей моделью является Multiple Dispatch , которая, правда, очень плохо реализована в языках программирования. Обычно диспетчеризация идёт по одному типу, что и является ООП (правда, ООП ещё подразумевает инкапсуляцию). Как минимум видел реализацию, где взаимодействие между объектами реализовано через "сообщения" (не используя очереди сообщений) Т.е. "главным объектом" был инфраструктурный объект, который перенаправлял сообщения. unregestered Так что "процедурщина" в бизнес-приложениях это не маргинальщина, а вполне естественное отображение предметной области. Именно, что маргинальщина, по принципу сделать быстро сейчас. Потом долго и мучительно переделывать потом. Ну и обычно для бакендеров формулируют задачу по реалиазции бизнес-процессов в процедурном стиле, ещё в виде веселых картинок. Вот они как настоящие акыны делают "что вижу, то пою". :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 10:52 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
chpasha ну например ты переписываешь легаси на спринг, но частями, т.е. есть уже новые вещи и есть еще куча старья и вот надо в старье уже заюзать нечто из нового, что уже мигрировали. по-крайней мере я подобной фигней тоже разродился лет 10 назад. Бгг, когда коту делать нечего он яйца лижет. А современный программист переписывает проект с одного фреймворка на другой точно такой же но модный в этом сезоне. А когда придет новый сезон и новый фреймворк - примется переписывать то же самое, но уже на него. Ну ничего, главное что денежка капает. А то, что занят абсолютно бессмысленной работой - ну так смысл на хлеб не намажешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:20 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Ржавый гвоздь Бгг, когда коту делать нечего он яйца лижет [конспектирует, высунув язык] Ржавый гвоздь переписывает проект с одного фреймворка на другой точно такой же но модный в этом сезоне. А когда придет новый сезон и новый фреймворк - примется переписывать то же самое, но уже на него. Ну ничего, главное что денежка капает. А то, что занят абсолютно бессмысленной работой - ну так смысл на хлеб не намажешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:49 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Ржавый гвоздь Бгг, когда коту делать нечего он яйца лижет. А современный программист переписывает проект с одного фреймворка на другой точно такой же но модный в этом сезоне. А когда придет новый сезон и новый фреймворк - примется переписывать то же самое, но уже на него. Ну ничего, главное что денежка капает. А то, что занят абсолютно бессмысленной работой - ну так смысл на хлеб не намажешь. Ну бывает надо переписывать на стильномодномолодежный фреймворк. Вот например щас у меня проект на jBoss seam, который лет пять как "сдох". Переводить его на JSF - ну такое. Так что сейчас переписывают на React + SpringBoot. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 13:49 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mad_nazgul С чего вы взяли, что ООП подходит для описание объектов GUI? ;-) Вы писали свой GUI? :-) Конечно писал лол mad_nazgul Как минимум видел реализацию, где взаимодействие между объектами реализовано через "сообщения" (не используя очереди сообщений) Т.е. "главным объектом" был инфраструктурный объект, который перенаправлял сообщения. :-) "Сообщение" (например в Object C) это всего лишь навсего вызов метода. mad_nazgul Именно, что маргинальщина, по принципу сделать быстро сейчас. Потом долго и мучительно переделывать потом. Ну и обычно для бакендеров формулируют задачу по реалиазции бизнес-процессов в процедурном стиле, ещё в виде веселых картинок. Вот они как настоящие акыны делают "что вижу, то пою". :-) "Переделывание", как вы выражаетесь, это неотъемлемая часть процесса разработки в принципе, и никак не связана со стилем программирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 14:25 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
bob1970 Как-то революционно выглядит. Можешь подробнее раскрыть мысль. Коротко: ООП это частный случай Dynamic dispatch, когда выбор метода идёт только на основе одного типа. Однако в бизнес-приложениях (и многих других) обычно взаимодействуют 2-3 объекта и невозможно выделить главный. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 14:30 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered bob1970 Как-то революционно выглядит. Можешь подробнее раскрыть мысль. Коротко: ООП это частный случай Dynamic dispatch, когда выбор метода идёт только на основе одного типа. Однако в бизнес-приложениях (и многих других) обычно взаимодействуют 2-3 объекта и невозможно выделить главный. Есть мнение что все немного наоборот, что multimethods это разновидность ООП, как и prototype-based languages, а не наоборот. Хотя и то и то мнение мне кажется немного натянутым. Ну и в любом случае мне кажется что ФП уделывает все эти парадигмы на раз-два ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2020, 15:00 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник Ну и в любом случае мне кажется что ФП уделывает все эти парадигмы на раз-два Программер должен знать разные парадигмы и архитектурные паттерны и понимать где что применимо. Я уже давно оцениваю языки с сугубо практической точки зрения: поддержка IDE, билд тулов, стат-анализаторов, библиотек, фреймворков, дебагеров, мониторинговых тулов, удобство рефакторинга, быстрота компиляции и работы итд итп Всё остальное это свистелки и перделки, как выражался товарищ Дейкстра. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 04:01 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered Конечно писал лол Вот прям API для рисования окошек, менюшечек и прочего? unregestered "Сообщение" (например в Object C) это всего лишь навсего вызов метода. Не только, там еще определенная иерархия классов. unregestered "Переделывание", как вы выражаетесь, это неотъемлемая часть процесса разработки в принципе, и никак не связана со стилем программирования. Ещё как связана. Переделать можно всё, вопрос в цене. Стоимость каждого последующего изменения процедурно написанной программы стремиться к бесконечности. ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 06:55 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mad_nazgul Вот прям API для рисования окошек, менюшечек и прочего? API - это не GUI. mad_nazgul Не только, там еще определенная иерархия классов. Я не понимаю, про что вы. При чём тут иерархия. Речь шла про то что [receiver message] в Objective-C эквивалентно receiver.message() в других языках программирования mad_nazgul Ещё как связана. Переделать можно всё, вопрос в цене. Стоимость каждого последующего изменения процедурно написанной программы стремиться к бесконечности. ;-) Сколько вы программ переделали? Я - миллион, включая свои собственные (хотя казалось бы уж тут-то качество должно быть на высоте). И я вас уверяю, что это: 1) неизбежно, 2) не является чем-то запредельным для нормального разработчика в большинстве случаев. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 12:03 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered bob1970 Как-то революционно выглядит. Можешь подробнее раскрыть мысль. Коротко: ООП это частный случай Dynamic dispatch, когда выбор метода идёт только на основе одного типа. Однако в бизнес-приложениях (и многих других) обычно взаимодействуют 2-3 объекта и невозможно выделить главный. В одном из семинаров по Haskell (кажется Виталия Брагилевского) докладчик сказал интересную вещь. Вобщем по его мнению ООП и ФП подход похожи примерно как разворот на 90 градусов всех абстракций. В одном случае ты вкладываешся в базовые классы. Реализуешь их. А в другом - в функции и типы. Стоимость поддержки и внесения изменений - примерно одинакова. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 12:27 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered API - это не GUI. Ок. Значит не делали. unregestered Я не понимаю, про что вы. При чём тут иерархия. Речь шла про то что [receiver message] в Objective-C эквивалентно receiver.message() в других языках программирования Не совсем. Т.к. обычно Код: java 1. 2. 3. 4. 5.
unregestered Сколько вы программ переделали? Я - миллион, включая свои собственные (хотя казалось бы уж тут-то качество должно быть на высоте). И я вас уверяю, что это: 1) неизбежно, 2) не является чем-то запредельным для нормального разработчика в большинстве случаев. Судя по вашим тезисам вы не работали с "кровавым Ынытрпрайзом" и дремучим легаси кодом. Который переписывать очень дорого, а нужно "тут немножко поправить". И как бы мне приходилось "немного править" в dBase-подобных ЯП. Где кроме процедурного программирования ничего в принципе нет. Скажем так, это было познавательно. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 12:53 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton докладчик сказал интересную вещь. Вобщем по его мнению ООП и ФП подход похожи примерно как разворот на 90 градусов всех абстракций. В целом мысль правильная,но в том то и дело что не всех, он немного лукавит. mayton В одном случае ты вкладываешся в базовые классы. Реализуешь их. А в другом - в функции и типы. Суть ты уловил, но неправильно формулируешь. Имеется ввиду решение так называемой expression problem(она заключается в том, что надо найти способ добавить новые функции и новые типы максимально используя уже дотупные и так, чтобы не сломать уже реализованный функционал) И тут действительно, ФП и ООП перпендикулярны. Так как в ФП данные и поведение разделены, то в нем легко добавить новую функцию, но невозможно добавить новый тип, не сломав уже реализованные функции. В ООп наоборот - легко добавить еще одну реализацию, но невозможно добавить метод в интерфейс не сломав все предыдущие реализации. В принципе это все решаемо,в ФП через typeclass, в ООП - object algebras. Разница же между ФП и ООП всего лишь в том что под ФП подведена математическая основа, а ООП - это скорее сбор эмпирических практик, которые все вольны трактовать по своему. По факту immutability, отсутсвие side-effects. pure функции, lambdas, streams etc - это все совершенно легко можно использовать и в ООП(на математической основе, а не следуя всяким высосаным SOLID). И мир к этому и идет. По сути, если убрать из ООП subtype polymorphism и наследование - то мы и придем к ФП. Все беды ООП именно из-за них. Наследование нарушает инкапсуляцию. точка. mayton Стоимость поддержки и внесения изменений - примерно одинакова. Поэтому это не правда ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 15:06 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник mayton Стоимость поддержки и внесения изменений - примерно одинакова. Поэтому это не правда Да. Она неодинакова хотя-бы потому что мы никогда не найдем двух специалистов одинакового левла ФП и ООП чтоб задать им одну и ту-же задачу и сравнить перформанс. Не сможем зайти в одну и туже воду дважды. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 15:27 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Я бы назвал столпами ФП: иммутабельность, ленивость и хвостовая рекурсия. Всякие операции с коллекциями, а-ля стримы, мапперы, редусеры ни в коем мере не является функциональной спецификой, ни с теоретической, ни с практической точки зрения. Операции с коллекциями есть чуть ли не во всех языках. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 17:39 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Вчера рассеянно просматривал лекции Юрия Жлобы по Эрланг. Меня не столько язык итересовал сколько брокер Rabbit-Mq и архитектура его устойчивости к сбоям. Поскольку он написан на Erlang то я искал некоторые ответы на вопросы в самом языке. И вот что я заметил. Есть семейство языков Erlang/Lisp/Prolog у которых очень много похожих свойств. Причем настолько похожих что кажется что они концепции просто копировали. И похожести в них больше чем в С++/Java/C#. От пролога - предикаты и нотация записи процедур запятая-запятая-точка. От Лиспа - списки. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 17:46 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered Я бы назвал столпами ФП: иммутабельность, ленивость и хвостовая рекурсия. Всякие операции с коллекциями, а-ля стримы, мапперы, редусеры ни в коем мере не является функциональной спецификой, ни с теоретической, ни с практической точки зрения. Операции с коллекциями есть чуть ли не во всех языках. Ленивость и хвостовая рекурсия это следствия, а не причины(при чем первое вообще присутствует далеко не во всех ФП-языках). Столпы ФП - pure, total, side-effects free функции + immutable data + high-order-functions(частным случаем которых как раз и являются стримы редьюсеры и т.п) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 17:46 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Вчера рассеянно просматривал лекции Юрия Жлобы по Эрланг. Меня не столько язык итересовал сколько брокер Rabbit-Mq и архитектура его устойчивости к сбоям. Поскольку он написан на Erlang то я искал некоторые ответы на вопросы в самом языке. И вот что я заметил. Есть семейство языков Erlang/Lisp/Prolog у которых очень много похожих свойств. Причем настолько похожих что кажется что они концепции просто копировали. И похожести в них больше чем в С++/Java/C#. От пролога - предикаты и нотация записи процедур запятая-запятая-точка. От Лиспа - списки. Так а что в этом удивительного? Закономерное развитие, когда новые языки вбирают в себя хорошо работающие идеи из старых. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 17:55 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Я-бы добавил вывод типов и генерики и паттерн-матчинг. 2 пункт вообще очень **ёво реализовано в Java. То что в Java навзали Generics вообще не имело право так называться. Их можно было назвать compile-time-guards (CTG) или что-то вроде этого. И поведение примитивных типов по отношению к CTG вообще не определено. Тоесть вы старалить. Описывали обобщенный алгоритм но не можете применить его к целому числу. Хотя сам бох велел скомпилировать хардкод для целого числа но ... компиллятор вставляет туда Object с RTTI Integer семантикой. Какие накладные при этом несет код - сложно представить. Я догадываюсь почему Одерский плюнул и стал делать свой язык. Хотя он ведь был коммитером самых первых версий JDK в эпоху Sun. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 17:55 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Я догадываюсь почему Одерский плюнул и стал делать свой язык. Хотя он ведь был коммитером самых первых версий JDK в эпоху Sun. Так он прямо об этом говорит. А сделали так коряво потому что backward-compatibility считали важнее чем теоретическая правильность ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 17:57 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Так для JVM все равно. Эту механику можно было реализовать еще в эпоху JDK 1.1. Просто компиллятор делал бы больше преобразований. Честное слово возьму ASM/CGlib и насетаплю свой Java-Kava с блекджеком и женщинами. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 18:04 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered На самом деле область применения ООП достаточно узкая. Объекты хороши когда есть один "изолированный" объект с состоянием и своим поведением. Обычно ООП хорош для описание объектов операционной системы: окно, принтер, кнопка и пр. +++ unregestered В этом случае более подходящей моделью является Multiple Dispatch , которая, правда, очень плохо реализована в языках программирования. Статью прочитал - но не понял. Пусть у меня есть необходимость задать некую операцию (например "оплата") над двумя классами объектов. Платеж и начисление. При этом может быть несколько типов платежа и несколько вариантов оплаты начисления. К примеру: обычная оплата, оплата из аванса и так далее. И разные классы начислений: обычное начисление, пени/штраф и так далее. В данном примере, нужно реализовать 2x2=4 варианта. Система живет, появляется новый класс начисления, нужно новое поведение. Оп...ля... уже нужно 2x3=6 вариантов.... Система живет, появляется еще новый класс оплаты. Эквайрингу, сбербанк-бизнес-онлайн, оплата по QR-CODE. Оп... 5x3 = 15 вариантов Функции. Появились новые классы начислений, требуют разнести воду, канализацию, экологию раздельно. 5x6=30 вариантов. Плохо я себе это представляю, на уровне компилятора. В классической программе, от такой мешанины получится спагетти код из if'ов, где кол-во if'ов будет __значительно__ меньше полного набора вариантов M x N В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 18:44 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Есть семейство языков Erlang/Lisp/Prolog у которых очень много похожих свойств. Первая версия Эрланга была написана на Прологе, оттуда и заимствование синтаксических конструкций. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:13 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Есть семейство языков Erlang/Lisp/Prolog у которых очень много похожих свойств. Между Erlang-ом и нет вообще ничего общего, ибо пролог это логическое программирование с недетерминированным (в общем случае) поведением програм ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:32 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste Необязательно. Реализуй только те что тебе конкретно нужны, речь не идет о cartesian product ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:36 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник Ленивость и хвостовая рекурсия это следствия, а не причины(при чем первое вообще присутствует далеко не во всех ФП-языках). Столпы ФП - pure, total, side-effects free функции + immutable data + high-order-functions(частным случаем которых как раз и являются стримы редьюсеры и т.п) High-order functions это указатели на функции что ли? Так вызов функции с колбаком в С и ассемблере -это и есть high-order. Основная идея ФП - это неизменяемость состояний и чистота функций. Lazy присваивания и определения заменяют обычное присваивание, изменяющее состояние. Без хвостовой рекурсии нам придётся использовать циклы, которые тоже изменяют состояние. Если так "ФП" не имеет ленивости, то вряд ли его можно назвать ФП. Просто этот термин щас лепят куда не попадя. Кроме того, ленивость нужна для динамического программирования (в качестве аналога кэширования), если язык не меняет состояние то динамического программирование надо делать через кэширование. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:42 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton Я-бы добавил вывод типов и генерики и паттерн-матчинг. 2 пункт вообще очень **ёво реализовано в Java. Паттерн-матчинг это 3-яя парадигма наряду с функциональным программированием и процедурным. В Computer Science машина тьюринга - это процедурный подход, ламбда исчисление - это функциональный, а pattern-matching-у соответствуют нормальные алгорифмы Маркова. На самом деле, паттерн-матчинг плохо реализован в языках. На вскидку могу назвать только XSLT, пролог и JBoss Drools. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:50 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Статью прочитал - но не понял. Пусть у меня есть необходимость задать некую операцию (например "оплата") над двумя классами объектов. Платеж и начисление. При этом может быть несколько типов платежа и несколько вариантов оплаты начисления. К примеру: обычная оплата, оплата из аванса и так далее. И разные классы начислений: обычное начисление, пени/штраф и так далее. В данном примере, нужно реализовать 2x2=4 варианта. Система живет, появляется новый класс начисления, нужно новое поведение. Оп...ля... уже нужно 2x3=6 вариантов.... Система живет, появляется еще новый класс оплаты. Эквайрингу, сбербанк-бизнес-онлайн, оплата по QR-CODE. Оп... 5x3 = 15 вариантов Функции. Появились новые классы начислений, требуют разнести воду, канализацию, экологию раздельно. 5x6=30 вариантов. Плохо я себе это представляю, на уровне компилятора. В классической программе, от такой мешанины получится спагетти код из if'ов, где кол-во if'ов будет __значительно__ меньше полного набора вариантов M x N В парадигме из ссылки - нужно реализовывать полный набор M x N функций, большинство из которых будет тупым Copy-Paste Не нужно реализовывать 4 варианта, достаточно реализовать функции для базовых классов. Если вы напишете ещё одну функцию с более специфическим типом, то этот вариант будет "перекрывать" более универсальный. Это что-то типа полиморфизма, но по нескольким типам. Такая фича есть в груви ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:54 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered High-order functions это указатели на функции что ли? Так вызов функции с колбаком в С и ассемблере -это и есть high-order. По смыслу правильно, но вернее будет сказать что hof - это функции, которые могут принимать длругие функции как параметр либо возвращать функции(currying, closures). unregestered Основная идея ФП - это неизменяемость состояний и чистота функций. Именно об этом я и сказал unregestered Lazy присваивания и определения заменяют обычное присваивание, изменяющее состояние. Без хвостовой рекурсии нам придётся использовать циклы, которые тоже изменяют состояние. Именно поэтому они и являются следствием, а не причиной(immutability, не устану повторять "как я и сказал") unregestered Если так "ФП" не имеет ленивости, то вряд ли его можно назвать ФП. Кроме того, ленивость нужна для динамического программирования (в качестве аналога кэширования), если язык не меняет состояние то динамического программирование надо делать через кэширование. Lazy спокойно эмулируется в обычной Java с помощью паттерна Command, к теории ФП это не имеет отношения. unregestered Просто этот термин щас лепят куда не попадя. Это да. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:56 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered Такая фича есть в груви В Clojure тоже. В динамически-типизированных языках реализовать мультиметоды проще ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 19:58 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered На самом деле, паттерн-матчинг плохо реализован в языках. На вскидку могу назвать только XSLT, пролог и JBoss Drools. Чем Scala не угодила? Не говоря о Haskell ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:00 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник unregestered На самом деле, паттерн-матчинг плохо реализован в языках. На вскидку могу назвать только XSLT, пролог и JBoss Drools. Чем Scala не угодила? Не говоря о Haskell В хаскеле тоже есть, но не уверен насколько полноценный, ибо не являюсь спецом по хаскелю. А в скале он вообще какой-то кривой - какие-то case-ы надо писать и пр. Или как, например, сматчить по полю дочернего объекта? Есть такое в Скале? В друлсах есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:09 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник Lazy спокойно эмулируется в обычной Java с помощью паттерна Command, к теории ФП это не имеет отношения. А как съэмулировать лези лист? А если надо мне надо lazy A прибавить к lazy B, это значит мне надо ещё один класс сделать вместо A+B? В общем, за такие фокусы в джаве надо руки отрывать ) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:14 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered забыл ник пропущено... Чем Scala не угодила? Не говоря о Haskell В хаскеле тоже есть, но не уверен насколько полноценный, ибо не являюсь спецом по хаскелю. А в скале он вообще какой-то кривой - какие-то case-ы надо писать и пр. Или как, например, сматчить по полю дочернего объекта? Есть такое в Скале? В друлсах есть. Да, насчет синтаксиса соглашусь. Тем не менее, сматчить по полю дочернего объекта можно. А вот сматчить List[String] vs List[Int] все же не получится, из-за erasure. Насчет Haskel - там классический паттерн-матчинг в моем понимании(каждый матчинг - отдельная функция, которая в зависимости от аргументов переадресует на свою ветку кода) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:27 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
В топике генерации кривой Гильберта я пытался создать ленивый список на Java. Ничего не вышло. Но мне помогли с созданием аналогичного функционала на Scala. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:30 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered А как съэмулировать лези лист? Так list.stream() же.. unregestered А если надо мне надо lazy A прибавить к lazy B, это значит мне надо ещё один класс сделать вместо A+B? Ну с этим беда unregestered В общем, за такие фокусы в джаве надо руки отрывать ) Согласен, но тем не менее мой поинт в том что lazy это все-таки далеко не основное и необходимое в ФП, это скорее интересное следствие при попытке реализовать ФП ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:30 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
mayton В топике генерации кривой Гильберта я пытался создать ленивый список на Java. Ничего не вышло. Но мне помогли с созданием аналогичного функционала на Scala. Ну тут надо еще определиться что есть lazy list. А то ведь есть и такие реализации - https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/list/LazyList.html ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:34 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник Согласен, но тем не менее мой поинт в том что lazy это все-таки далеко не основное и необходимое в ФП, это скорее интересное следствие при попытке реализовать ФП Ну все 4 парадигмы (процедурное, логическое, функциональное и паттерн-матчинг) могут эмулировать друг-друга ибо все turing-complete. Другое дело - насколько это удобно. То мы пару читабельных строчек напишем, а то кучу команд, с абстрактными классами, third-party библиотеками, кодогенераторами и портянкой кода ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 20:55 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит. Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 23:25 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит. Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся. Истину глаголишь! ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 04:15 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит. Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся. Зато можно обмазать слоями абстракции и присыпать синтаксическим сахаром. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 05:56 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит. Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся. Да, примерно это и имел в виду. С заметанием сложности в "концепции языка" есть еще проблема, что от такого заметания сложность может существенно прирасти. Взять те же самые Оплаты и Счета, Начисления. Если подходить с позиции ООП и инкапсуляции как минимум есть PaymentDocument, BillDocument, BillLines. А дальше начинается порнография. В каком из этих объектов я должен реализовывать метод РазнестиОплату (Квитовать) ? Чисто организационно (по рабочим группам), он относится к модулю ПриемПлатежей. НО он так же должен иметь полный доступ к функционалу Bill и BillLines. Т.е. или всю секьюрити/инкапсуляция идет лесом или нужно кодировать 100500 мелких служебных функций, что бы туда-сюда-обратно управление между классами передавать. Так же и внесение изменений. Любое изменение по любому пчиху заказчика, затрагивает все классы. Которые относятся к совершенно разным (организационно) группам (программистам) и модулям: Платежи и Счета/Начисления. Т.е. модульность и инкапсуляция становится не благом, а даже злом (организационно). А кроме квитовки, есть еще такой функционал как Авансы/Переплаты. Где вообще черт ногу сломит (в нашей сущ. системе). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 06:41 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
В результате получается: что часто данные удобно сложить в какие-то ООП-обертки a la DTO: Payment, Bill, BillLines А весь бизнес функционал унести в какие нибудь Utility class'ы. И вместо ООП с инкапсуляцией/наследованием .... мы получаем... получаем... фактически голый процедурный язык с необходимостью писать 100500 геттеров-сеттеров и прочей малонужной ООП обязаловкой. IMHO. Утрированно конечно ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 06:46 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Обычно для разноски одной суммы по другим суммам вводится третья сущность. С точки зрения БД это таблица связей многие ко многим. Например в ERP Галактика это сущность Хозяйственная операция, в SAP R3 это документ выравнивания. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 07:12 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
istrebitel Обычно для разноски одной суммы по другим суммам вводится третья сущность. С точки зрения БД это таблица связей многие ко многим. Например в ERP Галактика это сущность Хозяйственная операция, в SAP R3 это документ выравнивания. В таблицах то все понятно. Я именно про ООП говорю. ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует. Большинство бизнес-кода "междесциплинарны" и затрагивают сразу огромное кол-во объектов-данных. Т.е., по факту, главный постулать/аксиома на котором и основан весь ООП - оказывается не верной. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 07:22 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev istrebitel Обычно для разноски одной суммы по другим суммам вводится третья сущность. С точки зрения БД это таблица связей многие ко многим. Например в ERP Галактика это сущность Хозяйственная операция, в SAP R3 это документ выравнивания. В таблицах то все понятно. Я именно про ООП говорю. ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует. Большинство бизнес-кода "междесциплинарны" и затрагивают сразу огромное кол-во объектов-данных. Т.е., по факту, главный постулать/аксиома на котором и основан весь ООП - оказывается не верной. А так же наследовании и полиморфизме ;-) Комбинация трех этих принципов позволяет делать обработку "междесциплинарных" данных. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 08:15 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует. По факту, приходится брать всю (сложную) предметную область и раскладывать на "технически эффективные объекты", а не "описывать бизнес-терминологию на языке объектов". ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 08:36 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, мне кажется проблема больше в Джаве, как таковой. В ней смешиваются понятия модуля (функциональное разделение с инкапсуляцией) и класса. И, кроме того, в джаве не бывает методов без класса, хотя, казалось бы, никто не заставляет писать все процедуры внутри классов. Они могут лежать и отдельно, как в Делфи или С++, например. В результате джависты вынуждены создавать искусственные объекты: всякие там контроллеры, генераторы, парсеры, утилитные классы и пр. , чтобы обойти ограничения языка. Смешную фразу прочитал от Вирта недавно: "Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что теперь называется Oberon. Большинство идей пришло от использования и изучения существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали нас от того, как не надо делать ." ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 08:38 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered Leonid Kudryavtsev, мне кажется проблема больше в Джаве, как таковой. В ней смешиваются понятия модуля (функциональное разделение с инкапсуляцией) и класса. И, кроме того, в джаве не бывает методов без класса, хотя, казалось бы, никто не заставляет писать все процедуры внутри классов. Они могут лежать и отдельно, как в Делфи или С++, например. В результате джависты вынуждены создавать искусственные объекты: всякие там контроллеры, генераторы, парсеры, утилитные классы и пр. , чтобы обойти ограничения языка. Kotlin?! :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 09:49 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Leonid Kudryavtsev ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует. По факту, приходится брать всю (сложную) предметную область и раскладывать на "технически эффективные объекты", а не "описывать бизнес-терминологию на языке объектов". +1 к наивным иерархиям. Каким образом формы документов, которые по-сути просто мешок данных для печати отчета, внезапно стали бизнес-сущностью? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 13:01 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
дубликат ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 13:02 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
unregestered "Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что теперь называется Oberon. Большинство идей пришло от использования и изучения существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали нас от того, как не надо делать ." Насколько я понимаю Оберон это не просто язык. Это целая академическая разработка ОС+Среда+Язык. Тоесть сравнивать его (Оберон) можно не как язык а как отдельную идею и только в этой весовой категории. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 13:34 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит. Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся. Не стоит путать инфраструктурную сложность и сложность бизнес-модели. На сложность бизнес-модели ни язык ни платформа никаким образом повлиять не могут, это очевидно. А вот по поводу инфраструктруной сложности - еще как могут, далее в топике приведен хороший пример, когда для того чтобы написать просто функцию надо создать целый класс. Так что не все так просто ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 14:08 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev А дальше начинается порнография. В каком из этих объектов я должен реализовывать метод РазнестиОплату (Квитовать) ? Чисто организационно (по рабочим группам), он относится к модулю ПриемПлатежей. НО он так же должен иметь полный доступ к функционалу Bill и BillLines. Т.е. или всю секьюрити/инкапсуляция идет лесом или нужно кодировать 100500 мелких служебных функций, что бы туда-сюда-обратно управление между классами передавать. Так же и внесение изменений. Любое изменение по любому пчиху заказчика, затрагивает все классы. Которые относятся к совершенно разным (организационно) группам (программистам) и модулям: Платежи и Счета/Начисления. Т.е. модульность и инкапсуляция становится не благом, а даже злом (организационно). Не в бровь а в глаз:) Нельзя не вспомнить знаменитую статью Армстронга(создателя Эрланга) - "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." Объединение данных и алгоритмов в одном месте - насквозь костыльная идея, как ни пытались ввести в массы rich model посредством Фаулера - так ничего и не вышло. Как писали Сервисы и контроллеры так и пишут. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 14:15 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник А вот по поводу инфраструктруной сложности - еще как могут, далее в топике приведен хороший пример, когда для того чтобы написать просто функцию надо создать целый класс. Так что не все так просто Вы же не "внезапно обнаружили", что "функция может быть только в виде метода класса"? Нет. Вот и проектируйте иерархию объектов с учётом имеющихся ограничений. Не впадая брезгливое омерзение эстетствующего творца. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 14:41 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov забыл ник А вот по поводу инфраструктруной сложности - еще как могут, далее в топике приведен хороший пример, когда для того чтобы написать просто функцию надо создать целый класс. Так что не все так просто Вы же не "внезапно обнаружили", что "функция может быть только в виде метода класса"? Нет. Вот и проектируйте иерархию объектов с учётом имеющихся ограничений. Не впадая брезгливое омерзение эстетствующего творца. Так эти ограничения идут от инструмента, они ортогональны бизнес-логике, зачем мне "сжимать зубы и терпеть"? Я пожалуй поищу другой инструмент. Вся история развития программирования - это постепенный вынос инфраструктурной сложности в саму платформу, чтобы программист мог сконцентрироваться на бизнес-логике ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 14:43 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник Вся история развития программирования - это постепенный вынос инфраструктурной сложности в саму платформу, чтобы программист мог сконцентрироваться на бизнес-логике Но гордые эстеты от программирования продолжают уверенно шагать по старым граблям. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 14:59 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
Basil A. Sidorov забыл ник Вся история развития программирования - это постепенный вынос инфраструктурной сложности в саму платформу, чтобы программист мог сконцентрироваться на бизнес-логике Но гордые эстеты от программирования продолжают уверенно шагать по старым граблям. Само собой серебряной пули нет. И каждому инструменты - свое дело. Но ты же не поспоришь что например параллельное программирование на лет так 15 назад это небо и змеля. И так во всем. Невозможность создания универсального инструмента не отменяет попытки усоверщенствовать имеющиеся ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 15:03 |
|
Получение spring beans в классе, неуправляемом spring
|
|||
---|---|---|---|
#18+
забыл ник Невозможность создания универсального инструмента не отменяет попытки усоверщенствовать имеющиеся Работа у вас "инструменты совершенствовать" или, таки, "бизнес програмировать"??? А если совершенствовать, то в чём проблема? Берём JVM/JLS и пишем "новое API без недостатков", опираясь на возможности модуляризированной платформы. Если правильно помню, то собственно JVM для запуска требуется всего пяток классов: Class, ClassLoader, Thread, ThreadGroup и String. Если "делать правильно", то мы свободны и от ограничений существующего String API. Если делать собственный компилятор, то можно порешать ещё и проблемы (un)box/generics. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2020, 15:20 |
|
|
start [/forum/topic.php?all=1&fid=59&tid=2120807]: |
0ms |
get settings: |
14ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
1837ms |
get tp. blocked users: |
2ms |
others: | 326ms |
total: | 2272ms |
0 / 0 |