Для гладкоствольного оружия и сейчас можно делать так же. Гильзы, капсюли, порох, дробь/пули, пыжи — все это продается официально по отдельности. Для пороха и капсюлей спросят разрешение на оружие. Все остальное продается свободно. С готовыми патронами тут просто нюанс — раньше их можно было купить сразу с оружием. Т.е. у тебя есть лицензия на приобретение оружия — топаешь в магазин и покупаешь и ствол, и патроны к нему одним махом. Потом прописали, что продажа патронов осуществляется только при наличии разрешения на хранение или хранение и ношение. Но какое-то время еще в магазинах на это забивали. Но уже некоторое кол-во лет только по разрешению продают. По крайней мере в Москве. То ли штрафы были продавцам, то ли что похуже. Как с этим делом в конкретном магазине в Казани — хз.

Было такое с геймпадом «обрезиненным». Лежал несколько лет. Потом достал — даже дотрагиваться противно. В итоге этанолом чистым отмыл. Слой этот с поверхности смылся — получился просто пластиковый.
А x52 после какого срока так испортился? Я пару месяцев как купил — теперь вот после вашего сообщения переживаю.

Как отличить правильно спроектированный слой доступа к данным от неправильно спроектированного?

Время покажет.

Угу. Возьмем один метод, [.....] А то же самое между потоками? А между процессами (передача сериализованных данных)?

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

Теперь добавим еще один метод: save(entity).[.....]Что сохранится?

На этот вопрос ответит реализация абстракции TransactionManager

А теперь смотрите, в чем ловушка: совершенно не важно, какие ответы вы дадите. Важно другое — все эти ответы (и десятки других!) явно описаны где-то? На каждый из них есть тест? Или вы просто привыкли, что оно работает так?

На весь функционал, который востребован — да, все описано и покрыто тестами. Иначе подмена реализации чревата проблемами. Да и непонятно как работала первая реализация.

Все остальное уже разработано, протестировано. И трогать не надо ни бизнес логику, ни UI, ни что-то другое. [...] После такого перехода конечно же поменяются характеристики работы приложения

Подождите. Вы же только что говорили, что все уже разработано и протестировано, а теперь говорите, что характеристики поменяются. Если поменялись характеристики — надо перетестировать, а если они стали неудовлетворительными — переписывать. И нет, переписывать только DAL окажется недостаточно. А это значит, ваша абстракция снова протекла.

Вы тут забыли прихватить в цитату окончание фразы

такие как скорость работы, максимальная нагрузка и т.д. и т.п.

Эти вещи обязательно поменяются, т.к. напрямую зависят от характеристик хранилища данных. Но перетестирования всего остального не потребуется. Верстка UI от этого не поломается. Бизнес логика какой была, такой и осталась. Или вы хотите поменять часть приложения так, чтобы ничего не поменялось? Так архитектура не об этом.

Занятно, не находите? Утверждается, что архитектура, которая позволяет поменять хранилище, хорошая, но необходимость поменять хранилище — архитектурный косяк.

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

Это все к тому, что красивые фразы «это все детали реализации» обычно так и остаются красивыми фразами, потому что суровая реальность намного сложнее, чем простые примеры.

Это конечно все так. Но не потому, что абстракция плохая и не работает. Чаще всего просто не хотят / не умеют четко разделять слои, считают что это слишком долго, дорого и т.д.

Тот же переход с реляционки на KV например. Если сразу правильно спроектировать слой доступа к данным, то там будет, например, для сущности Customer интерфейс с необходимыми для работы приложения методами.

interface CustomerRepository {
  EntityCustomer getById(Long id);
  EntityCustomer getByName(String name);
  EntityCustomer getByManyManyAttrs(many many attrs ......);
  EntityCustomer save(EntityCustomer entity);
...............
}

