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

Откуда:
Сообщений: 5288
Basil A. Sidorov
Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит.
Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся.


Зато можно обмазать слоями абстракции и присыпать синтаксическим сахаром. :-)
14 май 20, 05:56    [22132560]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8552
Basil A. Sidorov
Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит.
Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся.

Да, примерно это и имел в виду.

С заметанием сложности в "концепции языка" есть еще проблема, что от такого заметания сложность может существенно прирасти.

Взять те же самые Оплаты и Счета, Начисления. Если подходить с позиции ООП и инкапсуляции как минимум есть PaymentDocument, BillDocument, BillLines.

А дальше начинается порнография. В каком из этих объектов я должен реализовывать метод РазнестиОплату (Квитовать) ? Чисто организационно (по рабочим группам), он относится к модулю ПриемПлатежей. НО он так же должен иметь полный доступ к функционалу Bill и BillLines.

Т.е. или всю секьюрити/инкапсуляция идет лесом или нужно кодировать 100500 мелких служебных функций, что бы туда-сюда-обратно управление между классами передавать. Так же и внесение изменений. Любое изменение по любому пчиху заказчика, затрагивает все классы. Которые относятся к совершенно разным (организационно) группам (программистам) и модулям: Платежи и Счета/Начисления. Т.е. модульность и инкапсуляция становится не благом, а даже злом (организационно).

А кроме квитовки, есть еще такой функционал как Авансы/Переплаты. Где вообще черт ногу сломит (в нашей сущ. системе).
14 май 20, 06:41    [22132567]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8552
В результате получается:

что часто данные удобно сложить в какие-то ООП-обертки a la DTO: Payment, Bill, BillLines
А весь бизнес функционал унести в какие нибудь Utility class'ы.

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

IMHO. Утрированно конечно
14 май 20, 06:46    [22132568]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
istrebitel
Member

Откуда:
Сообщений: 57
Обычно для разноски одной суммы по другим суммам вводится третья сущность. С точки зрения БД это таблица связей многие ко многим. Например в ERP Галактика это сущность Хозяйственная операция, в SAP R3 это документ выравнивания.
14 май 20, 07:12    [22132571]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 8552
istrebitel
Обычно для разноски одной суммы по другим суммам вводится третья сущность. С точки зрения БД это таблица связей многие ко многим. Например в ERP Галактика это сущность Хозяйственная операция, в SAP R3 это документ выравнивания.

В таблицах то все понятно. Я именно про ООП говорю.

ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте

Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует. Большинство бизнес-кода "междесциплинарны" и затрагивают сразу огромное кол-во объектов-данных. Т.е., по факту, главный постулать/аксиома на котором и основан весь ООП - оказывается не верной.
14 май 20, 07:22    [22132572]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5288
Leonid Kudryavtsev
istrebitel
Обычно для разноски одной суммы по другим суммам вводится третья сущность. С точки зрения БД это таблица связей многие ко многим. Например в ERP Галактика это сущность Хозяйственная операция, в SAP R3 это документ выравнивания.

В таблицах то все понятно. Я именно про ООП говорю.

ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте

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


А так же наследовании и полиморфизме ;-)

Комбинация трех этих принципов позволяет делать обработку "междесциплинарных" данных. :-)
14 май 20, 08:15    [22132585]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
Leonid Kudryavtsev
ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте

Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует.
Действует. Не работают "наивные" иерархии классов.
По факту, приходится брать всю (сложную) предметную область и раскладывать на "технически эффективные объекты", а не "описывать бизнес-терминологию на языке объектов".
14 май 20, 08:36    [22132596]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
unregestered
Member

Откуда:
Сообщений: 478
Leonid Kudryavtsev, мне кажется проблема больше в Джаве, как таковой. В ней смешиваются понятия модуля (функциональное разделение с инкапсуляцией) и класса. И, кроме того, в джаве не бывает методов без класса, хотя, казалось бы, никто не заставляет писать все процедуры внутри классов. Они могут лежать и отдельно, как в Делфи или С++, например. В результате джависты вынуждены создавать искусственные объекты: всякие там контроллеры, генераторы, парсеры, утилитные классы и пр. , чтобы обойти ограничения языка.

Смешную фразу прочитал от Вирта недавно:

"Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что теперь называется Oberon. Большинство идей пришло от использования и изучения существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали нас от того, как не надо делать."
14 май 20, 08:38    [22132597]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5288
unregestered
Leonid Kudryavtsev, мне кажется проблема больше в Джаве, как таковой. В ней смешиваются понятия модуля (функциональное разделение с инкапсуляцией) и класса. И, кроме того, в джаве не бывает методов без класса, хотя, казалось бы, никто не заставляет писать все процедуры внутри классов. Они могут лежать и отдельно, как в Делфи или С++, например. В результате джависты вынуждены создавать искусственные объекты: всякие там контроллеры, генераторы, парсеры, утилитные классы и пр. , чтобы обойти ограничения языка.


