Pull to refresh

Comments 22

У меня 2 вопроса:
1. Стоят ли все эти усилия того, чтобы просто внимательно отработать на get/set методах при создании объекта (при код ревью или самопроверке)?
2. Не является ли такой подход более многословным, нежели JUnit тест мест создания таких объектов?
Спасибо.

Я спрашиваю, просто очень много на хабре пишут про билдере в ключе создания объектов, но вот в моей 8 летней практике я ни разу не встречал проблем при работе с такими объектами (get/set).
Тем не менее сам патерн билдер я использовал немного в другом ключе — создание PrepareStatement для разных версий и типов АБС при интеграции данных.
Если смотреть с точки зрения использования самого builder-а, то он может казаться избыточным. Тем более при наличии модульных тестов. Но если вы пишете builder с тем, чтобы его использовали другие люди, то Ваши усилия могут окупиться сполна
Все вроде бы хорошо, но как быть, когда вызвать надо не только configure, но и configure2, configure3 и т.д.?
Посмотрите пример с UrlBuilder (под спойлером), там как раз несколько обязательных к конфигурирование свойств.

Вообще, если с точки зрения терминологии — по-моему, методы с в Java всю жизнь называли generic methods, а не "параметрический полиморфизм".

Предложенный метод забавен, но упирается в то, что по сути это вызов approve() руками, вместо implicit-вызова, которое генерирует type inferring в Scala.


Что касается Java, развитие языка не стоит на месте, язык меняется в лучшую сторону, вбирая в себя решения и конструкции из других языков.

Субъективно, Java как сам язык имеет дикое количество родовых травм и при попытке добавлять туда какие-то современные элементы функциональщины а ля Scala прямо все сурово трещит по швам, в первую очередь в районе системы типов. По крайней мере из того, что я вижу — программистов на "современной Java" сейчас уже сильно меньше, чем программистов на той же Scala. Приличная масса до сих пор сидит в лучшем случае на 7 (а то и на 6), или, даже если меняли компилятор — все равно в code base используют все те же практики 15-летней давности.


JVM же как раз развивается полезно, но как-то странно. Появляется масса интересных оптимизаций, JVM 8 действительно стала прямо летать на куче всяких интересных задач, но опять же — радикальных изменений в районе той же системы типов — так и не происходит. Фактически, JVM как ничего не знал о generics — так и не знает. Как была одна куцая инструкция instanceof — так, фактически и остается. Как плодятся классы на каждый чих для функциональных проявлений — так и плодятся, разве что благодаря более эффективным GC стало не так заметно.

>Приличная масса до сих пор сидит в лучшем случае на 7 (а то и на 6), или, даже если меняли компилятор — все равно в code base используют все те же практики 15-летней давности.

Да ладно. У меня обратные впечатления. Сам с удовольствием перешел сначала на 7, а потом на 8, причем в первом случае реальные улучшения были минимальны. А те, котому это интересно (или делать нечего, или и то и другое вместе ;) охотно пробуют вообще все новинки, а также кложу, скалу, котлин и пр. языки, все какие есть.

Те же, кто сидит на старых версиях, как правило вынуждены. Например, у нас тут рядом есть небольшая команда, человек 10, которые привязаны к Jboss Fuse, и эта купленная много лет назад версия, не работает на Java 8. А смигрировать большой проект — это не так просто. А так бы с радостью давно бы перешли.
Сам с удовольствием перешел сначала на 7, а потом на 8, причем в первом случае реальные улучшения были минимальны.

Ради интереса и статистики — что из 8 вы используете? Какой размер codebase у мигрированных проектов?


Возможно, что у меня сильно сдвинутая выборка — но я наблюдаю, что почти все, что сейчас делается новое-модное-интересное в районе JVM — делается на Scala или, реже, Clojure. Это всякие нагруженные вычисления, статистика, кластеризация, поисковые движки, всякие агентные системы, мессаджинг, игры с массивным количеством клиентов, one-page сайты с хорошей интеграция frontend/backend и т.п.