Поменять реализацию этого интерфейса — поменяется хранилище. На что угодно. В том числе и на KV.
Да, там будет много проблем с поиском не по ключу, с объединением данных и т.д. и т.п. Это может действительно оказаться очень долго и дорого. Но! Это реализация только слоя хранения. Те самые «детали реализации». Все остальное уже разработано, протестировано. И трогать не надо ни бизнес логику, ни UI, ни что-то другое.

После такого перехода конечно же поменяются характеристики работы приложения, такие как скорость работы, максимальная нагрузка и т.д. и т.п. Все зависит от новой реализации.

Совершенно другой вопрос — откуда необходимость столь радикальной смены хранилища? Слишком суровый архитектурный косяк, imho.

Зачем два раза одну и ту же пару проверять? 10*90 == 90*10. Второй цикл надо начинать не от 10, а от «x». Про остальное уже сказали.

Если оружие зарегистрировано, как оружие самообороны (даже длинноствольное без права ношения), то по закону каждые 5 лет при продлении разрешения необходимо сдавать экзамен на знание законов и правил обращения.
Отстрел нарезных в пулегильзотеку с 2019 года проводится раз в 15 лет.
Участковый обязан приходить раз в год и составлять акт о проверке условий хранения. + по запросам может приходить дополнительно. Другое дело что они на это часто забивают…
Если в ПДД появился новый знак, разметка или изменился процесс постановки авто на учет, то максимум что грозит за незнание — штраф. Если изменилось что-то в оружейном законодательстве, то можно лишиться оружия или даже сесть, как я уже говорил. Например — установил не родной приклад на карабин, все было по закону. А через пару лет закон поменялся и автоматом влетел под 223 УК РФ. Хотя на тот момент, когда делал все было по закону. А по факту от трех до пяти лет. Потому что не следишь за законодательством. По моему опыту люди, у которых имеется охотничье оружие, одни из самых законопослушных в РФ. Как раз из-за этих вот особенностей законотворчества.
И проверкой знаний (хоть и далеко не всех) для владельца оружия раз в пять лет является процесс продления разрешений. Ну и каждый выход на охоту, в тир и т.д. Я 4-й раз продлеваю вот сейчас. Каждый раз процедура хоть в чем-то да отличается. И чаще всего ужесточается. Единственное послабление — контрольный отстрел нарезного оружия теперь раз 15 лет.

В РФ если у тебя ОООП (травмат), то ты обязан раз в пять лет проходить обучение и проверку этих знаний. Ну и в целом как с ПДД не прокатит. Если придумали новые правила для дороги и ты не в курсе, то получишь штраф. Если придумали новый закон по оружию, а ты не в курсе, то можно и оружия лишиться совсем. А то и присесть. Так что в этой области народ следит более менее регулярно. И некоторая «проверка» раз в пять лет случается — продлевать надо разрешения. Сколько раз продлеваю, столько раз процедура не повторяется на 100%. Каждую пятилетку что-то да меняется.

Навеска та же самая. Ибо скорости вылета те же самые тоже. В РФ армейские vs гражданские патроны в первую очередь отличаются пригодностью к длительному хранению и стойкости к окружающей среде. Например распространенные 7.62x39 (АКМ и т.д.). На армейских лаком покрыты стыки гильза-капсюль и гильза-пуля. Чтобы влага на попадала. На гражданских такого нет. Пулями еще отличаются. В плане конструкции, разнообразия и т.д.

после какого слова директор побежит к программистам, чтобы все переделывать?

Я смотрю директор линкедина бежит к программистам — аж спотыкается. Потому ни как не добежит.

Тут как бы две точки зрения:

1. Преподносится все как кнут: не исполняете закон — щас как заблокируем! И типа все побегут
2. На самом деле все закончится после «заблокируем». Кто не выполняет сии законы, того не будет в российском сегменте.

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

Возьмем к примеру язык DELPHI. Несмотря на наличие у него этих самых дженериков, он содержит специальный тип VARIANT для операций с произвольными типами данных.