Kotlin?! :-)
14 май 20, 09:49    [22132619]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
fixxer
Member

Откуда:
Сообщений: 791
Basil A. Sidorov
Leonid Kudryavtsev
ООП зиждется на постулате инкапсуляции: данные и код которые их обрабатывают должны быть собраны в одном месте

Вроде бы верный постулат. Но если взять реальные бизнес-системы, то он нифига не действует.
Действует. Не работают "наивные" иерархии классов.
По факту, приходится брать всю (сложную) предметную область и раскладывать на "технически эффективные объекты", а не "описывать бизнес-терминологию на языке объектов".


+1 к наивным иерархиям. Каким образом формы документов, которые по-сути просто мешок данных для печати отчета, внезапно стали бизнес-сущностью?

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

Откуда:
Сообщений: 791
дубликат

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

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

"Просто невозможно поблагодарить всех тех, кто так или иначе подпитывал своими идеями то, что теперь называется Oberon. Большинство идей пришло от использования и изучения существующих языков, таких как Modula-2, Ada, Smalltalk и Cedar, которые часто предостерегали нас от того, как не надо делать."

Насколько я понимаю Оберон это не просто язык. Это целая академическая разработка ОС+Среда+Язык.
Тоесть сравнивать его (Оберон) можно не как язык а как отдельную идею и только в этой весовой категории.
14 май 20, 13:34    [22132830]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
Basil A. Sidorov
Практика показывает, что всегда найдётся задача (целый класс задач) где надо "портянку растягивать". От концептуальной эстетики языка это не зависит.
Помнится, была на RSDN статья про "сложность". Основной посыл: сложность она такая, какая есть. Всё, что можно сделать - "замести" часть сложности "куда-то". Я бы сказал, что замести сложность в "концепции языка" - вряд ли удастся.

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

Откуда:
Сообщений: 3289
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 май 20, 14:15    [22132886]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
забыл ник
А вот по поводу инфраструктруной сложности - еще как могут, далее в топике приведен хороший пример, когда для того чтобы написать просто функцию надо создать целый класс. Так что не все так просто
А не надо ставить лошадь позади телеги.
Вы же не "внезапно обнаружили", что "функция может быть только в виде метода класса"? Нет. Вот и проектируйте иерархию объектов с учётом имеющихся ограничений. Не впадая брезгливое омерзение эстетствующего творца.
14 май 20, 14:41    [22132912]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
забыл ник
Member

Откуда:
Сообщений: 3289
Basil A. Sidorov
забыл ник
А вот по поводу инфраструктруной сложности - еще как могут, далее в топике приведен хороший пример, когда для того чтобы написать просто функцию надо создать целый класс. Так что не все так просто
А не надо ставить лошадь позади телеги.
Вы же не "внезапно обнаружили", что "функция может быть только в виде метода класса"? Нет. Вот и проектируйте иерархию объектов с учётом имеющихся ограничений. Не впадая брезгливое омерзение эстетствующего творца.

Так эти ограничения идут от инструмента, они ортогональны бизнес-логике, зачем мне "сжимать зубы и терпеть"? Я пожалуй поищу другой инструмент. Вся история развития программирования - это постепенный вынос инфраструктурной сложности в саму платформу, чтобы программист мог сконцентрироваться на бизнес-логике
14 май 20, 14:43    [22132917]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Basil A. Sidorov
Member

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

Откуда:
Сообщений: 3289
Basil A. Sidorov
забыл ник
Вся история развития программирования - это постепенный вынос инфраструктурной сложности в саму платформу, чтобы программист мог сконцентрироваться на бизнес-логике
... с постоянным обнаружением того факта, что невозможно создать универсальную платформу.
Но гордые эстеты от программирования продолжают уверенно шагать по старым граблям.

Само собой серебряной пули нет. И каждому инструменты - свое дело. Но ты же не поспоришь что например параллельное программирование на лет так 15 назад это небо и змеля. И так во всем. Невозможность создания универсального инструмента не отменяет попытки усоверщенствовать имеющиеся
14 май 20, 15:03    [22132935]     Ответить | Цитировать Сообщить модератору
 Re: Получение spring beans в классе, неуправляемом spring  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10171
забыл ник
Невозможность создания универсального инструмента не отменяет попытки усоверщенствовать имеющиеся
Я как-то потерялся в потоке ваших мыслей ...
Работа у вас "инструменты совершенствовать" или, таки, "бизнес програмировать"???
А если совершенствовать, то в чём проблема? Берём JVM/JLS и пишем "новое API без недостатков", опираясь на возможности модуляризированной платформы.
Если правильно помню, то собственно JVM для запуска требуется всего пяток классов: Class, ClassLoader, Thread, ThreadGroup и String. Если "делать правильно", то мы свободны и от ограничений существующего String API.
Если делать собственный компилятор, то можно порешать ещё и проблемы (un)box/generics.
14 май 20, 15:20    [22132958]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
Все форумы / Java Ответить