Java я вижу почти исключительно в командах, занимающихся системами, которые зачастую существуют уже не первый десяток лет — банки, EE, какие-то относительно старые существующие веб-порталы, либо что-то, что вынуждено с таким интегрироваться. Там даже Spring + Hibernate зачастую считается чем-то прям новым и хипстерским. И, да, зачастую Java 6 и все.

Ну так JavaEE (в виде например WAS) — это и есть тот фактор, который сдерживает. Чтобы поддерживалась Java 8, нужно купить новую версию WAS, а кто и зачем это будет делать, если старая работает нормально? Это ровно таже причина, что я наблюдал с Fuse. Знаю, что до сих пор сидят местами на EJB 2. Но это на мой взгляд дурь — если бы смигрировали, получили бы приличные преимущества.

>Ради интереса и статистики — что из 8 вы используете? Какой размер codebase у мигрированных
проектов?

Я использовал в основном стримы, и лямбды. Проект маленький — где-то три человеко месяца, может чуть больше/чуть меньше.

Это (инвестиционный) банк. Кстати, был период тут (уже в другом проекте), когда народ увлекался, и писал на чем хотел. Clojure например. Сейчас наблюдается тенденция вернуться обратно на Java, потому что это с одной стороны, инфраструктура, и клиенты у нее разные, и иметь ее на Java — значит проще взаимодействовать. А с другой — проще поддерживать, потому что любитель кложи был один, он ушел — и опаньки.
Но это на мой взгляд дурь — если бы смигрировали, получили бы приличные преимущества.

Субъективно, профит получается, если выкидывать EE отовсюду и переделывать все на что-то более адекватное и современное. Но на это, как правило, ни верхи, ни низы пойти не могут: верхи — потому, что дорого, а низы — потому что зачем терять работу?


Сейчас наблюдается тенденция вернуться обратно на Java

Я такое года 3-4 назад наблюдал. Именно когда "сбегали" одиночки в инициативном порядке и, да, тогда некоторые огребали "любитель кложи был один". Сейчас это время прошло, народ целенаправленно и осознанно начинает новые проекты на Scala или Clojure, и программисты внезапно набираются, и так далее. И implicit'ы со scalaz уже не лепят везде, где только можно, просто потому что "круто".

Про EE — совершенно необязательно. При переходе на EJB 3 было серьезное упрощение почти всего. Это примерно 2008-2009. С одновременным облегчением контейнеров.

С тех пор, если вы смигрировали, смысла уходить куда-то уже не наблюдается. Хотя начинать что-то новое не на EE — может быть и проще. Но опять же — совсем не сильно. Что адекватное-то? Микросервисы? Так я готов поспорить, их преимущества зачастую сомнительны, потому что EE — это и есть контейнер для микросервисов. Как впрочем и OSGI.

А насчет остального… ну как у скалы, так и у кложи, есть некоторые недостатки. В каждом случае свои. И достоинства в общем тоже в каждом случае свои, разные. Чем дольше живет язык — тем недостатки и достоинства народу становятся яснее, это же понятно. Ну и делать «потому что круто» сейчас вот на кложе уже не круто — в моде уже другие.

И у нас таки есть целенаправленный уход от кложи — потому что когда-то применили не по делу. Я не говорю что это общая тенденция — но факты наблюдаю лично.
Что адекватное-то? Микросервисы? Так я готов поспорить, их преимущества зачастую сомнительны, потому что EE — это и есть контейнер для микросервисов. Как впрочем и OSGI.