ЕМНИП дженерики в делфи завезли в версии 2009 года. При этом вариантами пользовались чуть ли не с первой версии… Так себе аналогия получается

6 лет, книга «Юный радиолюбитель», первый детекторный приемник… Отец приносил с работы б/у платы, я их распаивал на детали. Потом что-то из них собирал. Половину детства с паяльником в руках. Но с лампами как-то не сталкивался. Ибо началось все для меня в 1987-1988 годах. Сразу изучал и собирал транзисторные схемы. Потом попались в руки первые микросхемы. Если правильно помню это были 2 штуки к176ла7. Цифровая электроника понравилась больше. А потом я увидел компьютеры ) Так что не уверен, что я именно радиолюбитель. Однако всех с праздником )

По цене таки ошибся — сейчас посмотрел официальный сайт — 12кр за эру хотят. В конфигураторе необязательная опция.

Renault Kaptur

В январе 2019 года купил в Москве у официального диллера новый автомобиль. Эры в нем нет. На мой вопрос «собственно как так?» мне сказали, что юристы автопроизводителя выяснили, что эта хрень все же не обязательная к установке и теперь они их снова не ставят. Точнее ставят если не ошибаюсь за 26кр. Опция, понимаешь. Насколько соврали не знаю. Но факт — в машине этой штуки нет.

На Т34 выпускались промышленные версии спектрумов в начале 90-хх. Назывались «Веста ИК-31». Была еще «Веста ИК-30» в которой вместо Т34 было много корпусов попроще.

Кстати, помню журнал Zx-Ревю, где народ модифицируя файлы сохранения в Элите попадал в рандомные галактики.

Если склероз мой не изменяет мне ни с кем, то можно было тормознуть загрузчик, дописать в него несколько poke и тем самым сдвинуть генератор галактик. Но Raxxla ни кто так и не нашел. Не было в генераторе названий планет слога «xx» )

любая книга В.Г. Борисова

Это которая «Юный радиолюбитель»? Я когда начал в 5 лет спрашивать как радио работает, мне ее отец принес и выдал со словами «читай». В 6 лет первый приемник уже рабочий получился. В общем о книге самые теплые воспоминания. Я ее до сих пор храню. Надеюсь дети заинтересуются тоже )

Почему-то всегда думал, что стандартная частота была 3.5, а турбо 7…

Из 48 ОЗУ еще надо вычесть 6 с небольшим для экрана, примерно 1-2 на системные переменные, и еще в конце памяти лежали символы режима G.

Это были не спрайты, а знакоместа. 8 байт, 8 на 8 точек. При чем байты одного знакоместа располагались не подряд в памяти, а через каждые 256 байт. Таким образом при адресации по паре регистров HL для перехода к следующему байту инкрементили старший регистр, а не прибавляли 32 к паре. Весь экран получатся из 3 таких блоков по два килобайта. По такому экрану весело было рисовать что-то, что не было горизонтальной линией )

+ 1 байт в области атрибутов. 4 бита цвет 1 в знакоместе, другие 4 — цвет 0. Цветов 8 — т.е. три бита. +1 бит «яркость». А для фона этот признак добавлял мерцание.

<Задумчиво> И вот зачем я все это помню до сих пор…

Я бы отметил три момента в вашем коде.
1. Не выполнено условие, что клиент может уйти из очереди. В методе onLeave клиенты уходят только из-за стола. Попавший в очередь же будет стоять до последнего…
2. Метод setFreeSpace мягко говоря водит в заблуждение. По соглашению это должно бы быть присваивание. А у вас там неочевидная математика. Сделали бы методы add и remove например.
3. Если вы сдавали все вот так одним файлом, то опять же большой ай-я-яй. Помимо стиля. Ваши классы, которые вы сделали для проверки, в ответе присутствовать не должны. В итоге еще и нарушили поставленное условие на конструктор RestManager.

По сути задача не решена получается. Потому и отказ.