В случае с v8n, это хоть как-то можно обосновать созвучием - ValidEIGHTioN - лично мне такой способ именования кажется притянутым за уши, но тут уж на вкус и цвет. Но что такое Vi-nine-es и почему это means validation - загадка для меня.
Необычно, что валидатор навешивается на команды. Более аутентичный подход, как мне кажется, это валидировать входные данные, поступающие в контролеры (реквесты) тем самым не допуская конструирования невалидных команд. Получаем следующие плюсы:
Не надо дополнительно конфигурировать FluentValidator - он на такой сценарий изначально рассчитан.
При валидационных ошибках пользователь API получит ответ, в котором сообщения об ошибках соответствуют структуре реквеста, а не команды. При разветвлённой структуре это может быть важно.
Не нужно пробрасыаать исключения при валидационных ошибках.
Из минусов я вижу то, что логика валидации конкретного реквеста связана с хендлером для команды очень неявным образом.
По своему опыту применения медатора, могу сказать, что он помогает в написании кода под конкретные юзкейсы, что особенно полезно, если одновременно работает несколько команд, и важно не поломать чужую логику в god-service. Но при этом, когда обсуждается паттерн "сервис-локатор", в качестве главного недостатка указывается, что у сервиса, имеющего зависимость от локатора, появляются невявные зависимости от других сервисов, при которые мы не можем узнать не глядя на реализацию; однако в случае с медатором мы имеем в точности то же самое, но я почему-то не встречал обсуждений такого недостатка этого паттерна.
Для сравнения - вероятность того, что на голову человеку упадет метеорит, равняется 0,000001% [14].
Вызывает сомнение эта цифра. При такой вероятности за время жизни среднестатистического человека, нескольким десятками людей по миру должны падать метеориты на головы. Примерно по одному в год. Как-то не верится. И в статье за номером 14 про это тоже ничего нет (что, впрочем, логично - в научных статьях обычно не прибегают к обывательским сравненияи).
Пример: команда должна проводить рефайнмент сессии и оценивать скоуп своих задач. Классно звучит, но мы некоторые задачи не можем оценить и не делаем этого. Вот как можно оценить саппорт скрам-команды, когда она переходит....ну пусть на java 14? Или как можно оценить РоС? А совместный рефакторинг архитектора и команды?
Как быть: методички - класс, их писали не идиоты. Но всегда задавайте вопрос "а что для нас важно: следовать процессу или делать качество?"
Не пытайтесь повторить.
Этот параграф выглядит как набор бессвязных предложений. По крайней мере, я не понял, он раскрывает тему "слушать команду"
Записывайтесь на бесплатный пробный онлайн-урок с преподавателем и прокачайте свой английский, чтобы понимать киношную речь без заминок и пробелов.
Хе-хе, чтобы тот же Snatch на слух понимать, придется доолго заниматься, там у каждого первого персонажа свой неповторимый акцент, что не облегчает понимания, но добавляет колорита. Некоторые шутки на этом построены:
D'gs, d'gs, d'you like d'gs (произносит как dugs)
Oh, you mean dogs? Yes, I like dogs!
Браво Пучкову за адекватный перевод (по памяти, что-то вроде) :
Еще "четыре" выбивается по количеству слогов - само по себе редко мешает, но "четыредесят" - уже явно слишком громоздко. Раз уж рефакторим, ломая обратную совместимость, можно и сократить. В идеале - все простые числительные сделать односложными (примерно как в английском, только без zero и seven. Сравните, насколько быстрее произносить nine-one-one, чем девять-один-один).
И заодно избавиться от созвучности некоторых числительных, которая мешает при восприятии на слух, особенно, когда качество связи не очень: семь-восемь (особенно, если о безударное, как в "восемнадцать"), девять-десять...
Т.е. могло бы получиться что-то вроде ноль-ван-два-три-фо-пять-шесть-семь-эйт-найн
Можно не вешать, а говорить: "ой сейчас, подождите минуточку" - и ставить звонок на удержание. Кто-то минуту висит, а кто-то и пять. Мелочь, конечно, но время у мошенников вы отняли, на один-два звонка меньше сделает.
Немного наивное утверждение, мне кажется. "Захотели бы программисты, и писали бы код без багов и без уязвимостей" - нелепо звучит, не правда ли? А ведь программа - это куда более предсказуемый, управляемый и детермирированный объект, нежели социум, но вот все равно баги есть практически в любом софте.
A class or a record is a reference type. When an object of the type is created, the variable to which the object is assigned holds only a reference to that memory. When the object reference is assigned to a new variable, the new variable refers to the original object. Changes made through one variable are reflected in the other variable because they both refer to the same data.
A struct is a value type. When a struct is created, the variable to which the struct is assigned holds the struct's actual data. When the struct is assigned to a new variable, it's copied. The new variable and the original variable therefore contain two separate copies of the same data. Changes made to one copy don't affect the other copy.
И только потом идет про кучу.
Действительно, догадаться можно, но чтобы поставить собеседуемого в тупик лучше спрашивать про боксинг, и вот тогда процент догадывающихся резко упадёт.
Кстати, по моей практике, нет. Про boxing/unboxing большинство что-то слышали и с разной степенью уверенности могут ответить, что в случае боксинга значение попадет в кучу.
Всё-таки, на мой взгляд, то, как присваиваются значения — это важное, но всё-таки следствие того, где значения располагаются. Также, например, важным следствием является то, как идёт очистка памяти от значений.
Не могу в полной мере согласиться. Представьте, что в рантайме .NET 8 кроме стека и кучи появилась какая-нибудь "яма", и рантайм будет сам решать, когда выделять память в куче, а когда в яме. Семантика типов-значений и типов-ссылок от этого не изменится — в переменных значимых типов по-прежнему будет храниться само значение, а в переменных ссылочных типов — ссылка на значение, хранящееся в куче или в яме, со всеми вытекающими особенностями присваивания.
Хотя постойте… Зачем представлять? Уже есть Large Object Heap, и рантайм решает за нас, аллоцировать память в SOH или в LOH. И да, разработчику иногда важно представлять, где произойдет аллокация, чтобы оптимизировать производительность, но с точки зрения языка C# разницы между "small" reference type и "large" reference type нет.
Все верно, разрыв устраняется, но разработчику нужно понимать разницу между категориями, чтобы представлять, что будет сохранено в x после var x = new Point(); в зависимости от того, объявлен тип Point как структура или как класс. И соответственно, что будет скопировано в y - ссылка (значение ссылки) или значение целиком.
Насколько логично звучит для вас фраза "В русском языке стальные предметы обычно тяжелые, а деревянные — лёгкие"? Вроде бы и правильно по смыслу, а сравнение иголок с бревнами мы проведем по категории не-обычно. Но при чем тут русский язык?
И я не собираюсь переубеждать лично вас, но на таких статьях в том числе учатся люди, которые потом придут к нам на собеседование и будут как заученную мантру повторять "ссылочные типы хранятся на стеке, а значимые в куче". Может быть, прочтя комментарии, они задумаются "хм, а ведь и правда, они же не кучевые и стековые, наверное, неспроста!"
В C# нам доступны значимые (обычно размещаются на стеке) и ссылочные (обычно размещаются в куче) типы.
Честное слово, 9 из 10 собеседуемых отвечают таким образом.
Во-первых, сами типы не размещаются на стеке, речь в лучшем случае должна идти о _локальных переменных_ этих типов. Когда задаешь вопрос, а где тогда располагается значение поля типа int экземпляра класса, примерно треть утверждает, что на стеке, остальные догадываются, что видимо все-таки в куче, хоть оно и значимого типа.
Во-вторых, это деталь реализации рантайма, которая не имеет отношения к языку.
А в третьих, если место аллокации локальных переменных было бы ключевым отличием, то и типы назывались бы кучевыми и стековыми. Но они почему-то называются ссылочными и значимыми. Может быть потому, что ключевое различие в семантике присваивания - либо копированием ссылки_ , либо копированием _значения_?
в SOLID вроде как наоборот, нежели рассказывается в статье: родители должны описывать поведение более обще, абстрактно, а потомки должны лишь уточнять поведение.
А можно узнать, где об этом написано?
Дочерние классы могут как угодно уточнять реализацию базового класса покуда это не накладывает дополнительных предусловий. Если это происходит, то дочерний класс больше нельзя безопасно использовать вместо родительского, и принцип подстановки нарушен. Это не смертный грех, и на практике мы нередко встречаемся с такими ситуациями, поэтому, возможно, вы и воспринимаете это как вариант нормы, но написание кода это усложняет.
Чтобы не быть голословным, в.NET есть класс Stream, у которого есть изменяемое свойство Position. Но при попытке изменить Position у наследника типа HttpResponseStream получаем NotSupportedException. Т.е. принцип подстановки нарушается. Но реализовать абстракцию Stream, не нарушающую этот принцип для всех возможных наследников, часть из которых read only, часть write only, и при этом сохранить его полезность - очень непростая задача. Отсюда компромиссы и вынужденное нарушение принципа Лисков.
Поддержу. К сожалению, наблюдал обратный случай: машина впереди меня перед переходом не замедлилась, а там девушка из маршрутки вышла и побежала через дорогу, обойдя маршрутку спереди. И расстояние-то ещё приличное было, и встречка пустая, но я вижу, как машина принимает влево, а девушка в этот момент ускоряется, чтобы успеть перебежать. Тогда водитель принимает вправо, а девушка, осознав первый маневр водителя, дергается назад. Тут-то они и встретились...
Неправы одновременно и водитель маршрутки (там вообще-то нет остановки, да и раз уж остановился, лучше было бы это сделать после зебры, а не перед),и водитель, не сбавивший скорость,и девушка, не вполне адекватно ведущая себя на дороге. Но от этого никому не легче
Вот это прям лютый антипаттерн - на ровном месте создать зависимость между членами класса, похоронить потокобезопасность, сделать вызовы более многословными (прощай expression body), и все это ради... А ради чего, собственно? Плюсов я не вижу.
По существу вроде все правильно, но вот метафора шеф-повара выглядит странно. Какой же он шеф, если его функция — принять вызов и передать его ядру с бизнес-логикой? Больше бы подошел образ девушки на ресепшене.
По большому счету — бек-офисная система, учет клиентов/поставщиков/продуктов/заказов и все в таком роде. Бизнес-область — разного рода публикации, научные статьи, подписки на периодические издания, доступ к базам данных и т.п. То есть про какие-то запредельные нагрузки речи нет, все вполне умеренно. Сейчас мигрируем в AWS, в соответствии с общей политикой развития компании.
Мы сейчас как раз в процессе — переписываем решение, которое начало создаваться 60(!) лет назад и до сих пор работает. Про прямое портирование речи нет, по сути пишем с нуля на современных платформах новое приложение, которое позволит полностью отказаться от мейнфрейма через 2 с небольшим года. Для заказчика сейчас это один из важнейших приоритетов, потому что каждый день работы мейнфрейма для него несет весьма существенные расходы — достаточно большие, чтобы вложить в переписывание ресурсы в виде 5-7 скрам команд на три с половиной года.
Плюс, конечно, желание избавиться от "чёрных ящиков", когда специалист регулярно запускает какой-то макрос для выгрузки определённых данных, но никто не знает, как он работает, и разбираться в этом тоже некому...
Прошу прощения, но статья получилась ни о чем. Все-таки читатели на Хабре в большинстве своём 80-, Альцгеймером не страдают, и им (нам) можно вполне успешно объяснить несколько более сложные концепции. Где-то когда-то я что-то слышал про то, что в мейнфреймах намного эффективнее распараллеливается ввод-вывод, благодаря чему на нём by design могут работать намного больше пользователей (процессов?) не влияя друг на друга в плане производительности, чем на x86, и только в последние годы, с вводом облачных вычислений в мейнстрим, x86 смогли обеспечить схожий уровень параллелизма, который мейнфреймы обеспечивают уже очень давно. Что-то где-то слышал про нативную поддержку десятичной арифметики, что очень востребованно финансовыми приложениями, которые из-за этого сильно теряют в производительности при портировании на x86…
Но это все на уровне "кажется, я где-то об этом слышал", и я совершенно не уверен, что все на самом деле так. Но это примеры того, что было бы интересно узнать от человека, работающего с мейнфреймами, читателям Хабра.
But... Why??
В случае с v8n, это хоть как-то можно обосновать созвучием - ValidEIGHTioN - лично мне такой способ именования кажется притянутым за уши, но тут уж на вкус и цвет. Но что такое Vi-nine-es и почему это means validation - загадка для меня.
Необычно, что валидатор навешивается на команды. Более аутентичный подход, как мне кажется, это валидировать входные данные, поступающие в контролеры (реквесты) тем самым не допуская конструирования невалидных команд. Получаем следующие плюсы:
Не надо дополнительно конфигурировать FluentValidator - он на такой сценарий изначально рассчитан.
При валидационных ошибках пользователь API получит ответ, в котором сообщения об ошибках соответствуют структуре реквеста, а не команды. При разветвлённой структуре это может быть важно.
Не нужно пробрасыаать исключения при валидационных ошибках.
Из минусов я вижу то, что логика валидации конкретного реквеста связана с хендлером для команды очень неявным образом.
По своему опыту применения медатора, могу сказать, что он помогает в написании кода под конкретные юзкейсы, что особенно полезно, если одновременно работает несколько команд, и важно не поломать чужую логику в god-service. Но при этом, когда обсуждается паттерн "сервис-локатор", в качестве главного недостатка указывается, что у сервиса, имеющего зависимость от локатора, появляются невявные зависимости от других сервисов, при которые мы не можем узнать не глядя на реализацию; однако в случае с медатором мы имеем в точности то же самое, но я почему-то не встречал обсуждений такого недостатка этого паттерна.
Вызывает сомнение эта цифра. При такой вероятности за время жизни среднестатистического человека, нескольким десятками людей по миру должны падать метеориты на головы. Примерно по одному в год. Как-то не верится. И в статье за номером 14 про это тоже ничего нет (что, впрочем, логично - в научных статьях обычно не прибегают к обывательским сравненияи).
Этот параграф выглядит как набор бессвязных предложений. По крайней мере, я не понял, он раскрывает тему "слушать команду"
Хе-хе, чтобы тот же Snatch на слух понимать, придется доолго заниматься, там у каждого первого персонажа свой неповторимый акцент, что не облегчает понимания, но добавляет колорита. Некоторые шутки на этом построены:
D'gs, d'gs, d'you like d'gs (произносит как dugs)
Oh, you mean dogs? Yes, I like dogs!
Браво Пучкову за адекватный перевод (по памяти, что-то вроде) :
П'ськи, п'ськи, любишь п'ськи?
А, пëсики! Да, обожаю собачек!
Еще "четыре" выбивается по количеству слогов - само по себе редко мешает, но "четыредесят" - уже явно слишком громоздко. Раз уж рефакторим, ломая обратную совместимость, можно и сократить. В идеале - все простые числительные сделать односложными (примерно как в английском, только без zero и seven. Сравните, насколько быстрее произносить nine-one-one, чем девять-один-один).
И заодно избавиться от созвучности некоторых числительных, которая мешает при восприятии на слух, особенно, когда качество связи не очень: семь-восемь (особенно, если о безударное, как в "восемнадцать"), девять-десять...
Т.е. могло бы получиться что-то вроде ноль-ван-два-три-фо-пять-шесть-семь-эйт-найн
Можно не вешать, а говорить: "ой сейчас, подождите минуточку" - и ставить звонок на удержание. Кто-то минуту висит, а кто-то и пять. Мелочь, конечно, но время у мошенников вы отняли, на один-два звонка меньше сделает.
Немного наивное утверждение, мне кажется. "Захотели бы программисты, и писали бы код без багов и без уязвимостей" - нелепо звучит, не правда ли? А ведь программа - это куда более предсказуемый, управляемый и детермирированный объект, нежели социум, но вот все равно баги есть практически в любом софте.
По вашей же ссылке я читаю
И только потом идет про кучу.
Кстати, по моей практике, нет. Про boxing/unboxing большинство что-то слышали и с разной степенью уверенности могут ответить, что в случае боксинга значение попадет в кучу.
Не могу в полной мере согласиться. Представьте, что в рантайме .NET 8 кроме стека и кучи появилась какая-нибудь "яма", и рантайм будет сам решать, когда выделять память в куче, а когда в яме. Семантика типов-значений и типов-ссылок от этого не изменится — в переменных значимых типов по-прежнему будет храниться само значение, а в переменных ссылочных типов — ссылка на значение, хранящееся в куче или в яме, со всеми вытекающими особенностями присваивания.
Хотя постойте… Зачем представлять? Уже есть Large Object Heap, и рантайм решает за нас, аллоцировать память в SOH или в LOH. И да, разработчику иногда важно представлять, где произойдет аллокация, чтобы оптимизировать производительность, но с точки зрения языка C# разницы между "small" reference type и "large" reference type нет.
Все верно, разрыв устраняется, но разработчику нужно понимать разницу между категориями, чтобы представлять, что будет сохранено в x после var x = new Point(); в зависимости от того, объявлен тип Point как структура или как класс. И соответственно, что будет скопировано в y - ссылка (значение ссылки) или значение целиком.
Прошу прощения, я не понял ваш вопрос. Вы не могли бы его переформулировать?
Насколько логично звучит для вас фраза "В русском языке стальные предметы обычно тяжелые, а деревянные — лёгкие"? Вроде бы и правильно по смыслу, а сравнение иголок с бревнами мы проведем по категории не-обычно. Но при чем тут русский язык?
И я не собираюсь переубеждать лично вас, но на таких статьях в том числе учатся люди, которые потом придут к нам на собеседование и будут как заученную мантру повторять "ссылочные типы хранятся на стеке, а значимые в куче". Может быть, прочтя комментарии, они задумаются "хм, а ведь и правда, они же не кучевые и стековые, наверное, неспроста!"
Спасибо за обзор, но забудьте уже, что
Честное слово, 9 из 10 собеседуемых отвечают таким образом.
Во-первых, сами типы не размещаются на стеке, речь в лучшем случае должна идти о _локальных переменных_ этих типов. Когда задаешь вопрос, а где тогда располагается значение поля типа int экземпляра класса, примерно треть утверждает, что на стеке, остальные догадываются, что видимо все-таки в куче, хоть оно и значимого типа.
Во-вторых, это деталь реализации рантайма, которая не имеет отношения к языку.
А в третьих, если место аллокации локальных переменных было бы ключевым отличием, то и типы назывались бы![]()
кучевыми и стековыми. Но они почему-то называются ссылочными и значимыми. Может быть потому, что ключевое различие в семантике присваивания - либо копированием ссылки_ , либо копированием _значения_?
А можно узнать, где об этом написано?
Дочерние классы могут как угодно уточнять реализацию базового класса покуда это не накладывает дополнительных предусловий. Если это происходит, то дочерний класс больше нельзя безопасно использовать вместо родительского, и принцип подстановки нарушен. Это не смертный грех, и на практике мы нередко встречаемся с такими ситуациями, поэтому, возможно, вы и воспринимаете это как вариант нормы, но написание кода это усложняет.
Чтобы не быть голословным, в.NET есть класс Stream, у которого есть изменяемое свойство Position. Но при попытке изменить Position у наследника типа HttpResponseStream получаем NotSupportedException. Т.е. принцип подстановки нарушается. Но реализовать абстракцию Stream, не нарушающую этот принцип для всех возможных наследников, часть из которых read only, часть write only, и при этом сохранить его полезность - очень непростая задача. Отсюда компромиссы и вынужденное нарушение принципа Лисков.
Поддержу. К сожалению, наблюдал обратный случай: машина впереди меня перед переходом не замедлилась, а там девушка из маршрутки вышла и побежала через дорогу, обойдя маршрутку спереди. И расстояние-то ещё приличное было, и встречка пустая, но я вижу, как машина принимает влево, а девушка в этот момент ускоряется, чтобы успеть перебежать. Тогда водитель принимает вправо, а девушка, осознав первый маневр водителя, дергается назад. Тут-то они и встретились...
Неправы одновременно и водитель маршрутки (там вообще-то нет остановки, да и раз уж остановился, лучше было бы это сделать после зебры, а не перед),и водитель, не сбавивший скорость,и девушка, не вполне адекватно ведущая себя на дороге. Но от этого никому не легче
class ApiPosts{var postsvoid fetch(count) { posts = fetch('https://api.dev/posts', {...}); }}Вот это прям лютый антипаттерн - на ровном месте создать зависимость между членами класса, похоронить потокобезопасность, сделать вызовы более многословными (прощай expression body), и все это ради... А ради чего, собственно? Плюсов я не вижу.
По существу вроде все правильно, но вот метафора шеф-повара выглядит странно. Какой же он шеф, если его функция — принять вызов и передать его ядру с бизнес-логикой? Больше бы подошел образ девушки на ресепшене.
По большому счету — бек-офисная система, учет клиентов/поставщиков/продуктов/заказов и все в таком роде. Бизнес-область — разного рода публикации, научные статьи, подписки на периодические издания, доступ к базам данных и т.п. То есть про какие-то запредельные нагрузки речи нет, все вполне умеренно. Сейчас мигрируем в AWS, в соответствии с общей политикой развития компании.
Мы сейчас как раз в процессе — переписываем решение, которое начало создаваться 60(!) лет назад и до сих пор работает. Про прямое портирование речи нет, по сути пишем с нуля на современных платформах новое приложение, которое позволит полностью отказаться от мейнфрейма через 2 с небольшим года. Для заказчика сейчас это один из важнейших приоритетов, потому что каждый день работы мейнфрейма для него несет весьма существенные расходы — достаточно большие, чтобы вложить в переписывание ресурсы в виде 5-7 скрам команд на три с половиной года.
Плюс, конечно, желание избавиться от "чёрных ящиков", когда специалист регулярно запускает какой-то макрос для выгрузки определённых данных, но никто не знает, как он работает, и разбираться в этом тоже некому...
Прошу прощения, но статья получилась ни о чем. Все-таки читатели на Хабре в большинстве своём 80-, Альцгеймером не страдают, и им (нам) можно вполне успешно объяснить несколько более сложные концепции. Где-то когда-то я что-то слышал про то, что в мейнфреймах намного эффективнее распараллеливается ввод-вывод, благодаря чему на нём by design могут работать намного больше пользователей (процессов?) не влияя друг на друга в плане производительности, чем на x86, и только в последние годы, с вводом облачных вычислений в мейнстрим, x86 смогли обеспечить схожий уровень параллелизма, который мейнфреймы обеспечивают уже очень давно. Что-то где-то слышал про нативную поддержку десятичной арифметики, что очень востребованно финансовыми приложениями, которые из-за этого сильно теряют в производительности при портировании на x86…
Но это все на уровне "кажется, я где-то об этом слышал", и я совершенно не уверен, что все на самом деле так. Но это примеры того, что было бы интересно узнать от человека, работающего с мейнфреймами, читателям Хабра.