В EE, по современным меркам, плохо, по-моему, примерно все. Неудобная (потому что бинарная и требует весьма специфичных инструментов для отладки и контроля) и медленная (потому что о каких-то серьезных нагрузках, promises и нетредовых архитектурах там и близко не слышали) messaging bus. Жесткая привязка к одной платформе — я вот сильно сомневаюсь, что кто-то в production будет сажать на шину (т.е. реализовать эти самые микросервисы) на чем-то, отличном от Java. Отсутствие простых базовых сервисов, собственно, "как сервис". Захотите какое-нибудь готовое хранилище документов от Amazon / Google, или, там, не знаю, дергать cloud'ное API для генерации картинок → в лучшем случае, все закончится проектом эдак на человекомесяц-два по написанию монструозной обертки над этим для EE. Там, где разработчик на Ruby или Node.js напишет две-три строчки и потратит 15 минут (из которых 14 будут написанием тестов), на EE это займет в десятки и сотни раз больше времени. Современный мир — гетерогенен и, хочется нам того или нет, SaaS/PaaS/IaaS зачастую дают гигантские преимущества.


Даже те сферы, где EE типично было удобно применять (типа автоматизации бизнес-процессов), сейчас дико подминают под себя, скажем, тот же Salesforce, Dynamics и SAP.

Хм. Ваши претензии к EE выглядят странно, если не сказать больше. Ну кроме разве что нагрузки — хотя утверждать что в мире enterprize не слышали о серьезных нагрузках — это сильно. Но тут я просто не в теме, потому что реально нагруженных систем на этом не делал.

Но в целом вы какую-то очень древнюю JavaEE себе представляете, по-моему.

Привязка к платформе? В каком месте? Если мне будет очень зачем-то нужно написать кусок на чем-то отличном от Java — я его прекрасно напишу на почти любом из пары десятков приличных языков. EE этому перпендикулярно.

Про cloud API вообще не понял посыла. Ну так, для начала — и Ruby (в виде JRuby), и javascript (в виде Rhino или Nashorn) в мире JVM, и в JavaEE тоже есть. Если разработчик Node.js напишет две-три строчки — что помешает мне написать те же две строчки, на тех же языках? JavaEE это легкое и простое API, уже лет 8 как. Там нет практически никаких ненужных накладных расходов. Вы просто берете — и пишете сервис. Который потом деплоите в любой из контейнеров, и контейнер дальше раздает его наружу, по любому из множества протоколов, включая древнюю corba. И обеспечивает вам транзакции, и прочие плюшки, по потребности.
хотя утверждать что в мире enterprize не слышали о серьезных нагрузках — это сильно.

"Мир enterprise" до сих пор работает 5 дней в неделю по 8 часов с перерывом на обед. "Мир enterprise" до сих пор мыслит оперднями и на полном серьезе складывает данные в Oracle. Единицы миллиардов транзакций в год — это до сих пор национальный потолок даже для крупных банков и транспортных систем. Где здесь нагрузки?


Привязка к платформе? В каком месте?

Отлично, вот есть у меня, допустим, система документооборота, построенная на базе EE. И вот в компании захотелось, внезапно, обеспечить интеграцию с каким-нибудь готовым существующим внешним решением по GPS-трекингу своего парка грузовых автомобилей с водителями, или, например, управления очередями печати в офисных принтерах. Что будет дальше происходить? В моем представлении, в лучшем случае будет происходить написание пары десятков врапперов над этим API. В худшем (как это обычно происходит) — просто никто не будет заморачиваться, подгрузят каких-нибудь библиотек в основной компонент и подергают вызовами оттуда. А потом, когда это понадобится в каком-то другом компоненте — добавят и туда, и подергают еще и оттуда.

Ерунду вы какую-то говорите, пардон. Мир enterprise — это например биржевая роботизированная торговля, которая торгует тогда, когда работают биржи. Т.е. фактически — круглосуточно, потому что Токийская биржа открывается примерно тогда, когда закрывается Нью-Йоркская.

Число транзакций? А вы много где видели скажем Терадату помимо банков? Я вам подскажу — еще сотовые операторы обычно кроме банков ее держат. Объемы входящих маркет данных тоже вполне себе немаленькие.

А про второй абзац снова не понял. EE-то тут каким боком? Для EE не нужно никаких врапперов для сервиса GPS трекинга, вы откуда это взяли? JavaEE — это про организацию компонентов внутри контейнера. Т.е. как будет выглядеть скажем сервис, причем это вовсе не догма — можно делать и не так, причем довольно переносимо.

