Опять принцип Лисков перевернули с ног на голову и ради этого в примере сделали дополнительный класс для наследования.
Класс PaymentAccount либо должен быть контрактом (абстрактным классом или вообще интерфейсом), либо сразу содержать реализацию, но тогда он нарушит все те объяснения, что даны в статье - заменить его на Account не выйдет из-за проблем с методами. Потому добавили еще один класс который наследуется от PaymentAccount и тем самым защищает от логической ошибки в тексте. Потому, как верно было замечено в комментариях, последовательность там все таки иная - мы можем заменить Account на любую из реализаций и логика не должна сломаться.
Подозреваю, в данном случае речь про thymeleaf, mustache или jsp. Я бы не назвал это прямо фреймворками, скорее библиотеками, но это действительно шаблонизаторы. Впрочем статью явно писал маркетолог, а не разработчик, это чувствуется по стилю.
Это зависит от размеров и сложности сервиса. Если у вас пара контроллеров да пара сущностей - то да, созданием прослоек можно пренебречь, но если приложение крупное, то создание этих оберток обосновано. В крупном приложении нужно строже придерживаться целевого назначения компонентов. То, что сейчас у вас всего 1 вызов в сервисе и сразу его возврат в контроллер, не значит что при решении новой задачи не появиться необходимость 2 вызовов, где транзакция нужна только для одного и тут внезапно придется вписывать слой сервисов. А вписывать его нужно целиком, чтобы не нарушать единообразия, а значит в какой то момент времени в ПР вместо добавления одного метода внезапно придется писать кучу вот таки пробрасывающих объектов, чтобы сохранить стилистику кода приложения. А при разработке приложения чуть сложнее, чем предоставление данных из BD в UI as is, такая необходимость возникнет гарантированно, а значит и сервисный слой будут закладывать еще на этапе проектирования архитектуры, даже если в первые пол года при разработке прототипа он окажется избыточным.
Цель разбиения на слои не только в технической необходимости, но еще и в соблюдении единообразия проекта, чистоты кода, проектного code style, снижения сложности входа в проект новых разработчиков и т.д. Собственно это базовые принципы использования любого архитектурного паттерна с заявкой на то, что сервис будет функционировать и эксплуатироваться.
Это зависит от того, какой стек используем. Если вся логика лежит в БД на уровне хранимых процедур (старый финтех), то да, можно и лучше вообще не использовать, база сделает все сама. При наличии любой ОРМ уже так просто не отделаться. И если выбирать между аннотацией и явным созданием транзакции через sessonFactory - лучше аннотация. код становится сильно проще. Что, впрочем, не отменяет необходимости знать, что за магия там творится под капотом, чтобы не стрелять себе в ногу
Ничего не мешает работать с rich model на уровне сервиса. Контроллер не вмещает в себя функцию бизнес логики - его задача получить данные из сервиса и отдать клиенту, максимум - преобразовать в ДТО. Но консистентносить и наполненность должна обеспечиваться именно сервисом
К сожалению, разбираюсь только в рынке джавы, про пайтон ничего сказать не могу.
Да и ориентироваться на джуна при выборе профессии не слишком правильно на мой взгляд — по сути это до первой работы. Найти вторую будет уже гораздо проще, т.к. есть опыт и там уже именно «джун» мало на что влияет. Смотреть стоит на перспективу, хотя бы на уровень мидла.
ну джун джуну рознь, да и вакансий для них не так много, если совсем без опыта. там действительно может быть ниже. Но в целом суммы меньше 100-120 я уже довольно давно не слышал даже для минимальных вакансий.
Это Москва. По моей выборке, 120 это джун. За меньше вы его врятли найдете. Остальное — на усмотрение работодателя и соискателя. И да, 250 это моя цифра за легаси стек, но я не считаю, что закрываю сеньорскую позицию, потому указываю как для мидла, на мой взгляд. Те, с кем работаю, и кто работает «за деньги» но с чем угодно — ставят на такие места вилку 300+. Мало кто столько даст, правда.
Ну собственно я к этому и веду. Мои +15% это все равно меньше 250 или 300.
И если компания хочет найти кого то на старый стек — им придется давать x1.5 к рынку в виде доплаты за легаси. И все равно это не самая тривиальная задача, в моем понимании она не согласуется с фразой «еще долго не будет очень больших проблем с поиском людей на саппорт». Как показывает практика — даже за такой рейт людей придется основательно поискать.
Вы дано не искали джавистов. Я от такого офера отказался неделю назад, в Газпромбанке есть система на старой джаве (6) без jee и спринга. И денег дают примерно по рынку. Очень меня уговаривали, но зачем? за неделю нашел еще 2 оффера с +15% к сумме и с нормальным стеком.
На джаве найти человека, который будет заниматься старым легаси и при этом не платить ему хотя бы от 250 в месяц (это для хорошего мидла, те сеньоры, кого я знаю и кто пойдет этим заниматься за деньги хотят от 300) — задача крайне не тривиальна и зачастую такая вакансия вообще не закрывается.
Читая эти сокращения и их произношение наткнулся на мысль, что в русском они проще — это всегда производная от русского слова. А тут латынь, да еще и произносится синонимами на английском вместо прямого произношения.
Тогда вынужден признать, что фразу
>А вы попробуйте сходить и сдать ЕГЭ. Чисто для себя, чтобы убедиться, что получить там сотню — плёвое дело
Его ведь может сдать любой человек :-)
Я до конца не понимаю) И это либо сарказм либо это сильно выше моего понимания)
Т.е. я могу вас поздравить с 100 баллов который вы получили за экзамен в последние пару лет?) Тогда я за вас рад) Но вы скорее исключение, чем правило. 300 бальников даже на фоне страны не так много)
Уверены что комментарий ко мне? Я то его уже сдавал и знаю, как к нему готовятся и что там спрашивают. Человек с улицы на 100 баллов ЕГЭ не сдаст) даже если у него за спиной красный диплом и отличные знания) У меня много примеров перед глазами было, кто готовился\учился в спец школах для одаренных и прочее, кто в итоге сдавал хуже тех, кто просто зубрили 2 года подряд и монотонно решали тесты)
Не указана исключительно котлин фича с енамами - у них есть неявный базовый класс на основе которого можно строить функции расширения и дженерики.
Опять принцип Лисков перевернули с ног на голову и ради этого в примере сделали дополнительный класс для наследования.
Класс PaymentAccount либо должен быть контрактом (абстрактным классом или вообще интерфейсом), либо сразу содержать реализацию, но тогда он нарушит все те объяснения, что даны в статье - заменить его на Account не выйдет из-за проблем с методами. Потому добавили еще один класс который наследуется от PaymentAccount и тем самым защищает от логической ошибки в тексте. Потому, как верно было замечено в комментариях, последовательность там все таки иная - мы можем заменить Account на любую из реализаций и логика не должна сломаться.
Если говорить цитатами, то:
Let f(x) be a property provable about objects x of type T. Then f(y) should be true for objects y of type S where S is a subtype of T.
Что в переводе говорит нам, что функция f остается корректной, если вызов f(x) заменить на f(y) где y подтип x
Ну если еще точнее - то за oracle jdk теперь просят. считай за поддержку, да. За остальные дистрибутивы, например open jdk - не просят.
как минимум часть Netflix использует Java - их разработки вошли в Spring Cloud. Речь как минимум про Eureka
Подозреваю, в данном случае речь про thymeleaf, mustache или jsp. Я бы не назвал это прямо фреймворками, скорее библиотеками, но это действительно шаблонизаторы. Впрочем статью явно писал маркетолог, а не разработчик, это чувствуется по стилю.
Нет, в примере он пишет, что хочет пробросить порт сервера 80 на порт 8080 контейнера. последовательность в примере должна быть обратная, т.е.
Не самый удачный перевод Registry с английского. Это хранилище образов
Если мне не именяет память, то наоборот. сначала протокол и порт локальной машины, потом - контейнера
Это зависит от размеров и сложности сервиса. Если у вас пара контроллеров да пара сущностей - то да, созданием прослоек можно пренебречь, но если приложение крупное, то создание этих оберток обосновано. В крупном приложении нужно строже придерживаться целевого назначения компонентов. То, что сейчас у вас всего 1 вызов в сервисе и сразу его возврат в контроллер, не значит что при решении новой задачи не появиться необходимость 2 вызовов, где транзакция нужна только для одного и тут внезапно придется вписывать слой сервисов. А вписывать его нужно целиком, чтобы не нарушать единообразия, а значит в какой то момент времени в ПР вместо добавления одного метода внезапно придется писать кучу вот таки пробрасывающих объектов, чтобы сохранить стилистику кода приложения. А при разработке приложения чуть сложнее, чем предоставление данных из BD в UI as is, такая необходимость возникнет гарантированно, а значит и сервисный слой будут закладывать еще на этапе проектирования архитектуры, даже если в первые пол года при разработке прототипа он окажется избыточным.
Цель разбиения на слои не только в технической необходимости, но еще и в соблюдении единообразия проекта, чистоты кода, проектного code style, снижения сложности входа в проект новых разработчиков и т.д. Собственно это базовые принципы использования любого архитектурного паттерна с заявкой на то, что сервис будет функционировать и эксплуатироваться.
Это зависит от того, какой стек используем. Если вся логика лежит в БД на уровне хранимых процедур (старый финтех), то да, можно и лучше вообще не использовать, база сделает все сама. При наличии любой ОРМ уже так просто не отделаться. И если выбирать между аннотацией и явным созданием транзакции через sessonFactory - лучше аннотация. код становится сильно проще. Что, впрочем, не отменяет необходимости знать, что за магия там творится под капотом, чтобы не стрелять себе в ногу
Ничего не мешает работать с rich model на уровне сервиса. Контроллер не вмещает в себя функцию бизнес логики - его задача получить данные из сервиса и отдать клиенту, максимум - преобразовать в ДТО. Но консистентносить и наполненность должна обеспечиваться именно сервисом
Да и ориентироваться на джуна при выборе профессии не слишком правильно на мой взгляд — по сути это до первой работы. Найти вторую будет уже гораздо проще, т.к. есть опыт и там уже именно «джун» мало на что влияет. Смотреть стоит на перспективу, хотя бы на уровень мидла.
И если компания хочет найти кого то на старый стек — им придется давать x1.5 к рынку в виде доплаты за легаси. И все равно это не самая тривиальная задача, в моем понимании она не согласуется с фразой «еще долго не будет очень больших проблем с поиском людей на саппорт». Как показывает практика — даже за такой рейт людей придется основательно поискать.
На джаве найти человека, который будет заниматься старым легаси и при этом не платить ему хотя бы от 250 в месяц (это для хорошего мидла, те сеньоры, кого я знаю и кто пойдет этим заниматься за деньги хотят от 300) — задача крайне не тривиальна и зачастую такая вакансия вообще не закрывается.
>А вы попробуйте сходить и сдать ЕГЭ. Чисто для себя, чтобы убедиться, что получить там сотню — плёвое дело
Его ведь может сдать любой человек :-)
Я до конца не понимаю) И это либо сарказм либо это сильно выше моего понимания)