Подарки от программис'тов
программист может не знать особенности работы индекса словаря
Это как бы мелочь.
Для начала неизвестно, что у нас с левой стороны.
Затем видим - операция добавления, значит коллекция меняется.
Вторая строка - операция присваивания, коллекция меняться не должна, мы ведь работаем с конкретным элементом.
То бишь налицо побочный эффект, я бы сказал отрицательный. Потому что хочу менять только те элементы что уже имеются, а добавлять только те которых нет. Вполне возможно что кто то захочет ровно наоборот, но это никак не причина разделять одну операцию на две
Ладно, вот другой примерчик странных подарков. К чему может быть такое наследование?
public class Config : ConfigBase<Config>
Конструктора у Config нет. Но это значит, что у него есть дефолтный без параметров.
Внутри ConfigBase сидит статическое свойство
public static T Configuration { get ... ; set ... ;}
в котором под блокировкой (lock) организуется загрузка конфигурации в геттере.
Как я понимаю, любой Config имеет статическое свойство на самого себя... И что это даёт? Можно в бесконечном цикле самого себя опрашивать?
Я бы подумал, что это какая-то странная организация синглетона через наследование и параметр типа, но дефолтный-то конструктор не мешает насоздавать сколько угодно Config? Плюс сеттер публичный доступен. "Протекающий" синглетон какой-то.
К чему может быть такое наследование?
Вот тут хз... Статики вообще маст дай :)
Зачем тут такое сказать сложно, наверное это действительно вариант синглтона. Т.е. автор хотел, чтобы у каждого конфига (типа) был ровно один конфигуратион. Тут я правда не знаю, как генерики дружат со статиками.
Кто-нибудь работал с проектами, которые нельзя запустить по Ф5 в Студии? Проекту требуется сложная система конфигурационных файлов, находящихся строго в нужных папочках. Эти файлы копируются и генерятся (!) в процессе установки. Протестировать юнит-тестами - тоже сомнительное дело, т.к. даже объект конфигурации - сложная система классов (вот как я выше привёл со странным наследованием в виде себя же в качестве параметра типа), имеющая ссылки на кучу других классов и ресурсов. Вобщем, собрать mock-объект для такого типа - та ещё задачка. Ну и вообще проект при инсталляции перемещает туда-сюда горы исполняемых и конфигурационных файлов, и по их захардкоденным путям потом их используют другие части проекта. Если просто дрюкнуть Ф5 - ничего на своих местах не обнаруживается.
И что это даёт?
-----
Кеширование?
Опять же, вы имеете ввиду синглетон или что-то подобное - один раз загрузил конфиг и держишь в памяти? Но почему так сложно - для этого можно просто иметь статическое свойство с конфигурацией в памяти. А там нагородили наследование и параметр типа в виде самого себя же.
Сделайте его или
-----
нее, это слишком просто... всякие джуны полезут править без понимания что и зачем...
Так делают все - от ждунов до помидоров. Если после недельки кипящих мозгов и отсутствия нормальных доков всё ещё невозможно понять, что там понаписано - выкидываешь в мусор и переписываешь по-своему.
Сделайте его или
-----
нее, это слишком просто... всякие джуны полезут править без понимания что и зачем...
Я знаю, что такое моки. Как и то, что они не панацея. На любой хитрый мок можно найти такой объект с кучей зависимостей (включая внешние), который фиг замокаешь. Вот и здесь что-то такое - объект грузит кучку файлов, которых без исталляции не существует на своих местах (не передвинули) или не существует вообще (не сгенерили). Чтобы протестировать такой объект, целую кучу мокающего кода нагородить надо. Естественно, всё это упадёт, если в этой куче кто-то что-то изменит (а он обязательно изменит). Проще выкинуть и написать по-своему.
имея только геттер, ты получаешь доступ ко всем методам и свойствам словаря
И список ключей можешь получить
И все очистить.
Ну и это уже будет намеренный выстрел в ногу.
Нууу... вобщем и целом первое объяснение как-то катит. Правда, зависит от контекста. У меня юзер словаря и так знает все ключи - так что он обнулит всё равно, если захочет. Да и всё равно, даже если все не знает - обнулит те, что знает. Т.е. не защита от вредителя (тут вообще другие механизмы нужны, а не абстрагирование в коде), да и от дурака - так себе. Зато куча неудобств для нормальных людей.
Заметьте, что по фен-шую (ну, как тут на некоторых островах принято) нужно на GetValue/SetValue сделать интерфейс, затем унаследоваться от него и написать реализацию, и наконец протестировать это всё. Со словарём ничего такого делать не надо. Пишешь такой неработающую "защиту от дурака" - два-три тикета в таск-трекере, работы на полдня, на митинге что-то брякнул про важность и полезность такого подхода. А по факту только наговнокодил и усложнил всё. ))
А потом через время придёт "дурак" со стороны, для поддержки этой всей дури, через недельку бесполезных попыток понять, что происходит, плюнет и перепишет проще и по-своему. Так что все защиты, паттерны и прочие глюки сектантов с островов полетят в корзину.
Больше подходит, что чел хотел абстрагироваться от конкретного способа хранения, но это преждевременная оптимизация - менять словарь на что-то другое с индексами и ключами явно незачем.
Кто-нибудь работал с проектами, которые нельзя запустить по Ф5 в Студии? Проекту требуется сложная система конфигурационных файлов, находящихся строго в нужных папочках. Эти файлы копируются и генерятся (!) в процессе установки.
Все просто - устанавливаешь свою прогу, меняешь в студии output path и отлаживаешь уже в папочке с установленной версией :)
Не, там скорее после установки можно пути к нужным файлам взять в мою прогу. Но суть предложения я понял - без установки никак.
Но я считаю это неправильным, когда по Ф5 приложение не работает. Как его тестировали? Одними юнит-тестами? А процесс установки довольно длительный и, главное, требует ввода кучих данных. Т.е. приходится разрабатывать на установленном приложении. Но после каждого существенного обновления (разработал фичу) нужно править установщик - т.е. деинсталлировать и инсталлировать снова. И так постоянно. Бред...
Но я считаю это неправильным, когда по Ф5 приложение не работает.
Так оно работает :) Просто надо немного подготовить систему. Такое, кстати, бывает очень часто. А раньше, когда надо было регистрировать COM компоненты такая байда была сплошь и рядом. Сейчас тоже программы часто привязываются к путям на жестком диски и/или к реестру.
Как его тестировали?
Устанавливали и тестировали :)
А процесс установки довольно длительный и, главное, требует ввода кучих данных.
Наверняка есть silent install, где все эти данные можно ввести заранее (через командную строку или через конфигурационный файл)
Но после каждого существенного обновления (разработал фичу) нужно править установщик - т.е. деинсталлировать и инсталлировать снова. И так постоянно. Бред...
Или просто поменять сборки в уже установленном софте :)