К тому, как вы будете общаться с внешним сервисом, будь то GPS или принтеры, это никакого отношения ровным счетом не имеет. То есть ваще никакого.
Мир enterprise — это например биржевая роботизированная торговля, которая торгует тогда, когда работают биржи.

Окей, покажите мне хоть одну биржу или трейдерский софт на EE ;)


А вы много где видели скажем Терадату помимо банков? Я вам подскажу — еще сотовые операторы обычно кроме банков ее держат. Объемы входящих маркет данных тоже вполне себе немаленькие.

Последний раз когда я смотрел на Teradata DWH, он был написан на C++. Ну и да, по нынешним временам я бы их в пример приводить не стал, дела у них идут относительно так себе.


Одного сотового оператора наблюдаю прямо сейчас. Ничего особенно впечатляющего — ни в количестве транзакций, ни в размерах в байтах. Терадата у них живет исключительно в BI и в сильно урезанном виде. Основной внутренний рабочий DWH — Splunk.


Среднестатистический bigdata-стартап, считающий какие-нибудь рекомендации или рекламу, обрабатывает в 10-100 раз больше данных в сутки.


К тому, как вы будете общаться с внешним сервисом, будь то GPS или принтеры, это никакого отношения ровным счетом не имеет. То есть ваще никакого.

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

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

Я вам еще раз повторю — JavaEE это не про внешние API. Как вы с ними будете работать — исключительно ваши трудности. Хотите — врапперов напишите, хотите так потребляйте. JavaEE тут ни при чем, никаким боком. Поэтому какие у вас тут претензии к JavaEE, я так и не понял.
Хотя насчет высокой нагрузки — я пожалуй соглашусь. Точнее — насчет масштабирования.

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

По сути дела надо проверить являются ли введенные параметры валидными, это в сто раз проще всего, что тут написано и на 100% закрывает задачу.


PS. Как безопасно написать такой билдер:


        NotificationCompat.Builder mBuilder = new NotificationCompat.Builder(context)
                .setSmallIcon(getType().getIconRes())
                .setTicker(getMessage())
                .setOngoing(true)
                .setCategory(Notification.CATEGORY_PROGRESS)
                .setColor(context.getResources().getColor(R.color.main))
                .setVisibility(Notification.VISIBILITY_PUBLIC)
                .setWhen(new Date().getTime())
                .setShowWhen(true)
                .setPriority(Notification.PRIORITY_HIGH)
                .setProgress(getTotal(), getProgress(), getIndeterminate())
                .setContentTitle(context.getResources().getString(R.string.app_name))
                .setContentText(getMessage())
                .setContentIntent(getProgressIntent(context));
Всякому решению свое применение. Вереница условий с проверкой каждого параметра из такого большого списка будет не многим лучше выглядеть чем куча generic параметров и все еще поздно (только кода программа запущена, и выполнена ветка исполнения касающаяся билдера) давать фидбек. Тут дело уже в другом — я бы расстроился, если бы в используемой библиотеке мне пришлось инициализировать такого монстра. Возможно части параметров из примера можно выставить значения поумолчанию, часть сгруппировать.
Как говорилось на одной известной картинке: «но зачем?»
Все примеры, которые я видел, применения по делу, не требовали обязательного вызова всех методов. Как правило речь идет о вызове лишь части методов, иногда они даже бывают взаимоисключающие.

А мне бы хотелось compile-time проверку для сложных билдеров. Главная проблема предложенного решения — добавлять еще один метод очень сложно (надо кучу дженериков поправить). Но это решается вынесением билдера в какой-нибудь lombok в джаве или макросы в скале.


Так здесь же важна сама идея. Опциональные/взаимоисключающие методы сюда уже просто добавляются. Правда, выглядеть хорошо это будет только на скале. В джаве надо будет писать по своему approve для каждого метода.

Only those users with full accounts are able to leave comments. Log in, please.